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

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 CustomerGatewayclasse 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.

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 diverso intento / significato e implementazione risultante.

Un repository "si comporta come una raccolta, ad eccezione di una più complessa capacità di interrogazione" [ Evans, Domain Driven Design ] e può essere considerato un "oggetto nella facciata della memoria" ( discussione sul repository )

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

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

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

Il repository sembra molto generico, non mostrando 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).

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 "Services Layer" 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.

Data Mapper vs Table Data Gateway Per farla breve:

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

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 accoppiamento o no 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 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.

Di seguito è solo la mia comprensione.

TableGateWay / RowDataGateWay : in questo contesto, Gateway fa riferimento a un'implementazione specifica che ha ogni mappatura "oggetto dominio" su ciascun "gateway oggetto dominio". Ad esempio, se abbiamo Person , avremo un PersonGateway per memorizzare 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, a seconda che si passi 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 di persistenza 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 deve avere operazioni CRUD supportate per ogni oggetto di dominio. Disaccoppia l'origine dati e il modello di dominio.