Reputation: 3707
So far I've been implementing in my projects repository pattern and dependency injection. I use Entity Framework for ORM and also have a service layer that manages my repositories.
I kind of feel like doing something not so essential for problems at hand. I am not likely to change my database or ORM. For small projects I have no need to implement tests.
But I like the idea of not sending requests to database each time I fetch data, if it's already in memory get it from there.
My question is: if I use Entiry Framework for example in Asp.Net MVC application, and not use repository pattern, but still using a DI on EF's DBContext, I can get benefit of performance by preventing roundtrips to database server for reads?
By implementing DI on DbContext I mean something like this for Ninject example:
kernel.Bind<MyDBContext>().ToSelf().InRequestScope();
Thanks
Upvotes: 3
Views: 3753
Reputation: 3707
As explained in Advanced Entity Framework 6 Scenarios section of Getting Started with Entity Framework 6 Code First using MVC 5 series of Microsoft articles, repository pattern is not much needed anymore.
Upvotes: 2
Reputation: 13233
Adding the repository pattern on top of an EF DbContext
does not help in performance optimization.
The DbContext
is a unit of work which keeps track of loaded/changed/added entities. A IDbSet<T>
is basically a repository. So the DbContext
has a list of repositories. The DbContext
is responsible for doing some performance optimisations like not loading the same entity twice but rather return the same instance when you do load it twice by id.
Of course, for this to apply you must reuse the same DbContext
instance. If you create two DbContext
instances, they will both load the same entity once.
So using
kernel.Bind<MyDBContext>().ToSelf().InRequestScope();
and not putting your own "Repository Pattern" on top of the MyDBContext
is perfectly fine.
Upvotes: 5