Unit of Work in Rich Clients

Magellan/MVC has changed the way I think about implementing rich client apps - after seeing it in action it now seems obvious to me that Controllers are the puzzle piece that most rich clients are missing.

Taking the 'transactional' logic out of View Models also makes them much more focused in their responsibilities.

I'd love to hear more about your experiences with this pattern in different situations - I'm really enjoying learning some more disciplined approaches to lifetime in rich client apps.

Generally I use IStatelessSession instead of ISession if all I am doing is loading objects for a search/display and don't need any state change tracking.

I like the way you describe that the Controller.Action formalizes the boundary of the unit of work to be done. So Controller.Action == UnitOfWork.DoWork.

I think that there needs to be some consideration as to how the state of ISession is scoped. For example, what implications might arise if I pass ISession to a child component. And even further, what if that child component is then cached?

I should clarify my previous comment... you say pretty clearly that the unit of work is not Controller.Action (that only forms a logical contextual boundary) but the unit of work is more like:

• var foo = new DbContext
• foo.Add
• foo.Add
• foo.CommitChanges

My comment about the scoping of ISession is still relevant though

Hi Darren,

Generally the ISession shouldn't be passed to other components, but should be injected into them via the container. So for example, suppose my Repository<T> looks like this:

public class Repository<T>
{
    public Repository(ISession session) { .. }
}

My controller could then look like this:

public class SearchController
{
    public IRepository<Customer> Customers { get; set; }
    public IRepository<Order> Order { get; set; }

    // .. actions
}

In my IOC container, I'd register the components with the following lifetimes (using Autofac terminology):

• ISession: Instance per lifetime scope
• Controller: Instance per dependency ("transient")
• IRepository<>: Instance per dependency

My ControllerFactory would create a lifetime scope per controller it resolves, so that every repository in the controller gets the same ISession.

If another component needed access to the session within the controller action, then that component would take a dependency on ISession and it would be resolved from the container just like repositories do. They're all resolved within the same lifetime scope so they'll share the same session.

Paul

Thanks for the response. I think extending the discussion about lifetimes would be good.

What prototyping tool you have used? Found some new done with Silverlight, you might take a look www.mockupbuilder.com

"Generally the ISession shouldn't be passed to other components, but should be injected into them via the container."

I don't like this sort of dogmatic thinking. It leads to overly complex designs and fails to utilize the power of the ISession/Datacontext.

For example, if you have an OrderViewModel and OrderItemViewModel, the most elegant way is to have the repository inject the ISession/Datacontext into the OrderViewModel which in turn injects the ISession/DataContext into the OrderItemViewModel.

The OrderViewModel then takes care of saving / transactions for the entire order and there is no need to co-ordinate anything as it will be implicitly handled by the ISession.

Hi Martin,

I agree that not everything fits neatly into that basket. In the cases where it doesn't the rule would be:

• If you're passing the unit of work to another component, the component shouldn't live longer than the unit of work.

Which I suppose is a good rule to follow when it comes to managing any object lifetime.

Now, I could be nit-picking your example but:

• Could you resolve the OrderItemViewModel from the container too?
• If not, does the OrderItemViewModel really need the full ISession? Wouldn't it just wrap a real OrderItem?
• By having the OrderViewModel pass depenencies to the OrderItemViewModel, aren't you doing the job of the IOC container?

I think a lot of it depends on your overall application architecture. In a Magellan application, an ISession would never be passed to a ViewModel in the first place.

Paul

I agree with your first rule, that the child (OrderItemViewModel) should not outlive the unit of work.

Could you resolve the OrderItemViewModel from the container too?

It follows that the OrderItemViewModel would not be resolved from the container, as it probably has no purpose as a standalone (eg it doesn't know how to fetch itself, save itself....)

If not, does the OrderItemViewModel really need the full ISession? Wouldn't it just wrap a real OrderItem?

It might not be that common for the OrderItemViewModel to need the full ISession, however there are certainly cases where it makes for a cleaner implementation. For example, lets say an OrderItem has a property called DeliveryMethod which is a lookup table in the database. I prefer the OrderItemViewModel to populate a collection (for the view to bind to) of DeliveryMethods from the ISession rather than require the OrderViewModel to pass them in. There are many other examples where the OrderItemViewModel might need other adhoc stuff from the ISession.

By having the OrderViewModel pass depenencies to the OrderItemViewModel, aren't you doing the job of the IOC container?

I have a different philosophy here. Injecting dependencies via constructors has been sound software engineering long before IOC containers existed, therefore I don't think everything that gets injected into a constructor has to come from the IOC container. Particularly in this case the ISession is created by the IOC, but just propogated from parent to child.

The whole point of my argument is to keep it simple. There is no need to co-ordinate the units of work, as it happens implicitly. However, you still get the benefit of encapsulating as much of the OrderItemViewModel related logic in its own class.

To be honest, I haven't looked at Magellan (yet), I was just discussing the general point. I am interested to see how you separate the VMs from an ISession (without creating a lot of work :-)