What is Repository ?

At first, we will review the definition of Repository Pattern from this book together:

Mediates between the domain and data mapping layers, acting like an in-memory collection of domain objects.

This definition says that Repository is actually a collection of Domain Objects or Entities that acts as an interface between the Domain layer and Data Mappers.

We said that Repository is a collection of entities, so it must have the methods that a collection has, methods like:

- add

- remove

- get

- find

?The first thing we should pay attention to here is that we are talking about a collection, so we don't have a save or update method

So! ?if we don't have save and update, how can we create a new entity or update it? We will answer this question when we mentioned the Unit of Work pattern.

We said that each Repository represents an Entity and acts as a collection of that Entity in Memory. And we also said that every Repository has methods like add, remove, get, find because of its collection feature. Now, because all repositories must have these methods, to avoid code duplication, we create a base class that has these basic methods and the rest of the classes inherit from it.

Now let's say one of the advantages of Repository Pattern:

- Prevent code duplication.

- Help to make the code testable.

- Independence of the program from databases and ORMs.

In programs where business logic has direct access to data, you can face any of the following problems.

? Duplicate code

? Higher potential for programming errors

? Difficulty in centralizing policies related to data such as caching

? Inability to test business logic separately from external dependencies

Repositories are classes that hide the logic needed to store or retrieve data. Therefore, our application does not care what kind of ORM we use, because everything related to ORM is managed in a Repository layer. Repositories are classes or components that contain the logic needed to access data resources. They centralize common data access functionality and provide better maintainability and separate the infrastructure or technology used to access databases from the Domain Model layer.

Because Domain should not depend on technology! It should not have a reference to data access or EF core or... It only defines a series of interfaces, which is called the data access layer later, this interface must be implemented!

Architecture should be independent of Frameworks. (Robert Cecil Martin)

There may be cases where you need to use multiple ORMs in one solution. Probably Dapper to fetch data and EFCore to write data. This is for performance optimization only.

The Repository pattern helps us achieve this by creating an abstraction on top of the DataAccess layer. Now you don't need to depend on EFCore or any other ORM for your application. Instead of being your only option for accessing data, EFCore becomes one of your options

Now that we have configured our EFCore layer, let's talk a little about the traditional method of receiving data from this layer. Traditionally, you call the dbContext object directly to read and write data. this is good. But is it really ideal for the long term? When you use dbContext directly, what you're doing is making Entity Framework Core tightly coupled with your application. So, in the future when something newer and better than EFCore is released/required, it's very annoying for you to implement the new technology and make the corresponding changes. it's true?

On the one hand, Repository supporters believe that all database access code should be placed in the Repository, and on the other hand, those who work with DbSet and EF admit that DbSet is a Repository in itself, so there is no need to create another Repository.

Both of these types of thinking are true to some extent. The Repository pattern and the idea behind it is useful for working with databases, but it was formed long before the introduction of ORMs such as EF, and today, despite powerful ORMs such as EF, it may not be very useful to use this pattern.

The most important reason you might want to do this (add an abstraction layer on top of DbContext):

? Maybe you don't want your project to be completely tied to Entity Framework and its architecture. So, you hide Entity Framework behind those abstractions so that you can replace Entity Framework with any other ORM without any changes to the data access layer interface.

? Implementing custom repositories offers several advantages when implementing microservices or more complex applications. The patterns of Unit of Work and Repository are considered to enclose the persistence layer, so it is separated from the application and domain-model layers.

?You use repositories to specify what operations are allowed on specific entities.

? Microsoft itself recommends using Repository patterns in complex scenarios to reduce coupling and provide better testability. In cases where you want the simplest code possible, you want to avoid the Repository pattern.