L'oggetto del modello di dominio passa tra i livelli generali?

Question

Sto lavorando a un progetto che utilizza l'ibernazione e la primavera. Hibernate è incapsulato in un livello DAO e il livello DAO ha anche il livello di servizio corrispondente, inoltre i controller mappati per le richieste e le pagine JSP. Mi è stato detto di non passare oggetti tra questi livelli (Controller < -> Servizio < -> DAO) poiché si tratta di un sovraccarico delle prestazioni. Un'istanza particolare era quando ho avuto bisogno di aggiornare un valore booleano in un oggetto dominio (classe ORM), ho scritto un metodo che ha passato l'oggetto dominio tra il livello di servizio e il livello DAO e mi è stato detto di passare l'ID oggetto e il particolare booleano solo valore e scrivere metodi separati nei livelli per quello. È giusto? Ritengo che farlo annullerà molti vantaggi dell'utilizzo di uno strumento ORM (Hibernate). Ho sbagliato a pensarlo? Qualsiasi consiglio e approfondimento sarà utile ....

Answer 1

Hai 100% di ragione. Questo è un consiglio terribile. Passa gli oggetti intorno È esattamente ciò per cui è progettato Hibernate, e "overhead delle prestazioni" per il normale passaggio di oggetti è semplicemente pazzesco. A meno che non ci sia qualcosa nell'app che non conosci, fai attenzione ai consigli della persona che ti ha detto questo.

Answer 2

Come per la maggior parte dei problemi di architettura, c'è un compromesso da fare qui.

Per le applicazioni che non prevedono l'utilizzo di un'architettura orientata ai servizi (ad esempio un sito Web autonomo con database di backup, una singola applicazione aziendale interna), è molto meglio che il modello di dominio venga esposto a tutti gli strati del applicazione. Ciò garantisce che non violi il principio DRY (Non ripeti te stesso) e che non devi eseguire molti refactoring ogni volta che aggiungi una nuova proprietà al tuo modello di dominio. È inoltre possibile utilizzare un framework come il validatore NHibernate per definire una volta la convalida e utilizzare tale convalida sia per il livello dati sia per il livello Web.

Per le applicazioni più grandi che contengono molti servizi separati (ad esempio grandi suite di applicazioni aziendali interne), è opportuno separare l'ORM dall'interfaccia del servizio. Ciò consentirà di apportare modifiche ai modelli di accesso ai dati senza modificare l'interfaccia del servizio (e viceversa), il che è estremamente prezioso quando molti altri servizi dipendono dalla stabilità dell'interfaccia.

Tuttavia, la situazione descritta (utilizzando metodi per modificare proprietà specifiche) non sembra corrispondere a nessuno di questi scenari: è generalmente una cattiva idea seguire lo schema che hai descritto in quanto traccia i percorsi di esecuzione e il refactoring molto difficile (e può portare a codice spaghetti). L'unica possibilità di utilizzo che posso pensare è se i tuoi modelli di dati sono molto grandi (5k XML blob, ecc.) E inviarli attraverso il livello di servizio genererebbe grandi quantità di traffico. (NB: gli oggetti C# sono molto più piccoli di 5k se serializzati correttamente!)

Si consiglia di passare l'intero modello di accesso ai dati fino al livello Web.

Answer 3

ottimizzazione prematura è la radice di tutti i mali

anche in alta Frequency Trading, dove 50 nanosecondi importa, fate ciò che è giusto prima, e poi ottimizzare, se necessario. Sareste sorpresi di ciò che possono fare i moderni compilatori/larghezza di banda della rete.

Per rispondere alla domanda più direttamente => passare quegli Oggetti in giro e non pensare alle prestazioni. Lo farai, se ne avrai bisogno in seguito, ma è molto probabile che lo sia causato dal passaggio degli oggetti in giro.