Why use design patterns ?
Earlier, software developers don’t follow any standard pattern for accessing the database during the software development where the business logic and database are tightly coupled together which makes the application code complex to test, extend and scale the application.
Directly accessing the database logic from the business logic makes it difficult to unit test the business logic layer and repetitive data access code through the business layer which breaks the principle of “Don’t Repeat yourself”.
So, to overcome these challenges and difficulties in the traditional way of mixing up the business layer and database layer various design patterns were introduced and followed by the software developers for writing clean and scalable code by separating the business logic layer and database logic in the software development process.
Repository Design Pattern:
A repository Design Pattern is a kind of repository that is portable and can process multi-millions of rows without affecting the server performance. It is being used, proven, and tested in the production environment.
For further understanding, a “Repository Design Pattern” is a software design pattern and practice which is implemented as an additional layer between your application and your database. Through the repository, you are managing how the data is being manipulated from/to the database.
It is now an industry standard to always use a repository pattern when developing an application (specifically for database connectivity). It is a widely known pattern and is highly recommended for everyone and/or any form of software development.
Following this design pattern, it helps in separating the database logic from the business logic which helps in writing more clean and scalable code in terms of software development. In the Repository pattern, the domain entities, the data access logic, and the business logic talk to each other using interfaces.
Implementation of Repository Pattern:
A repository pattern is implemented by creating an interface for abstraction and a class for implementing those interface methods.
Here, is a repository for creating, Delete, Update and Read operations in ASP.NET Web API.
Repository Interface:
In this interface, the required database operations are listed as interface methods which will be implemented later.
IUserRepository.cs
Understanding the Responsibility of each method:
- GetAll(): This method is used to return all the user entities as an enumerable collection (such as a generic List).
- GetById(): This method accepts an integer parameter representing a User ID (UserID is an integer column in the User table in the database) and returns a single User entity matching that User ID.
- Insert(): This method accepts a User object as the parameter and adds that User object to the Users DbSet.
- Update(): This method accepts a User object as a parameter and marks that User object as a modified User in the DbSet.
- Delete(): This method accepts an UserID as a parameter and removes that User entity from the User DbSet.
- Save(): This method saves changes to the UserDB database.
Repository Class:
In this class, the created interface methods are implemented here for writing the actual database logic required.
UserRespository.cs
Here every necessary database logic is implemented for the application which can be used by the controller for operations like create, update, delete and read.
User Controller:
Here is a Web API controller for performing create, update, read and delete operations in Users using the repository created with the database logic for create, update, delete and read.
UserController.cs
Conclusion:
Above is the implementation of the repository design pattern where the business logic layer and database logic layer are separated.