Qual è la differenza tra i pattern Data Mapper, Table Data Gateway (Gateway), Data Access Object (DAO) e Repository?

Question

Sto cercando di rispolverare le mie abilità nel design pattern e sono curioso di sapere quali sono le differenze tra questi pattern? Tutti sembrano essere la stessa cosa: incapsulare la logica del database per un'entità specifica, quindi il codice chiamante non ha conoscenza del livello di persistenza sottostante. Dalla mia breve ricerca in genere tutti implementano i metodi CRUD standard e sottraggono i dettagli specifici del database.

Oltre alle convenzioni di denominazione (ad es. CustomerMapper vs. CustomerDAO vs. CustomerGateway vs. CustomerRepository), qual è la differenza, se presente? Se c'è una differenza, quando sceglieresti l'uno rispetto all'altro?

In passato avrei scritto un codice simile al seguente (semplificato, naturalmente - normalmente non avrei usato proprietà pubbliche):

public class Customer
{
    public long ID;
    public string FirstName;
    public string LastName;
    public string CompanyName;
}

public interface ICustomerGateway
{
    IList<Customer> GetAll();
    Customer GetCustomerByID(long id);
    bool AddNewCustomer(Customer customer);
    bool UpdateCustomer(Customer customer);
    bool DeleteCustomer(long id);
}

e hanno una classe CustomerGateway che implementa la logica specifica del database per tutti i metodi. A volte non userei un'interfaccia e rendere statici tutti i metodi su CustomerGateway (lo so, lo so, lo rende meno testabile) in modo da poterlo chiamare come:

Customer cust = CustomerGateway.GetCustomerByID(42);

Questo sembra essere lo stesso principio per i pattern Data Mapper e Repository; il modello DAO (che è la stessa cosa di Gateway, penso?) sembra incoraggiare anche gateway specifici del database.

Mi sto perdendo qualcosa? Sembra un po 'strano avere 3-4 modi diversi di fare la stessa cosa esatta.

Answer 1

I tuoi termini di esempio; DataMapper, DAO, DataTableGateway e Repository, hanno tutti uno scopo simile (quando ne uso uno, mi aspetto di recuperare un oggetto Cliente), ma intenti / significato diversi e implementazione risultante.

Un repository " si comporta come una raccolta, tranne che con una capacità di query più elaborata " [ Evans, Domain Driven Design ] e può essere considerato un " oggetti nella facciata della memoria " ( Discussione sul deposito )

Un DataMapper " sposta i dati tra oggetti e un database mantenendoli indipendenti l'uno dall'altro e il mappatore stesso " ( Fowler, PoEAA, Mapper )

Un TableDataGateway è " un Gateway (oggetto che incapsula l'accesso a un sistema esterno o risorsa) a una tabella di database. Un'istanza gestisce tutte le righe nella tabella " ( Fowler, PoEAA, TableDataGateway )

Un DAO " separa l'interfaccia client di una risorsa dati dai suoi meccanismi di accesso ai dati / adatta l'API di accesso di una risorsa dati specifica a un'interfaccia client generica " consentendo "Meccanismi di accesso ai dati per cambiare indipendentemente dal codice che utilizza i dati" ( Modelli Sun )

Il repository sembra molto generico, non rivelando alcuna nozione di interazione con il database. Un DAO fornisce un'interfaccia che consente di utilizzare diverse implementazioni di database sottostanti. Un TableDataGateway è specificamente un involucro sottile attorno a un singolo tavolo. Un DataMapper funge da intermediario consentendo all'oggetto Model di evolversi indipendentemente dalla rappresentazione del database (nel tempo).

Answer 2

C'è una tendenza nel mondo del design del software (almeno, mi sento così) a inventare nuovi nomi per cose e schemi ben noti. E quando abbiamo un nuovo paradigma (che forse differisce leggermente dalle cose già esistenti), di solito viene fornito con un intero set di nuovi nomi per ogni livello. Quindi "Business Logic" diventa " Livello servizi " solo perché diciamo che facciamo SOA e DAO diventa Repository solo perché diciamo che facciamo DDD (e ognuno di questi non è in realtà qualcosa di nuovo e unico, ma ancora: nuovi nomi per concetti già noti raccolti nello stesso libro) . Quindi non sto dicendo che tutti questi paradigmi e acronimi moderni significino ESATTAMENTE la stessa cosa, ma in realtà non dovresti essere troppo paranoico al riguardo. Principalmente questi sono gli stessi schemi, solo di famiglie diverse.

Answer 3

Mappatore dati vs Table Data Gateway Riassumere:

il Mapper dati riceverà l'oggetto modello di dominio (Entity) come parametro e lo utilizzerà per implementare le operazioni CRUD

Table Data Gateway riceverà tutti i parametri (come primitivi) per i metodi e non saprà nulla sull'oggetto Modello di dominio (Entità).

Alla fine entrambi fungeranno da mediatori tra gli oggetti in memoria e il database.

    

Answer 4

Hai un buon punto. Scegli quello con cui hai più familiarità. Mi piace sottolineare alcune cose che possono aiutare a chiarire.

Il Table Data Gateway viene utilizzato principalmente per una singola tabella o vista. Contiene tutte le selezioni, gli inserti, gli aggiornamenti e le eliminazioni. Quindi il cliente è una tabella o una vista nel tuo caso. Pertanto, un'istanza di un oggetto gateway dati tabella gestisce tutte le righe nella tabella. Di solito questo è correlato a un oggetto per tabella del database.

Mentre Data Mapper è più indipendente da qualsiasi logica di dominio ed è meno accoppiato (anche se credo che ci sia o meno accoppiamento). È semplicemente un livello intermedio per trasferire i dati tra oggetti e un database mantenendoli indipendenti l'uno dall'altro e dal mappatore stesso.

Quindi, in genere in un mapper, vedi metodi come inserire, aggiornare, eliminare e nel gateway dati della tabella troverai getcustomerbyId, getcustomerbyName, ecc.

L'oggetto di trasferimento dati differisce dai due modelli precedenti, principalmente perché è un modello di distribuzione e non un modello di origine dati come sopra due modelli. Usalo principalmente quando lavori con l'interfaccia remota e devi rendere le tue chiamate meno loquaci poiché ogni chiamata può diventare costosa. Di solito, quindi, progettare un DTO che può essere serializzato via cavo in grado di riportare tutti i dati al server per applicare ulteriori regole o elaborazioni aziendali.

Non sono molto esperto nel modello di repository in quanto non ho avuto la possibilità di usare fino ad ora ma guarderò le risposte degli altri.

Answer 5

Di seguito è solo la mia comprensione.

TableGateWay / RowDataGateWay : In questo contesto, Gateway sta riferendo un'implementazione specifica che ha ciascun "oggetto di dominio" mappatura su ciascun "gateway oggetto dominio". Ad esempio, se abbiamo Persona , avremo un PersonGateway per archiviare l'oggetto di dominio Person nel database. Se abbiamo Persona, Dipendente, Cliente, ecc. Avremo PersonGateway, EmployeeGateway e CustomerGateway. Ogni gateway avrà una funzione CRUD specifica per quell'oggetto e non ha nulla a che fare con altri gateway. Non esiste un codice / modulo riutilizzabile qui. Il gateway può essere ulteriormente suddiviso in RowDataGateway o TableGateway, dipende se si passa un "id" o un "oggetto". Il gateway viene in genere confrontato con il record attivo. Collega il tuo modello di dominio allo schema del database.

Repository / DataMapper / DAO : sono la stessa cosa. Si riferiscono tutti al livello Persistence che trasferisce le entità del database al modello di dominio. A differenza del gateway, il repository / DataMapper / DAO nasconde l'implementazione. Non sai se c'è PersonGateway dietro Person. Potrebbe, o no, non ti interessa. Tutto quello che sai è che devono essere supportate operazioni CRUD per ogni oggetto di dominio. Disaccoppia l'origine dati e il modello di dominio.