Repository Pattern

In simple terms, a repository basically works as a mediator between our business logic layer and our data access layer of the application. Sometimes, it would be troublesome to expose the data access mechanism directly to business logic layer, it may result in redundant code for accessing data for similar entities or it may result in a code that is hard to test or understand.
To overcome these kinds of issues, and to write an Interface driven and test driven code to access data, we use Repository Pattern. The repository makes queries to the data source for the data, thereafter maps the data from the data source to a business entity/domain object, finally and persists the changes in the business entity to the data source.
According to MSDN, a repository separates the business logic from the interactions with the underlying data source or Web service. The separation between the data and business tiers has three benefits:

• It centralizes the data logic or Web service access logic.
• It provides a substitution point for the unit tests.
• It provides a flexible architecture that can be adapted as the overall design of the application evolves.

 Repository Pattern separates the data access logic and maps it to the entities in the business logic. It works with the domain entities and performs data access logic. In the Repository pattern, the domain entities, the data access logic and the business logic talk to each other using interfaces. It hides the details of data access from the business logic. In other words, business logic can access the data object without having knowledge of the underlying data access architecture. For example, in the Repository pattern, business logic is not aware whether the application is using LINQ to SQL or ADO.NET Entity Model ORM. In the future, underlying data sources or architecture can be changed without affecting the business logic.

Repository Pattern

•  Adds a separation layer between data and domain layers. Avoids duplication of data access code logic including direct access to database, ORM, WCF services, XML etc.
• Mediator between BAL and DAL.     BAL only interacts with Repository and is unaware of   DAL. 
• Data access logic is defined in repository rather than being mixed with BAL or UI Layer, so repository can be reused across different BAL Classes.
• Access the repository from the business layer through the Interface, this helps in creating decoupled architecture and helps in Unit Testing. Since the repository is accessed by BAL using interfaces rather then concrete classes, we can easily point the interface to a different implementation without changing any of the BAL layer logic. This also helps in mocking as we can create a mock object for the repository.

          1. Define a Student Class.
              Public Class Student
               {
                  public string FirstName {get; set;}
               }

         2.   Define an Interface for the Student Repository
               interface IRepository
               {
                   void Insert (Student s);
                   IEnumerable<Student> GetAllStudents();
              }

             Different implementations of interface can implement these interface methods differently.

     3.  Public Class SQLRepository : IRepository
           {
                    public void Insert(Student s)
                     {
                         // insert logic here.
                      }
           }

Now, if a Client wants to use any repository class which implements the IRepository interface, then it needs to reference just the IRepository interface.(eg. like in controller, we refer to the interface repository class.)

• When the BAL accesses the repository, the interface is used. This way the business layer can use any object that implements the contracts defined in the repository interface.
• With Repository, there is no need to deal with database concerns like connections, commands, cursors, or readers etc.
• Mostly we use database context directly in the controller. This creates the tight coupling between controller and data access layers and it violets the Single Responsibility Principle and Open Close Principle.  Any change related to the data access layer can break the controller code. With repository, we separate the controller and the data access layer(database context). Hence it acts as a abstraction layer between controller and database context.
• Unit Tests can use a custom persistence layer to facilitate testing.
• Repository mediates between domain and data mapping layers, acting like an in-memory domain object collection.
• In repository pattern, the domain entities, the data access logic and the business logic talk to each other using interfaces. It hides the data access logic from the business logic. The underlying data access logic/layer/source or architecture can be changed without affecting the business logic.
• Repositories should always return IEnumerable. They should not return IQueryable, because this gives impression to the upper layers like Services and Controllers that they can reuse this IQueryable to build queries, Which is completely against the idea of repositories in the first place. The repositories should encapsulate your queries so that you do not repeat them.

  

Posted in: REPOSITORY