I was doing some research and someone pointed out that Line 24 of the DBContext Class states
DbContext is a combination of the Unit Of Work and Repository patterns.
Does this mean that we no longer need to abstract EF to a Repository and then use and Interface to inject it into Controllers?
It's really up to you. There are two main reasons you may want to introduce a repository which are not handled by DbContext:
DbContext exposes IQueryable so the app can compose any query allowed by LINQ. Repositories that don't return IQueryable can help you control what is sent to the database.Ultimately it comes down to a philosophical/style/preference decision. Many apps have been built successfully using either approach.
@rowanmiller Thanks for the insights. I currently working on a project in which i find my repositories have a lot of methods like FindById, FindByName, FindBy.... and also a lot of dynamicness needed for When to Include and When to OrderBy etc..
I just started research
No, repository pattern for EF context is evil! Just don't use it!
@ilmax I personally prefer using repositories in my data access layer for encapsulating DbContext, so other developers can't use it directly in the application and create repetitive queries. I'd like to hear your point of view why not to use this approach.
FYI, Programmers Stack Exchange is a good place to discuss these types of design questions.
Closing this one out as I think we have addressed everything from the EF side.
I posted this on Stack Exchange as suggested. I would appreciate the discussion continueing there
Most helpful comment
It's really up to you. There are two main reasons you may want to introduce a repository which are not handled by
DbContext:DbContextexposesIQueryableso the app can compose any query allowed by LINQ. Repositories that don't returnIQueryablecan help you control what is sent to the database.Ultimately it comes down to a philosophical/style/preference decision. Many apps have been built successfully using either approach.