In che modo i livelli di interfaccia dell'applicazione e del database interagiscono ai loro confini?

Question

In che modo i livelli di interfaccia dell'applicazione e del database interagiscono ai loro confini?

#1 da (1 voti)
#2 da (1 voti)
#3 da (0 voti)

5

Stavo guardando uno dei video di Uncle Bob e ha richiamato l'interfaccia del database Strato. Aveva questo diagramma che lo mostrava:

QuestefreccemostranocheilDBInterfaceLayerèaconoscenzaechiamaillivelloApplicationeDatabase,manonviceversa.

IlDBInterfaceLayercontiene"record di dati". Queste sono "classi" che hanno il nome della tabella e i campi delle colonne. Questi sono quelli che di solito chiamano DTO. Ma questi record di dati hanno tutti i campi pubblici e nessun / pochi metodi.

Il livello dell'interfaccia DB è responsabile dell'acquisizione dei dati dal database, del popolamento dei "record di dati" e dell'implementazione di un'interfaccia nel livello applicazione in questo modo:

Sono un po 'confuso perché non ho mai sentito parlare di questa separazione prima. Ogni progetto su cui ho lavorato utilizza i DTO nella vista apparentemente sbagliata (almeno secondo il video di Uncle Bob).

Inoltre, non ho mai lavorato a un progetto in cui il DB Interface Layer chiama Application Layer. È sempre il livello applicazione che richiede il livello di interfaccia DB per informazioni. Ad esempio, utilizzando un DAO.

Ma sta iniziando a dare un senso. Ogni volta che uso l'ibernazione mi sto sempre tirando i capelli perché cerco di rendere le DTO più OO e la biblioteca mi combatte sempre.

Quindi, suppongo che cosa sto cercando di fare è, come appare il codice sul / al confine tra l'applicazione e il livello di interfaccia del database? Ad esempio, in che modo l'applicazione ottiene l'implementazione dell''attuazione del gateway dell'ordine? L'implementazione del gateway ordini è un DAO? Non ho una visione chiara di come il POS può utilizzare il Gateway ordine rispetto a come / quando il Gateway ordini viene popolato con i dati.

programming-practices design-patterns layers enterprise-architecture

posta Daniel Kaplan 29.03.2013 - 23:09

fonte

3 risposte

Leggi altre domande sui tag programming-practices design-patterns layers enterprise-architecture

Considerazioni sulle prestazioni durante l'utilizzo di Go for my project Più chiavi SSH per diverse organizzazioni

score 1 · Answer 1

Penso che tu abbia interpretato le foto in modo sbagliato! Le frecce non rappresentano la direzione della chiamata secondo me.

Quando si guarda la seconda immagine, è ovvio che l'implementazione del gateway ordini implementa l'interfaccia del gateway dell'ordine e gli oggetti di tipo Gateway dell'ordine vengono utilizzati dal tipo di client POS. Quindi la direzione effettiva della chiamata è dall'alto verso il basso come ci si aspetterebbe.

Questa è solo un'applicazione del modello di strategia per separare la struttura del database che si trova all'interno del livello DB I / F dall'interfaccia utilizzata dal livello dell'applicazione. Se non avessi il livello DB I / F, il tuo livello di applicazione probabilmente accederà direttamente a strutture DB specifiche, il che non sarebbe sicuramente il modo giusto per essere flessibile con la tecnologia DB.

Modifica:

Bene, pensiamo alla nozione di DTOs: quelli sono oggetti contenenti determinate quantità di dati (comportamento no ) aggregati per uno scopo specifico, di solito per spingerli attraverso la rete in sistemi distribuiti . Anche se vengono utilizzati in questo contesto come tabella degli ordini e tabella degli elementi pubblicitari, non vi è alcuna contraddizione nell'usare DTO per le viste poiché le viste sono generalmente associate solo ai dati.

Lo scopo del DAO è in primo luogo quello di incapsulare il più possibile dalle tecnologie di origine dei dati. Poiché DAO non è solo un singolo oggetto, ma un modello che include l'interfaccia e la sua implementazione, è possibile mappare il modello DAO direttamente sull'interfaccia Order Gateway e su Order Gateway Implementation, con conseguente assenza di dipendenze dal livello dell'applicazione a specifiche strutture di dati. p>

score 1 · Answer 2

Vorrei aggiungere che mentre le frecce non rappresentano la direzione della chiamata, ciò che rappresentano fanno è la dipendenza .

Introducendo l'interfaccia "Order Gateway" nell'Application Layer e implementando quell'interfaccia nel DB Layer, invece che Application Layer che prende una dipendenza dal livello DB, sarà l'opposto; abbiamo invertito la direzione di dipendenza.

Questa è una strategia di disaccoppiamento chiamata Inversione di dipendenza che consente di sostituire il livello DB senza modificare il Livello applicazione.

score 0 · Answer 3

Penso che la tua confusione derivi dal termine "Interfaccia".

Esiste un'interfaccia DatabaseInterface e un'interfaccia DatabaseInterface.

Il livello Applicaton conosce e utilizza l'interfaccia DatabaseInterface per ottenere dati dal database in dto-s o daimain-objects.

DatabaseInterface - Implementazione implementa l'interfaccia DatabaseInterface e sa / usa dto-s.

Molti sviluppatori lo chiamano modello del repository

Se le frecce nella tua foto significano "usi o chiamate", quindi la freccia da "Interfaccia" a "ordina" nella seconda immagine ha la direzione sbagliata .