Pattern del repository e creazione dell'oggetto DAL

La mia comprensione è:

• DAL (livello di accesso ai dati) fa riferimento a un layer nel tuo software che si trova tra la tua tecnologia di persistenza e la logica dell'applicazione. Il suo scopo è di mantenere i problemi di accesso ai dati separati dal resto dei problemi delle applicazioni. È un concetto generale .

• Repository è un concetto di DDD (Domain Driven Design).

In DDD, un Repository è responsabile dell'incapsulamento di tutti i problemi di accesso ai dati per un determinato aggregato . Ciò comporta la responsabilità di garantire la coerenza durante le letture e le scritture dell'Agregato. E un aggregato è un raggruppamento di entità correlate (ad esempio Product , Store , ecc.)

Quindi, un repository è specificamente consapevole dei problemi di persistenza e coerenza di Aggregate. Il DAL generale molto probabilmente sarà composto da specifici repository

TL; DR;

• DAL è un termine generale per l'astrazione dei problemi di accesso ai dati.
• Repository è un concetto simile, ma più specifico, di DDD.
• Il tuo DAL sarà probabilmente composto da diversi repository.

Stai confrontando due concetti diversi e complementari:

• Il livello di accesso ai dati è un strato architettonico che intende l'accesso astratto ai dati. Non dice come l'accesso deve essere astratto.
• Il Repository è un modello specifico che appartiene al DAL (vedi l'elenco dei pattern alla fine di questo collegamento ). Dice esattamente come astrarre un accesso specifico ai dati: offrendo una collezione come interfaccia all'archivio dati.

Il DAL nel tuo esempio

È interessante notare che, nel tuo esempio di libreria di classi, DAL.Product sembra essere un repository. Quindi è normale che tu non veda davvero una differenza: dal punto di vista dell'implementazione è la stessa cosa (in questo caso specifico).
Ma non è necessario; Un DAL potrebbe essere implementato in modo diverso, ad esempio:

• record attivi che si basano su un livello di astrazione del database.
• oggetti di dominio anemico (attenzione, anti-pattern!) ottenuti da un row gateway dati
• o, perché no, oggetti di dominio ottenuti da diversi oggetti di query, in cui ogni query implementerebbe un modo particolare per recuperare l'oggetto
• repository
• un mix di tutti quelli

Che cosa è diverso per il repository

Il concetto di repository è indipendente dal modello architettonico e dall'implementazione. Non è necessario pensare in livelli o database. Tutto ciò che devi sapere quando progetti il tuo dominio, è che i tuoi oggetti sono in repository che sono un tipo speciale di raccolta che offre persistenza. Questo li rende molto adatti alla progettazione di domini e spiega perché sono un elemento chiave di Domain Driven Design .

In DDD, i repository hanno alcune regole da rispettare: danno accesso agli aggregati (un'entità indipendente o un gruppo di entità correlate dipendenti da una radice aggregata) e vi è un singolo repository per aggregato.

Il modello di repository è una forma più sofisticata del DAL.

Se leggi su Inversion of Control (IoC), Dependency injection (DI) e unit test, diventerà chiaro.