In ASP.NET MVC & Entity Framework , because many examples and some open-source projects we find a unit of work together with repository pattern and DbContext is already a unit of work, including projects with IoC and DI. >
Is there a reason for this? The use would only be to avoid the override of SaveChanges in DbContext ?
Oren Eini , creator of NHibernate, Castle Framework and RavenDB collaborator, wrote the following text talking about why using repositories is not worth
Ladislav Mrnka gave this answer in Programmers , reinforcing that the repository pattern goes against Do not Repeat Yourself and that the repository is not important because IDbSet<T> is already a generic repository.
In addition, the use of Expression Methods , and not Linq, has been encouraged, precisely so that the use of the Framework was more natural with a programming language, moving away from the concept of query, such as SQL.
What confuses (much) is the concept of repository with the concept of DAO. In another answer I gave here (although I Java and Oracle, the concept is the same) , explain that a DAO implements the data access method itself, while the repository works with collections of objects, without understanding how access to the database is made is done by another layer). Now if manipulating objects can be done by a Controller (as it is currently done), there is no need to have another layer just to manipulate collections of objects. Data harmonization, Controller responsibility, is a collection manipulation, and the persistence of this data, which is the responsibility of the Entity Framework, is another. With this, it can be concluded that the repository pattern is not needed when working with the Entity Framework.
Finally, for unit tests, this site explains how to Mocking of a DbContext . This does not require a repository for unit testing when the project uses Entity Framework.
