6

I have recently learned of the Repository and Unit of Work Design Patterns and thought that I would implement them in a new EF4 MVC3 project, since abstraction is generally good.

As I add them to the project, I am wondering if the juice is worth the proverbial squeeze, given the following:

  • It is EXTREMELY unlikely that the underlying data access mechanism will change from EF4.
  • This level of abstraction will require more overhead/confusion to the project and to other developers on the team.

The only real benefit I see to using the Repository pattern is for unit testing the application. Abstracting away the data store doesn't seem useful since I know the datastore won't change, and further, that EF4 already provides a pretty good abstraction (I just call .AddObject() and it looks like I am modifying an in-memory collection and I just call .SaveChanges() which already provides the unit of work pattern).

Should I even bother implementing this abstraction? I feel like there must be some massive benefit that I am missing, but it just doesn't feel like I need to go down this route. I am willing to be convinced otherwise; can someone make a case? Thanks.

skaz
  • 21,962
  • 20
  • 69
  • 98

2 Answers2

6

I recommend you reading this answer and all linked questions. The repository is very popular pattern and it really makes your application nice and clean. It make you feel that your architecture is correct but some assumptions about repository pattern with EF are not correct. In my opinion (described in those answers):

  • It will make some more complex EF related task much harder to achieve or your repository and UoW implementation will need to have public interface very similar to EF's
  • It will not make your code better unit testable because all interactions with repository must still be covered by integration tests. Not only my experience proved that mocking EF code by replacing linq-to-entities with linq-to-objects does not test your code.
Community
  • 1
  • 1
Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • If you use the POCO objects in EF then you should have an easier time testing the objects and you can treat them as any other non-ef object. This greatly simplifies this dependency. – Adam Tuliper Apr 30 '11 at 17:06
  • @Adam: It is not about POCO but about linq-to-entities provider switched to linq-to-objects where L2E is only subset of L2O. – Ladislav Mrnka Apr 30 '11 at 17:57
  • can you give me a brief example of the issue, I'm not following and would like to understand. – Adam Tuliper May 02 '11 at 16:43
2

yes yes yes : ) - first of all - the repository pattern helps to inject your dependencies for unit testing. Secondly, it gives a very clear view of exactly what data access methods are available to get something rather than people misc. coding against the EF layer directly. Download the POCO templates though for EF4 so your classes don't carry the EF properties around with them if you happen to use them as models and/or don't want any EF dependency libraries references in your mvc app assuming your repository work is in a separate project (which I recommend). If you are using all viewmodels then its not as much of a concern, but its nice working with a "Customer" object without extra methods on them. Its cleaner in my opinion.

Adam Tuliper
  • 29,982
  • 4
  • 53
  • 71