2

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.

HichemSeeSharp
  • 3,240
  • 2
  • 22
  • 44

2 Answers2

3

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.

Piotr Perak
  • 10,718
  • 9
  • 49
  • 86
  • Thanks for your reply.I have mentioned that i have taken a look to almost all posts including Ayende's. My question is quite precise on the efficient (with arguments). – HichemSeeSharp Sep 09 '12 at 12:52
  • No problem. I didn't know you read it. He states that there is no good repository. IList insteaad of IQueryable doesn't change much. So I thought you haven't read his blog. You asked for repository implementation that is good practice. So the answer is there is none. Not with ORM. – Piotr Perak Sep 09 '12 at 13:27
1

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.

Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252
  • What about tests ? I mean how can I test without using the repository pattern ? – HichemSeeSharp Sep 09 '12 at 11:11
  • Thank's for your reply, but You didn't answer my first question. – HichemSeeSharp Sep 09 '12 at 11:25
  • I'm still new to EF but how do you test if you can write to database if you use TransactionScope? I think You can't use same DbContext (DataContext) to write and read. And when you have open transaction (not commited) 2nd context won't be able to read data written by first. – Piotr Perak Sep 09 '12 at 11:38