Patrón de repositorio vs Creación de objetos DAL

Por lo que he aprendido, el IRepositorydebería contener CRUD. Entonces heredamos esta IRepositoryen nuestras otras interfaces como IProducte implementar IProductclase concreta ProductRepository, con métodos como GetAllProducts(), Top5Products().

También podríamos hacer lo mismo con la arquitectura de n niveles. como, Creación DAL Class Libraryy en ella definir una clase Productcon métodos como GetAllProducts(), Top5Products().

En ambos DAL.Producty Repo.ProductRepositoryclases de inicializar DB Contextde Entity Frameworky consulta nuestros datos pertinentes.

La llamada es similar en ambos métodos Repo.ProductRepositoryo DAL.ProductdesdeBLL

En vista de estas similitudes, mi pregunta ¿cuál es el beneficio de Repos? Puedo hacer lo mismo con mucha facilidad utilizando arquitecturas de n-capas con ( Controller, BLL Class Library, DAL Class Library).

Mi entendimiento es:

• DAL (Data Access Layer) se refiere a una capa en su software que se encuentra entre su tecnología de persistencia y la lógica de su aplicación. Su propósito es mantener las preocupaciones de acceso a datos separadas del resto de las preocupaciones de su aplicación. Es un concepto general .

• El repositorio es un concepto de DDD (Diseño controlado por dominio).

En DDD, un repositorio es responsable de encapsular todas las preocupaciones de acceso a datos para un agregado determinado . Esto conlleva la responsabilidad de garantizar la coherencia durante las lecturas y escrituras del Agregado. Y un agregado es una agrupación de entidades relacionadas (por ejemplo, Product, Store, etc.).

Por lo tanto, un repositorio es específicamente consciente de las preocupaciones de persistencia y consistencia de su agregado. Su DAL general probablemente estará compuesto por repositorios específicos

TL; DR;

• DAL es un término general para abstraer las preocupaciones de acceso a datos.
• El repositorio es un concepto similar, pero más específico, de DDD.
• Su DAL probablemente estará compuesto por varios repositorios.

Estás comparando dos conceptos diferentes y complementarios:

• La capa de acceso a datos es una capa arquitectónica que tiene la intención de abstraer el acceso a los datos. No dice cómo se debe abstraer el acceso.
• El repositorio es un patrón específico que pertenece al DAL (consulte la lista de patrones al final de este enlace ). Dice exactamente cómo abstraer un acceso específico a los datos: ofreciendo una colección como interfaz para el almacén de datos.

El DAL en tu ejemplo

Curiosamente, en su ejemplo de biblioteca de clases, DAL.Productparece ser un repositorio. Por lo tanto, es normal que realmente no veas una diferencia: desde el punto de vista de la implementación, es lo mismo (en este caso específico).
Pero no tiene que hacerlo; Un DAL podría implementarse de manera diferente, por ejemplo:

• registros activos que se basan en una capa de abstracción de base de datos.
• objetos de dominio anémico (¡atención, antipatrón!) obtenidos de una pasarela de datos
• o, por qué no, objetos de dominio obtenidos de diferentes objetos de consulta, donde cada consulta implementaría una forma particular de recuperar el objeto
• repositorios
• una mezcla de todos esos

¿Qué es diferente para el repositorio?

El concepto de repositorio es independiente del modelo arquitectónico y la implementación. No necesita pensar en capas o bases de datos. Todo lo que necesita saber cuando diseña su dominio es que sus objetos están en repositorios que son un tipo especial de colección que ofrece persistencia. Esto los hace muy adecuados para el diseño de dominios y explica por qué son un elemento clave del diseño dirigido por dominios .

En DDD, los repositorios tienen algunas reglas más que respetar: dan acceso a los agregados (una entidad independiente o un grupo de entidades relacionadas que dependen de una raíz agregada) y hay un único repositorio por agregado.