Ah sorry - from your first post I thought you wanted a new interface IUnitOfWork.
I wanted it to wrap the context, so that you hide the fact that you are handling a context. You don't want any other logic wrapped in the unit of work.
i have tried to implement an IDbContext that does not live during the lifetime of a request, but is instantiated in a unit of work manner within service methods, because I also wanted to have a better sql transaction behavior. The problem that I encountered was, that then my context and therefore the sql connection only lived within the scope of the service method and I ran into problems when using lazy loading of entities in controller methods, because the connection was already closed.
To solve this issue one would have to completely refactor the service layer so it does not return entities that support lazy loading. Instead the service layer would have to return/accept a kind of Data Transfer Objects that are decoupled from entities. Furthermore, one would then have to refactor most of controller methods, because there the entities are used.
That's why I don's see this before nopcommerce > v 4.0. , if at all. :-(
This thread is from 4 years ago, but nop still misses the unit of work. I think it's extremely important to implement this pattern, specially to ensure data consistency, but also for performance. Some operations have many update operations and performing them one by one has a big performance hit, a part from the risk of failing before finishing.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
