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 ?
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.
Darrell Norton, MVP
Darrell Norton's Blog Please click "Mark as Answer" if this helped you.
Marked as answer by misuk11 on Feb 01, 2013 02:03 PM
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.
@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.
I'd greatly appreciate it.
misuk11
Participant
1608 Points
1280 Posts
mvc 4, entity framework 5 and the repository pattern
Feb 01, 2013 09:12 AM|LINK
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 ?
DarrellNorto...
All-Star
86555 Points
9624 Posts
Moderator
MVP
Re: mvc 4, entity framework 5 and the repository pattern
Feb 01, 2013 10:01 AM|LINK
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.
Darrell Norton's Blog
Please click "Mark as Answer" if this helped you.
misuk11
Participant
1608 Points
1280 Posts
Re: mvc 4, entity framework 5 and the repository pattern
Feb 01, 2013 10:43 AM|LINK
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.
jilekp
Member
2 Points
1 Post
Re: mvc 4, entity framework 5 and the repository pattern
Feb 18, 2013 09:17 AM|LINK
@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.
I'd greatly appreciate it.
Thanks
Paul