È una cattiva pratica usare gli oggetti entità su tutti i livelli di un'applicazione web?

Question

Sto sviluppando un'applicazione Web che utilizza un'architettura a livelli. Ho:

1. Application Layer (Controller)
2. Servizio strato (Servizi)
3. strato di accesso ai dati (DAO)

che si collega a un database Oracle back-end.

Sto usando JPA con Hibernate come implementazione. Creo quindi entità per modellare la vista dell'oggetto delle mie tabelle di database relazionali.

La mia domanda è ... È considerata una cattiva pratica utilizzare questi oggetti entità su tutti e 3 i miei livelli?

So che deve essere utilizzato almeno dal livello di accesso ai dati, ma che cosa si può dire al di là del livello di servizio &?

Ho visto alcune persone utilizzare DTO nei livelli di applicazione & e fanno la conversione tra DTO ed entità tra i livelli di Accesso ai dati del servizio &.

Basta chiedersi qual è la migliore pratica per questo e quale dovrebbe essere l'approccio migliore?

Answer 1

Non si dovrebbero mai usare gli oggetti entità in tutto il livello. Usando lo stesso oggetto su tutti i livelli, esegui l'accoppiamento stretto tra i dati dei moduli dell'interfaccia utente e le tabelle del database.

Se si desidera modificare il nome del campo sull'interfaccia utente, è necessario modificare la colonna corrispondente nella tabella. Quindi si consiglia a DTO, VO di portare i dati da DAO al front-end. Utilizzare diversi tipi di mapper disponibili sul mercato. Uno degli esempi è orika mapper.

Answer 2

Ci sono casi in cui gli oggetti dati corrispondono esattamente agli oggetti che l'utente manipola sullo schermo. D'altra parte, ci sono casi in cui l'utente lavora su oggetti che sono derivati ​​e/o che influenzano più in base a una logica di business. Molte applicazioni di reporting sono esempi di quest'ultimo.

A seconda del dominio e del profilo utente, la frequenza dei casi di corrispondenza dati/oggetti UI è alta o bassa. Dovresti definire modelli separati quando necessario e il costo di mantenerli attraverso le modifiche nel tuo progetto. Quindi, i modelli eccessivamente separati sono cattive pratiche. D'altra parte, se insisti a trasmettere modelli di dati ovunque, la tua logica aziendale o il codice dell'interfaccia utente potrebbero non essere molto puliti.

La decisione di separare gli oggetti del livello di accesso ai dati e quelli passati all'interfaccia utente dipende anche dagli strumenti che si sta utilizzando. Ad esempio, nei casi in cui i controller si serializzano in JSON in modo statico (*), si potrebbe scegliere di definire le classi per ogni differente attraversamento dell'albero (da utilizzare) del grafico dell'oggetto. D'altra parte, gli stessi oggetti potrebbero essere utilizzabili con un'interfaccia utente basata su JSP.

(*) Un esempio è Jackson, che utilizza annotazioni che stabiliscono il modo in cui l'oggetto (grafico) viene serializzato in un albero. Esistono mezzi per limitare l'albero - utili a prevenire perdite di dati indesiderate - tuttavia la loro praticità e manutenibilità è limitata, nei casi che ho incontrato.