Explain how to properly apply the Repository pattern with the Entity Framework?

Question

.NET

Why can't you use the Repository template to work with several entities at once, why do you need to make your own repository for each entity? What is the advantage and convenience of this approach?
For example, I have a user and a history of his actions, why not just add the GetUserWithHistory(int userId) method and immediately get the desired data structure? Same with saving. It is necessary to save the new user values ​​​​and write them to the history, it turns out that you need to call the operations of 2 repositories and somehow coordinate the saving in order to roll back on failure. How is this problem solved?

Answer 1

why you need to make your own repository for each entity

Not for every entity, but only for entities that act as the roots of aggregates of entities. Well, that is, if you have the entity Product and ProductImage, for example, then you make a repository only for products.
Because the repository represents a certain thing that is responsible for storing things. For example, imagine that the repository is a shelf. You have a shelf for some things, a shelf for others.
Moreover, these shelves can contain various business rules in the spirit of "the user cannot put more than N products on the shelf until he pays extra money."
And each entity will have its own rules on how and who can store them where. Banal observance of the principle of single responsibility and separation of duties.

Answer 2

Repository - This is a wrapper over a collection of items in memory. We need methods Add, Remove, Get(id), GetAll, Find(predicate). There should be no save, edit methods here. to do this, we just need to take an element from the collection and change it. The repository does not need to know about the database.
Unit of work - Represents a list of objects changed by business transactions, coordinates the recording of these changes.
If just taking an element is not enough, they make a service that already knows what and with what and how to save it. There is no need to make repositories for each entity, the 1st Generic is enough.
https://www.youtube.com/watch?v=rtXpYpZdOzM
https://www.youtube.com/watch?v=QwwfTWMrM9k
Another approach is DDD, it does not have repositories and unitofwork. But it is more difficult to do and does not immediately reach.

Answer 3

The repository gives the same set of common APIs such as :
IEnumerable<TModel> GetModels(); sometimes it changes to IQueryable<TModel>GetModels(), especially in this example it is more correct (since GetModels has no parameters, materialization should be at the very last moment).
This is solved using services or Unit of Work, which are built around the union of repositories connected by a single business logic, a single context instance, a single transaction where necessary, etc.
An example of all this goodness can be seen, for example, here: https://www.asp.net/mvc/overview/older-versions/ge...
The article is old, but for a general understanding it will do. But the salt is not in this. The point of the situation is that EF itself is UoW, and its DbSets are repositories. Accordingly, you need repositories only if you want support for working with several, let's call it, backends. In this particular case, backends can be:

Answer 4

Good afternoon! I think it's a very similar question: I don't know how to prepare a repository, or is it just not very good?
Push. Sculpting repositories for each entity is beneficial, as it seems to me, only when these entities are one, two or three over, and the project will never be maintained. In enterprise solutions, following the principle of "1 repository per 1 entity" will lead to difficulties in maintaining and scaling the application.