Utilizzo del livello di accesso ai dati a 3 livelli

Question

Utilizzo del livello di accesso ai dati a 3 livelli

#1 da (2 voti)

0

Come ho capito nell'architettura a 3 livelli, il livello di presentazione parla con il livello della logica aziendale, che parla con il livello di accesso ai dati. E, idealmente, il livello aziendale non conosce nulla sulla presentazione e il livello di accesso ai dati non conosce nulla sul livello aziendale. Voglio scrivere le classi per fare il lavoro di database CRUD che sono separati dalle classi di dominio. Ad esempio, Foo è una classe di dominio nel livello aziendale e voglio scrivere una classe PersistFoo che prenda gli oggetti Foo e CRUD. La mia domanda è (in qualche modo teorica?) Su quale livello è PersistFoo? Logicamente, appartiene al livello dati per me. Tuttavia, PersistFoo dipende da Foo (ad esempio legge il database e converte i dati in oggetti Foo e li restituisce). Quindi, se PersistFoo si trova nel livello dati, dipende dal livello aziendale, il che viola che i livelli inferiori non dovrebbero dipendere da livelli superiori.

architecture layers architectural-patterns

posta drg 06.01.2017 - 19:36

fonte

1 risposta

Leggi altre domande sui tag architecture layers architectural-patterns

Come mostrare un sottosistema come un'applicazione mobile in un diagramma dei casi d'uso Dovresti taggare / contrassegnare un oggetto o spostarlo in una collezione diversa?

score 2 · Accepted Answer

Ci sono un paio di approcci che puoi prendere qui, a seconda della complessità della tua applicazione.

Se si tratta di una semplice applicazione a 3 livelli in cui il tuo oggetto dominio mappa (o esattamente) le tue tabelle di database, allora puoi pensare al tuo oggetto dominio come trasversale, il che significa che possono essere messi nel loro assembly e condivisa tra i livelli di accesso business e dati. Se la tua applicazione vuole semplicemente eseguire operazioni CRUD su oggetti Foo, perché aggiungere strati di astrazione non necessari. Non over engineer :) Avrai comunque le dipendenze che vanno in pila (presentation - > service - > database) e non più.

Un'altra possibilità è fare qualcosa come ho fatto nel mio attuale lavoro. Abbiamo un database legacy mal progettato in cui il modello di dati è molto diverso rispetto al modello di dominio. Alcuni oggetti di dominio provengono da più oggetti di dati. Quindi, ciò che facciamo è che abbiamo sia dominio che oggetti dati e il livello aziendale è l'unico livello che dipende da entrambi. Il livello di presentazione dipende dagli oggetti del dominio e il livello del database dipende dagli oggetti dati. Ci sono servizi di traduzione nel livello aziendale.