10

As far as I've learned, the IRepository should contain CRUD. Then we inherit this IRepository in our other Interfaces like IProductand implement IProductconcrete class ProductRepository, with methods like GetAllProducts(), Top5Products().

We could also do the same with n-tier architecture. like, Creating DAL Class Library and in it define a class Product with methods like GetAllProducts(), Top5Products().

In both DAL.Product and Repo.ProductRepository classes we initialize DB Context of Entity Framework and query our relevant data.

The calling is similar in both Repo.ProductRepository or DAL.Product methods from BLL

In view of these similarities, my question what is the benefit of Repos? I can do the same with much ease using n-tier architectures with (Controller ,BLL Class Library, DAL Class Library).

M. Arslan
  • 109
  • 1
  • 4
  • @Neil I think that OP is familiar with DAL and asks whether repositories are just other interfaces for doing the same things or if it is more – Christophe Sep 13 '18 at 07:20
  • @Christophe exactly, I am confused on this. If we could do the same in DAL why use repo pattern? – M. Arslan Sep 13 '18 at 07:27

2 Answers2

8

My understanding is:

  • DAL (Data Access Layer) refers to a layer in your software that sits between your persistence technology and your application logic. Its purpose is to keep data access concerns separate from the rest of your application concerns. It is a general concept.

  • Repository is a concept from DDD (Domain Driven Design).

In DDD, a Repository is responsible for encapsulating all data access concerns for a given Aggregate. This comes with the responsibility of ensuring consistency during reads and writes of the Aggregate. And an Aggregate is a grouping of related Entities (eg, Product, Store, etc).

So, a Repository is specifically aware of its Aggregate's persistence and consistency concerns. Your general DAL will most likely be composed of specific Repositories

TL;DR;

  • DAL is a general term for abstracting away Data Access concerns.
  • Repository is a similar, but more specific, concept from DDD.
  • Your DAL will likely be composed of several Repositories.
Community
  • 1
MetaFight
  • 11,549
  • 3
  • 44
  • 75
  • 5
    ***Repository*** is also a term that is used more generically outside of DDD to refer to *an in-memory collection of objects that mirrors database records.* In this context, it sits *between* the DAL and the Business Logic Layer. See https://martinfowler.com/eaaCatalog/repository.html – Robert Harvey Sep 13 '18 at 21:22
  • 1
    Why does everyone try to give DDD credit for everything?! – TheCatWhisperer Sep 13 '18 at 22:06
  • 1
    Today I learned :P – MetaFight Sep 14 '18 at 11:46
2

You are comparing two different and complementary concepts:

  • The Data Access Layer is an architectural layer that intends to abstract access to data. It doesn't say how the access shall be abstracted.
  • The Repository is a specific pattern that belongs to the DAL (see list of patterns at the end of this link). It says exactly how to abstract a specific access to data: by offering a collection like interface to the data store.

The DAL in your example

Interestingly, in your example of class library, DAL.Product seems to be a repository. So it's normal that you do not really see a difference: from the implementation point of view it's the same (in this specific case).
But it doesn't have to; A DAL could be implemented differently, for example :

  • active records that rely on a database abstraction layer.
  • anaemic domain objects (attention, anti-pattern!) obtained from a row data gateway
  • or, why not, domain objects obtained from different query objects, where each query would implement a particular way to retrieve the object
  • repositories
  • a mix of all those

What is different for the repository

The concept of repository is independent of the architectural model and the implementation. You do not need to think into layers or database. All you need to know when you design your domain, is that your objects are in repositories that are a special kind of collection witch offers persistence. This makes them very suitable for domain design and explains why they are a key element of Domain Driven Design.

In DDD, the repositories have some more rules to respect: they give access to aggregates (an independent entity, or a group of related entities dependent of an aggregate root) and there is a single repository per aggregate.

Christophe
  • 74,672
  • 10
  • 115
  • 187