Quale schema si adatta tra una facciata e un DAO?

Question

Sono in procinto di progettare parte dell'architettura della mia azienda per le sue applicazioni web Java EE. Sono abbastanza chiaro sui motivi per utilizzare una facciata e uno o più DAO. Il problema che ho è questo:

Ci sarà una logica che sicuramente appartiene al livello di integrazione perché si tratta di mantenere il modello di dati coerente. Tranne la logica va oltre il semplice mantenimento dell'integrità referenziale e di altre attività di persistenza "crude" che saranno gestite da JPA e Hibernate. Non classifico questo come logica aziendale perché è separato da qualsiasi funzione aziendale. Tuttavia, la mia comprensione è che un DAO dovrebbe implementare solo la logica necessaria per accedere e mantenere gli oggetti all'origine dati.

La mia conclusione è che ho bisogno di un modello "business object" che sia appropriato per il livello di integrazione. Mi sono guardato intorno e la cosa più vicina che ho trovato (ma ancora non mi sembra giusto) è lo Sun Transfer Object Assembler pattern.

O c'è una lacuna nella mia comprensione di Java EE o c'è un modello là fuori che si adatta.

Answer 1

forse un mediator è ciò che si vuole:

definire un oggetto che incapsula come un insieme di oggetti interagiscono. Il mediatore promuove l'accoppiamento libero impedendo esplicitamente agli oggetti di riferirsi l'un l'altro e consente di variare la loro interazione in modo indipendente.

quindi è possibile utilizzare un DaoMediator al fine di coordinare due o più DAO s

Answer 2

Mi sembra che manchi un controller e, di conseguenza, potrebbe essere necessario il modello MVC. Il controller si prenderà cura dei DAO e presenterà una vista coerente (non pensare in termini di GUI, burt piuttosto un'interfaccia client-facing). Quando le modifiche vengono apportate tramite questa vista, il controller coordina le modifiche al modello tramite DAO. Sospetto che gli oggetti della tua facciata possano essere la vista in questo scenario.

Detto questo, non mi preoccuperei troppo molto sull'identificazione di particolari modelli. Trovi spesso che, prendendo in considerazione tutte le tue esigenze e separando le preoccupazioni, laddove applicabile, finisci per implementare un particolare schema e lo identifichi solo come tale dopo il fatto.

Answer 3

Penso che sia un pattern DataMapper (o Adapter) tra il tuo DAL e il tuo Business Layer, ma senza una comprensione più concreta non potrei esserne sicuro.

Answer 4

Avete pensato di utilizzare aggregati da Domain Driven Design? Sono uno studente di DDD e penso che la logica di business che stai cercando di progettare possa essere realizzata da modelli di dominio più ricchi di POJO. Dovresti avere ciascun oggetto dominio responsabile per i suoi oggetti aggregati e includere anche qualsiasi logica relativa a tale concetto di business; detto questo, il tuo strato di integrazione coordinerebbe quegli oggetti ricchi ma si asterrebbe dall'avere una logica reale di per sé (cioè una logica condizionale diversa).

Forse lo schema che stai cercando di trovare è in realtà un passaggio in oggetti di dominio più ricchi?

Answer 5

Qual è l'esigenza di coerenza tra i DAO? Se c'è qualche ipotesi aziendale che sta dettando la relazione.Ad esempio, potresti avere un tipo di fattura che quando è "Capitale", allora dobbiamo assicurarci che molti altri oggetti siano nello stato giusto o che abbiano il giusto insieme di valori. Questo è decisamente al di fuori del regno del livello dati.

Non vorrei provare a trovare il modello perfetto per questo caso. Hai bisogno di una sorta di classe di coordinamento, un mediatore o un controllore di qualche tipo.