Implementing Repository pattern and doing Tests

Question

I have read almost all articles about Repository pattern and different implementations of it. Many of them judged bad practices (ex: using IQueryable<T> instead of IList<T>) etc. that why i'm still stuck and couldn't end-up to the right one.

So:

• Do I need Repository pattern to apply IoC in my MVVM applications ?

• If yes, What is the efficient IRepository implementation to EF Entities which is a good practice and better testable ?

• How can I test my Repositories and UnitofWork behavior ? Unit tests against in memory Repositories ? Integration tests ?

Edit : According to answers I added the first question.

Answer 1

Ayende Rahien has a lot of posts about repository http://ayende.com/blog/search?q=repository and why it is bad when you are using ORM's. I thought Repository was the way to go. Maybe it was, in 2004. Not now. ORM's already implement repository. In case of EF it is IDbSet. And DbContext is UnitOfWork. Creating a repository to wrap EF or other ORM's adds a lot of unnecessary complexity.

Do integration testing of code that will interact with database.

Answer 2

The repository pattern adds an extra layer when you are using EF, so you should make sure that you need this extra level of indirection.

The original idea of the Repository pattern is to protect the layers above from the complexity of and knowing about the structure of the database. In many ways EF's ORM model protects the code from the physical implementation in the database so the need for a repository is less.

There are 2 basic alternatives:

• Let the business layer talk directly to the EF model
• Build a datalayer that implements the Repository pattern, this layers maps EF objects to POCO

For tests:

• When we use EF directly we use a transaction scope with rollback, so that the tests do not change the data.
• When we use the repository pattern we use Rhino Mocks to mock the repository

We use both approaches, Repository pattern gives a more clearly layered app and therefore maybe more control, using EF directly gives an app with less code and therefore faster to build.