Why use Repository Pattern or please explain it to me?

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

1. Loose coupling (that's why hide EF from upper layer?)
2. 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 :)

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.

This picture makes it easy to understand

One thing is to increase testability and have a loose coupling to underlying persistance technology. But you will also have one repository per aggregate root object (eg. an order can be an aggregate root, which also have order lines (which are not aggregate root), to make domain object persistance more generic.

It's also makes it much easier to manage objects, because when you save an order, it will also save your child items (which can be order lines).

It's also an advantage to keep your queries in a central place; otherwise your queries are scattered around and are harder to maintain.

And the first point you mention: "To hide EF" is a good thing! For instance, saving logic can be hard to implement. There are multiple strategies that apply best in different scenarios. Especially when it comes to saving entities which also have changes in related entities.

Using repositories (in combination with UnitOfWork) can centralize this logic too.

Here are some videos with a nice explanation.

Repository systems are good for testing.

One reason being that you can use Dependency Injection.

Basically you create an interface for your repository, and you reference the interface for it when you are making the object. Then you can later make a fake object (using moq for instance) which implements that interface. Using something like ninject you can then bind the proper type to that interface. Boom you've just taken a dependence out of the equation and replaced it with something testable.

The idea is to be able to easily swap out implementations of objects for testing purposes Hope that makes sense.