Unidad de Trabajo - ¿Cuál es el mejor enfoque para el almacenamiento de objetos temporal en una granja de servidores web?

Question

necesito para diseñar e implementar algo similar a lo que Martin Fowler llama el patrón "unidad de trabajo". He oído que otros se refieren a ella como un patrón "carrito de compras", pero no estoy convencido de que las necesidades son lo mismo.

El problema concreto es que los usuarios (y nuestro equipo de interfaz de usuario) quieren ser capaces de crear y asignar los objetos secundarios (con restricciones de integridad referencial en la base de datos) antes de crear el objeto padre. Me encontré con otro de nuestros diseñadores de hoy en día y se nos ocurrió dos enfoques alternativos.

a) En primer lugar, crear un objeto padre maniquí en la base de datos, y luego crear los niños ficticias y asignaciones ficticias. Podríamos utilizar claves negativas (las teclas normales son todos positivos) para distinguir entre las ovejas y las cabras en la base de datos. A continuación, cuando el usuario envía toda la transacción, es necesario actualizar los datos y obtener las claves reales añaden y alineados.

Veo varios inconvenientes a éste.

• Se provoca perturbaciones a los índices.
• Todavía tenemos que llegar a algo para satisfacer restricciones únicas de columnas que los tienen.
• Hay que modificar un montón de SQL y el código existente que genera SQL para añadir otro predicado a un montón de cláusulas WHERE.
• La alteración de las claves principales en Oracle se puede hacer, pero es un desafío.

b) Crear tablas transitorios para los objetos y las tareas que tienen que estar en condiciones de participar en estas operaciones temporales. Si el usuario selecciona Enviar, generamos las entradas reales y purgar la edad.

Creo que esto es más limpio que la primera alternativa, pero todavía implica un mayor nivel de actividad de la base de datos.

Ambos métodos requieren que tengo alguna forma de expirar datos transitorios si la sesión se pierde antes de que el usuario ejecuta someter o cancelar pedidos.

¿Alguien ha resuelto este problema de una manera diferente?

Gracias de antemano por su ayuda.

Answer 1

No entiendo por qué estos objetos se deben crear en la base de datos antes de que se confirme la transacción, así que sería bueno aclarar con su equipo de interfaz de usuario antes de proceder con una solución. Es posible que todo lo que quieren hacer es leído previamente la información guardada por el usuario en otra página.

Por lo tanto, suponiendo que los objetos no necesitan ser almacenados en la base de datos antes de la confirmación, te doy el plan C:

inicializado tienda de objetos de negocio en la sesión. A continuación, puede crear todos los hijos que desea, y sólo tocar la base de datos (y establecer referencias) cuando la transacción necesita ser comprometido. Si los datos de sesión va a ser grande (ya sea individual o colectivamente), almacenar la información de la sesión en la base de datos (que ya puede estar haciendo esto).