3
In ASP.NET MVC & Entity Framework, because many examples and some open-source projects find a unit of work together with the repository pattern whereas the 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 the DbContext?
3
Oren Eini, creator of Nhibernate, Castle Framework and collaborator of Ravendb, wrote the following text about why using repositories is no longer worth it.
Ladislav Mrnka gave this answer in Programmers, reinforcing that the repository standard goes against the Don’t Repeat Yourself and that the repository is not important because the IDbSet<T> is already a generic repository.
In addition, the use of Expression Methods, and no more of Linq, just so that the use of the Framework was more natural with a programming language, moving away from the concept of query, as is the SQL.
What confuses (a lot) is the concept of repository with the concept of DAO. In another answer I gave here (despite talking about Java and Oracle, the concept is the same), explain that a DAO implements the data access method itself, while the repository works with object collections, without understanding how access to the database is done (this is done by another layer). Now, if manipulating objects can be done by a Controller (as is currently done), there is no need to have one more layer just to manipulate collections of objects. Harmonisation of data, responsibility of the Controller, is a collection manipulation, and the persistence of this data, the responsibility of the Entity Framework, is another. With this, one can conclude that the repository pattern is not necessary when working with the Entity Framework.
Finally, on unit tests, this site explains how to do the Mocking of a DbContext. With this, you don’t need a repository to perform unit tests when the project uses Entity Framework.
So you think the Controller should take care of queries directly? without any abstraction? using the Express methods...
I don’t think so. I’m sure.
The fact of having no abstraction could not lead to a DRY?
Repositories lead to Drys. The Entity Framework allows the programmer to work at the collection handling level only. If many Controllers need to repeat the same operations, the problem is not the lack of repository, but system design.
Just out of curiosity, you create an instance of Dbcontext in each controller?... using service Pattern you pass the instance of Dbcontext pro service?
Yes, it is an instance for each Controller which is destroyed after the cycle of its execution. As I do not use Service Pattern (because I find it useless), I have no way of saying, but if I were to do so for some nonsense of life, probably the instantiation of the context would be in the same service layer.
Honestly I’ve never been very good with face of Patterns but in corporate environment, unfortunately it is a reality the use of these ..., therefore, I can not ignore.
Well, this is the big problem of having to deal with human beings.
Browser other questions tagged asp.net-mvc entity-framework repository
You are not signed in. Login or sign up in order to post.
Opinionately speaking, I find a repository in a project that uses the Entity Framework completely useless. I will try to think of a good answer.
– Leonel Sanches da Silva
I am waiting, as for the repositories many love, others hate, anyway this is hilarious, I have seen people using Pository because they do not expose the LINQ and facilitates unit tests and the person does not create unit tests. I believe that it is choices based on actual use, prior experience than experiencing new forms.
– Trxplz0
None of these reasons proceed. I am preparing a response.
– Leonel Sanches da Silva
Please help me, what is the alternative for sharing Dbcontext ? Supposed to use Dbcontext directly? like: Dbcontext.Set<Tentity>(). Add(obj); Dbcontext.Savechanges(); directly in a service camda for example?
– Andre