Modello di repository vs Creazione oggetto DAL

Per quanto ho imparato, IRepositorydovrebbe contenere CRUD. Poi abbiamo ereditato questo IRepositorynelle nostre altre interfacce come IProducte attuare IProductclasse concreta ProductRepository, con metodi come GetAllProducts(), Top5Products().

Potremmo anche fare lo stesso con l'architettura di livello n. come, creazione DAL Class Librarye in essa definire una classe Productcon metodi come GetAllProducts(), Top5Products().

In entrambi DAL.Producte Repo.ProductRepositoryle classi inizializziamo DB Contextdi Entity Frameworke interrogare i nostri dati rilevanti.

La chiamata è simile in entrambi Repo.ProductRepositoryo in DAL.Productmetodi daBLL

Alla luce di queste somiglianze, la mia domanda qual è il vantaggio di Repos? Posso fare lo stesso con molta facilità utilizzando architetture n-tier con ( Controller, BLL Class Library, DAL Class Library).

La mia comprensione è:

• DAL (Data Access Layer) si riferisce a un livello nel software che si colloca tra la tecnologia di persistenza e la logica dell'applicazione. Il suo scopo è quello di mantenere separati i problemi di accesso ai dati dal resto dei problemi relativi alle 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 . Questo ha la responsabilità di garantire coerenza durante le letture e le scritture dell'Aggregato. E un aggregato è un raggruppamento di entità correlate (ad esempio, Product, Store, ecc).

Quindi, un repository è specificamente consapevole delle preoccupazioni di persistenza e coerenza del suo aggregato. Molto probabilmente il tuo DAL generale sarà composto da specifici repository

TL; DR;

• DAL è un termine generale per sottrarre preoccupazioni relative all'accesso ai dati.
• Il repository è un concetto simile, ma più specifico, di DDD.
• Probabilmente il tuo DAL sarà composto da più repository.

Stai confrontando due concetti diversi e complementari:

• Il livello di accesso ai dati è un livello architettonico che intende astrarre l'accesso ai dati. Non dice come si debba sottrarre l'accesso.
• Il repository è un modello specifico che appartiene al DAL (vedere l'elenco dei modelli alla fine di questo collegamento ). Indica esattamente come astrarre un accesso specifico ai dati: offrendo una raccolta come interfaccia all'archivio dati.

Il DAL nel tuo esempio

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

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

Ciò che è diverso per il repository

Il concetto di repository è indipendente dal modello architettonico e dall'implementazione. Non è necessario pensare a 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 la strega offre perseveranza. Questo li rende molto adatti per la progettazione del dominio e spiega perché sono un elemento chiave del Domain Driven Design .

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