Zune Phone Parody

 

Rodrigo y Gabriela

Do you like acoustic guitar? Well they are really, really, really freakin' good.

 

 

DDD + IoC + WinForms = Headache

 

I'm trying to wire up DDD-style domain classes, NHibernate and Windsor IoC into one nice mini-framework and separate it from UI/Application layer.  At first sight everything seemed pretty straight forward. But then I hit a wall. Some of my domain classes needed a reference to a session-object. This session-class contains instances of Windsor’s IWindsorcontainer, NHibernate’s ISession, user-object etc and might also contain some other application-data.  Where should the application store this session-object? How can domain-objects find it?

In ASP.NET world this is not a problem. Session specific data can be stored into HttpContext and any object can access it easily. The only disadvantage is that then I've still got to reference System.Web from my domain-assembly.

WinForms is another beast. If the application has only one form open at a time, I could save the session-object into the CallContext. What if the application has multiple forms open at a time and each of them wants to have a separate instance of my session-class?  CallContext is out of the question. So are all thread-specific alternatives.  What is left? Nothing?  I’m not the first person pondering this issue. A solution probably exists but I can’t find it. Do I really have to inject the session-object into every object instance that might need it? Or should I refactor a lot behavior from domain-classes into services and inject the session-object into them. I don’t like this approach because I want my classes to be more than data containers.  

Sigh.

Technorati Tags: DDD, IoC, WinForms, NHibernate, Windsor, .NET