Sto pensando a come strutturare un progetto. Mi chiedo se sia una buona pratica utilizzare classi di entità diverse tra BL e DAL per disaccoppiare questi livelli.
Ho lavorato su progetti in cui classi di entità sono state inserite in un progetto / pacchetto separato. Quindi BL e DAL hanno utilizzato le stesse entità.
Ma posso immaginare che un approccio migliore sia definire una classe di entità per ogni livello e il suo assemblaggio. Quali sono i pro ei contro oggettivi di tale approccio?
Lo scopo del BL è implementare la logica di dominio che funziona con le entità di dominio. La definizione di queste entità è guidata dal business.
Lo scopo del DAL è quindi di organizzare la persistenza delle entità di dominio. L'idea è di nascondere dagli strati superiori i brutti dettagli dell'accesso ai dati e del database. Se è ben fatto, puoi cambiare il database sotto la superficie e lasciare invariati i livelli superiori.
Non sorprende che il dominio le entità siano condivise su entrambi i livelli : BL ha bisogno che vengano eseguite attività di dominio, ma DAL ha bisogno di loro per organizzare la persistenza.
Il disaccoppiamento dei componenti è generalmente un'ottima idea. Tuttavia, i livelli non sono componenti indipendenti. I livelli sono raggruppamenti logici di classi correlate.
Se possibile, puoi anche ridisegnare il diagramma del livello e immaginare un livello tra BL e DAL che contiene le Entità. E all'improvviso, gli strati appariranno puliti e disaccoppiati.
Proponi un'alternativa all'uso di due diversi tipi di entità nei diversi livelli. Quindi avresti entità di dominio appropriate nel BL. E tu avresti entità di accesso ai dati intermedi nel DAL.
Ora immagina di implementare questo schema perfetto. Come faresti allora il collegamento tra l'entità BL e l'entità DAL? In qualche modo questi dovrebbero conoscersi per sincronizzare i dati. Quindi finiresti per avere un strong accoppiamento tra gli strati comunque. È solo che sarebbe meno ovvio.
Definisci entità in una classe e usa la stessa entità in BL e DAL. questo design salva il tuo tempo e il bug che proviene dal cambiare le entità di volta in volta.
Se il progetto è diretto e utilizza un'unica origine dati, ha senso utilizzare le stesse classi di entità in cui la logica aziendale e il livello di accesso ai dati utilizzano le stesse classi di entità. Se si hanno a che fare con più fonti di dati e la logica aziendale si occupa di più fonti di dati e gestisce un sacco di convalida e trasferimento di dati; è possibile utilizzare oggetti separati, ad esempio oggetti di trasferimento dati per il livello aziendale. Ciò dà la flessibilità di offrire un semplice DTO al livello di presentazione in una singola chiamata.
Leggi altre domande sui tag coupling architecture business-logic layers entity