Repository Design Pattern
First and foremost, what are the design patterns and why we need them? someone might be having such questions in the mind.
Writing quality production code consistently is not easy without some foundational principles underlying. The common scenario from developers’ perspective is, they more often fall into the trap of writing their code in a generic manner unwarranted extensibility thinking it produces an attractive source. But the complexity running through their code base leads to improbable scenarios which reduces the readability and maintainability. There comes the need of design patterns.
Now let me show how one of the design pattern called as “Repository Design Pattern” works. Here, I am going to discuss it in the context of Entity Framework and ASP.NET MVC. Repository design pattern can be identified as one of the most using design patterns in the real time applications.
Repositories can be identified as classes or components that encapsulate the required logic to provide centralized common data access functionality which ultimately provides better maintainability and decoupling the infrastructure to access databases from the domain model layer.
As you can seen in the Figure 1, database context directly connects to whatever the databse server. There, any change in the data access layer imapcts to the controller code. To reduce such impcts to the code base, we can implement a middle layer which provides the communication between the two layers mentioned.
We can implement this pattern using one of the following methods.
- Having one repository per model (Non-generic)
- Having a generic repository used by all the entities
- Having one repository per model along with a generic repository for the common functions
Let me show you how a generic class works. It is basically consisted of all the CRUD methods. There, any other entities can be used generic class’s methods. The generic repository will look as Figure 3.
Here, T Entity is the generic type that can be any entity of the database. It allows you to specify an arbitrary type without specifying a concrete type. All the operations will be applied on this T Entity type only.
Next task is to create a generic Unit of Work class. Why we need that? Unit of Work can be referred as a single transaction that invloves multiple operations of CRUD along with dispose, commit and rollback. This means, one unit of work executes one single database transaction which involves all the said operations. Using a Unit of Work class makes the task easy because calling a single method, performs multiple operations in one single controller method.
As per the above figure, when one operation is excuted, the changes will be automatically applied for both repositories. Ultimately Unit of work class can be written as following coding snippet. It will receive the instance of the Dbcontext and furthermore it will generate the respective required repository instances and pass the same DbContext to both repositories.
So hope this article gives you a kick start of trying Repository Design Pattern along with your code base.
I hope you enjoyed reading it! :)
