ASP.NET Boilerplate has an interesting implementation of this.
http://www.aspnetboilerplate.com/Pages/Documents/Unit-Of-Work
https://github.com/aspnetboilerplate/aspnetboilerplate/tree/dev/src/Abp/Domain/Uow
I'm looking for this enhancement.
I wonder why this item is marked as "maybe wont" :(
@hung-doan it's not just"maybe wont". now it's "on hold OR mabe wont"
thanks for your feedback @AndreiMaz , nopCommerce is an amazing framework. I'm looking forward for this update in the future
I have been working with nopCommerce for a few weeks, but I immediately noticed that UoW is not used. UoW in facts is recommended by any software architecture book and I think that is a must for a an enterprise-level application like nopCommerce because without UoW many bugs and incosistent states can blow up. For example, if an exception is thrown (or other failures) in the admin CustomerController::Create whe can have Customers without password, or without generic attributes and things like this. In general every action method that use more than a repository method (where SaveChanges is called) can be dangerous! I think that we have to implement a solution as soon as possible. Moreover, we can speed up the system using transaction-based controller action methods
Also the domain events raise their listeners and they are not inside a UoW so the listeners performs actions and eventually interacts with the persistence layer and if somithing go wrong changes cannot be rollbacked
Nowadays Entity Framework is stable and rich enough, I think Uow pattern is a must only to ensure data consistency but also performance. Besides it makes the code very cleaner and more readable
after some consideration we've decided not to implement this functionality out of the box
Most helpful comment
I have been working with nopCommerce for a few weeks, but I immediately noticed that UoW is not used. UoW in facts is recommended by any software architecture book and I think that is a must for a an enterprise-level application like nopCommerce because without UoW many bugs and incosistent states can blow up. For example, if an exception is thrown (or other failures) in the admin CustomerController::Create whe can have Customers without password, or without generic attributes and things like this. In general every action method that use more than a repository method (where SaveChanges is called) can be dangerous! I think that we have to implement a solution as soon as possible. Moreover, we can speed up the system using transaction-based controller action methods