Unità di Lavoro - Qual è l'approccio migliore per oggetto temporaneo stoccaggio in una web farm?

Question

Ho bisogno di progettare e implementare qualcosa di simile a quello di Martin Fowler chiama "Unità di Lavoro" modello.Ho sentito altri si riferiscono ad essa come un "Carrello della spesa" modello, ma non ne sono convinta, le esigenze sono le stesse.

Il problema è che gli utenti (e i nostri UI team) vuole essere in grado di creare e assegnare gli oggetti figlio (con vincoli di integrità referenziale del database) prima che il genitore viene creato l'oggetto.Ho incontrato con un altro dei nostri progettisti di oggi e siamo venuti con due approcci alternativi.

a) in Primo luogo, creare un manichino oggetto principale nel database, e quindi creare fittizio bambini e fittizio assegnazioni.Potremmo usare negativo tasti (i normali tasti sono tutti positivi) per distinguere tra le pecore e le capre nel database.Quindi quando l'utente invia l'intera transazione dobbiamo aggiornare i dati ed ottenere le chiavi aggiunte e allineati.

Vedo alcuni inconvenienti di questo.

• Essa provoca perturbazioni per gli indici.
• Abbiamo ancora bisogno di trovare qualcosa per soddisfare i vincoli unici su colonne che hanno loro.
• Dobbiamo modificare un sacco di SQL esistente e il codice che genera il codice SQL per aggiungere ancora un altro predicato per un sacco di clausole WHERE.
• Alterare le chiavi primarie in Oracle può essere fatto, ma è una sfida.

b) Creare Transitoria tabelle per gli oggetti e le assegnazioni devono essere in grado di partecipare a queste operazioni temporanee.Quando l'utente preme Invia, siamo in grado di generare il vero non valide ed eliminare il vecchio.

Penso che questo è più pulita rispetto a prima alternativa, ma comporta comunque un aumento dei livelli di attività del database.

Entrambi i metodi richiedono che mi hanno in qualche modo a scadere i dati transitori se la sessione è perso prima che l'utente esegue inviare o annullare le richieste.

Qualcuno ha risolto questo problema in un modo diverso?

Grazie in anticipo per il vostro aiuto.

Answer 1

Non capisco perché questi oggetti devono essere creati nel database prima del commit della transazione, così si potrebbe desiderare di chiarire con la UI di squadra prima di procedere con una soluzione.Si potrebbe scoprire che tutti si desidera fare è leggere le informazioni precedentemente salvate dall'utente su un'altra pagina.

Così, supponendo che gli oggetti non devono essere memorizzati nel database prima del commit, ti do il piano C:

Negozio inizializzato business objects nella sessione.È quindi possibile creare tutti i bambini che si desidera, e solo toccare il database (e impostare i riferimenti) quando la transazione ha bisogno di essere impegnata.Se i dati della sessione sta per essere grande (individualmente o collettivamente), memorizzare le informazioni di sessione nel database (si può già fare questo).