Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I would have a UnitOfWork that I passed as a dependency to whatever class needed to do the commit, which in your case if, I understand, you don't want to be your strategies.</p> <p>The UnitOfWork should know about how to commit your updates because it would have a reference to some kind of data context. Maybe and entity framework model, DBContext, etc.</p> <p>Your strategies shouldn't know about the UnitOfWork if they are not supposed to commit. I'm guessing maybe your using the UnitOfWork to expose your data context to your strategies. </p> <p>Your strategies and your UnitOfWork should both have references to the same data context. Then your strategies work with the context and some other routine, it may have used many strategies, would have a reference to the UnitOfWork to commit it at the end.</p> <p>This is all quite straight forward if you are using an IOC framework because you would specify the lifetime scope of the data context as PerRequest and you would pass it as a dependency to both of your classes. When the framework injected that dependency into your class it would use the same instance so your strategies would be writing to the same instance held by the unit of work. In this way the changes you make to the data through your strategies are the same changes the unit of work is going to commit. If you are really slick with the IOC you can actually inject the individual parts of the context needed by a given class further isolating the dependency.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload