entity framework - EF4 with MVC3 - Do I need The Repository Pattern? -
i have learned of repository , unit of work design patterns , thought implement them in new ef4 mvc3 project, since abstraction good.
as add them project, wondering if juice worth proverbial squeeze, given following:
- it extremely unlikely underlying data access mechanism change ef4.
- this level of abstraction require more overhead/confusion project , other developers on team.
the real benefit see using repository pattern unit testing application. abstracting away data store doesn't seem useful since know datastore won't change, , further, ef4 provides pretty abstraction (i call .addobject() , looks modifying in-memory collection , call .savechanges() provides unit of work pattern).
should bother implementing abstraction? feel there must massive benefit missing, doesn't feel need go down route. willing convinced otherwise; can make case? thanks.
i recommend reading answer , linked questions. repository popular pattern , makes application nice , clean. make feel architecture correct assumptions repository pattern ef not correct. in opinion (described in answers):
- it make more complex ef related task harder achieve or repository , uow implementation need have public interface similar ef's
- it not make code better unit testable because interactions repository must still covered integration tests. not experience proved mocking ef code replacing linq-to-entities linq-to-objects not test code.
Comments
Post a Comment