Repository Design Pattern for Data Access in Software Development
Introduction
The Repository design pattern is a data access pattern used in software development.
Repository design pattern as defined by Martin Fowler isolates your domain from caring about how storage is implemented so all objects retrieved can be treated like an in-memory collection.
You could have a repository based on a database, an XML file, a text document, a web service, or anything.
The applications code itself doesn’t care. This makes it very useful for testing.
For brevity, we will refer to database/data store/data source as persistence store throughout this article.
What are Repositories?
Repositories are classes or components that encapsulate the logic required to access persistence store.
Repositories, in practice, are used to perform database operations for domain objects (Entity and Value types).
Generally, a separate repository is used for each Entity (or Aggregate Root).
Purpose of Repositories
- Centralize common data access functionality.
- Provide better maintainability.
- Decouple the infrastructure or technology used to access persistence store from the domain model layer.
- Make your code testable, reusable, and maintainable.
Consider the below flow:
If we want to unit test the code, it is tightly coupled to the data access layer.
If the persistence store changes, code in data access layer will change and so will your code that is referencing it.
To resolve this issue of tight coupling, a layer called as repository is introduced between your code and the data access layer.
Your code now interacts with the repository layer and is decoupled from the data access layer.
The Repository Pattern
After implementing the repository pattern, in the above flow we get the below:
Thus, the Repository pattern puts a façade over your data access layer so that you can shield the rest of your application code from having to know how persistence works.
The Repository pattern makes your code programmatically testable.
If you want to unit test your code, not infrastructure, the repository abstractions make it easier to achieve that goal.
You can implement mock repositories that return fake data instead of data from the database.
So, now we have:
A repository can be replaced during testing with a Mock Repository so that we can test the code behavior in isolation.
A mocking framework is generally used for this purpose.
Mock objects allow developers to emulate, through interfaces or virtual methods, the behavior of another class during testing and then verify that expected events occurred.
The behavior of mock objects (also simply called mocks) is what allows you to replace dependencies in your classes and then test those classes without having the real dependencies in place.
Advantages of the Repository pattern
1. Insulate your application from changes in the persistence store.
2. Facilitate automated unit testing.
3. Facilitate test-driven development (TDD).
Objectives of the Repository Pattern
1. Maximize the amount of code that can be tested with automation.
2. Isolate the data layer to support unit testing.
3. Apply centrally managed, consistent access rules and logic.
4. To implement and centralize a caching strategy for the data source.
5. Improve the code’s maintainability and readability by separating business logic from data or service access logic.
6. Use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
7. To associate a behavior with the related data.
8. To apply a domain model to simplify complex business logic.
Implementation of the Repository Design Pattern in C#
The below code demonstrates the Repository Pattern for accessing Web API
(Public Web API used is https://rapidapi.com/wirefreethought/api/geodb-cities/)
Coming up:
1. Dependency Injection and the Repository Design Pattern.
2. Repository Design Pattern with the Unit of Work Design Pattern.
3. Code to access data in files and databases with the Repository + UOW Patterns.
References and Further Reading:
