locked
mvc 4, entity framework 5 and the repository pattern RRS feed

  • Question

  • User65893105 posted

    Im building a project from scratch and am learning 'best practice' methods for architecting the system.  I want to implement design patterns in the best way, but Im slightly confused about the repository pattern and the unit of work pattern used in conjunction with entity framework 5.  My understanding of the unit of work pattern is that it maintains a list of objects that have been changed by a business transaction and coordinates the persistance of the changes as one atomic action, rolling back all changes if there was a problem.  In other words, a transaction.  Doesnt EF5 implicitly perform transactions when saving to the data store?  In that case, why would I also need to implement the unit of work pattern ?  So far all the stuff Ive read about design patterns seems to include the unit of work pattern when using the repository pattern.  Can anyone clear this up for me ?  Whats the 'best practice' approach to this ?

    Friday, February 1, 2013 5:12 AM

Answers

  • User-837620913 posted

    DbContext implements both unit of work and repository patterns. When you call "SaveChanges" all changes made in that unit are saved in a transaction. Multiple different calls to SaveChanges are not wrapped in a transaction unless you do it explicitly. So the short answer is you don't need to unless you don't need to also implement UoW patter.n.

    The two patterns go hand in hand. The repository pattern is also implemented by DbContext. Unless you don't like the way it works, no need to add another abstraction on top of it. It seems like creating a Generic Repository is all the rage in articles these days. I've tried it - and after several years of use we ripped it out and simplified our code. We did not need to mock the repository for unit testing (we used integration tests instead, hitting an in-memory data store) so adding a Generic Repository on top of DbContext was needless overhead.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, February 1, 2013 6:01 AM

All replies

  • User-837620913 posted

    DbContext implements both unit of work and repository patterns. When you call "SaveChanges" all changes made in that unit are saved in a transaction. Multiple different calls to SaveChanges are not wrapped in a transaction unless you do it explicitly. So the short answer is you don't need to unless you don't need to also implement UoW patter.n.

    The two patterns go hand in hand. The repository pattern is also implemented by DbContext. Unless you don't like the way it works, no need to add another abstraction on top of it. It seems like creating a Generic Repository is all the rage in articles these days. I've tried it - and after several years of use we ripped it out and simplified our code. We did not need to mock the repository for unit testing (we used integration tests instead, hitting an in-memory data store) so adding a Generic Repository on top of DbContext was needless overhead.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, February 1, 2013 6:01 AM
  • User65893105 posted

    Thanks for your reply

    I have to say, there are so many conflicting opinions around this, the whole thing has me confused and given me a headache!  Im all for using the simplest approach and dont want any uncecessary complexity.  Would you say its better for me to have a repository for each 'aggregate' in my app rather than a generic 'catch all' repository ?

    at the moment my app consists of several layers, a 'core' which contains the domain model and a service layer.  The domain model are the POCO classes EF generated from my database, Ive simply moved then across (by removing the dependancy on the edmx file).  I also have an infrastructure layer and and mvc project.  the service layer is the conduit into the system fro the mvc app.

    So as an example, If I had a 'Customer Order'  object this would consist of several dependant objects.  The main object would be the order which is linked to order items and the customer.  So I could have a CustomerOrderRepository which would have its own set of methods specific to a customer order, any changes to that 'aggregate' would be done in the DBContext, hence inside a transaction.  So If for example, it was neccesary to delete a customer, this would in turn delete all the orders for that customer along with all the order items.

    From what Ive read so far, it seems to be frowned upon to build it this way as I would end up with lots of repository classes for the many domain objects in my app.  I hope Ive made sense, but all these design patterns are confusing me.

    Friday, February 1, 2013 6:43 AM
  • User-860466875 posted

    @misuk11 I have been pulling my hair over the same issue.  Okay I've got the pretty well same setup as you with DB first using EF5 and UI MVC 4, but so confused with the Generic Repository and UoW... then DI (using ninject or unity).. and to top it all off Automapper.  From what I have read: using the Generic Repository and UoW pattern was a good thing for decoupling and thus separation of concerns.

    I have been scouring the net trying to find a up-to-date modern ntier architecture using all of the above.  The majority of information I have seen talk about EF4 and code first.

    I wonder if @DarrelNorton could post somethiing a little more concrete (projects and what would be contained in them) about the structure he might use.Laughing  I'd greatly appreciate it.

    Thanks

    Paul

    Monday, February 18, 2013 5:17 AM
  • User-590241306 posted

    I completely agree with htis after many years of experience with asp.net. Currently i have built service oriented architecture where in i don tuse repositary or UOW. it is simple domainservice layer which will do all the neccessary business and return view model or dto. the advantage is my controller action is very thin and almost nothing. My service is also can be webapi, so various other ttype of client can eb use since my logic in controller is very thin.

    i am fine with it soforr, it is i live for 1yr in health care industry.

    Thursday, September 5, 2013 5:34 AM