I am learning repository pattern and was reading Repository Pattern with Entity Framework 4.1 and Code First and Generic Repository Pattern - Entity Framework, ASP.NET MVC and Unit Testing Triangle about how they implement the repository pattern with Entity Framework.
Saying
•Hide EF from upper layer
•Make code better testable
Make code better testable I do understand, but why hide EF from upper layer?
Looking at their implementation, it seems just wrap the entity framework with a generic method for query the entity framework. Actually what's the reason for doing this?
I am assuming is for
- Loose coupling (that's why hide EF from upper layer?)
- Avoid repeat writting same LINQ statement for same query
Am I understand this correctly?
If I write a DataAccessLayer which is a class have methods
QueryFooObject(int id)
{
..//query foo from entity framework
}
AddFooObject(Foo obj)
{
.. //add foo to entity framework
}
......
QueryBarObject(int id)
{
..
}
AddBarObject(Bar obj)
{
...
}
Is that also a Repository Pattern?
Explaination for dummy will be great :)
The same reason you don't hard code file paths in your app: loose coupling and encapsulation. Imagine an app with hard coded references to "c:\windows\fonts" and the problems that can cause. You shouldn't hard code references to paths so why should you hard code references to your persistence layer? Hide your paths behind config settings (or special folders or whatever your os supports) and hide your persistence behind a repository. It will be much easier to unit test, deploy to other environments, swap implementations, and reason about your domain objects if the persistence concerns are hidden behind a repository.
I don't think you should.
The Entity Framework is already an abstraction layer over your database. The context uses the unit of work pattern and each DBSet is a repository. Adding a Repository pattern on top of this distances you from the features of your ORM.
I talked about this in my blog post: http://www.nogginbox.co.uk/blog/do-we-need-the-repository-pattern
The main reason adding your own repository implementation is so that you can use dependency injection and make your code more testable.
EF is not very testable out of the box, but it's quite easy to make a mockable version of the EF data context with an interface that can be injected.
I talked about that here: http://www.nogginbox.co.uk/blog/mocking-entity-framework-data-context
If we don't need the repository pattern to make EF testable then I don't think we need it at all.