Nopcommerce: "Unit of Work" pattern

Created on 15 Jan 2016  路  8Comments  路  Source: nopSolutions/nopCommerce

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

All 8 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AndreiMaz picture AndreiMaz  路  4Comments

mariannk picture mariannk  路  4Comments

AndreiMaz picture AndreiMaz  路  4Comments

tigran-avdalyan picture tigran-avdalyan  路  7Comments

AndreiMaz picture AndreiMaz  路  6Comments