Thread Local: A Convenient Abomination.

A couple of weeks ago i tried to find a storage place for sessioncontext(s)  so that one WinForms application could have multiple sessions open at a time. I noticed that there are no easy solutions for that problem. Today i read an article that describes the other side of the coin.

Thirteen years ago, while working on my first book, Jim Coplien and I were having a debate on the nature of threads and objects. He made a clarifying statement that has stuck with me since. He said: “An object is an abstraction of function. A thread is an abstraction of schedule.”

It has become the norm, in Java applications, to assume that there is a one-to-one correspondence between a thread, and a unit-of-work. This appears to make sense since every Servlet request has it’s own particular thread. Framework authors have built on this assumption by putting unit-of-work related information (e.g. session) into ThreadLocal variables.

Clearly, the more ThreadLocal variables that hold unit-of-work related information, the more that the thread and the unit-of-work are related. While very convenient, the basic assumption is dead wrong.

It doesn't matter if you have 1 or 10 threads. The problem is always the same. UnitOfWork or SessionState should have a place that does not depend on threads. It's a dangerous assumption that UnitOfWork is directly related to one single thread. That assumption seriously limits your other architectural choices. 

So, though convenient, ThreadLocal variables confuse the issue of separating function from schedule. They tempt us to couple function and schedule together. This is unfortunate since the correspondence of function and schedule is weak and accidental.

What we’d really like is to be able to create UnitOfWorkLocal variables.

Couldn't agree more.

 

Technorati Tags: WinForms

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

Visual Web GUI

Visual Web GUI is a solution that allows you to write a winforms application and at compile time transform it into an ASP.NET application. The application has same look and feel as winforms applications and it will behave exactly as the winforms application does. So instead of creating an ASP.NET page you create a VWG-form. At Build time the form and controls are translated into ASP.NET, Ajax and JavaScript code.

I’m speechless. The whole thing is so amazing that you must see it before you believe it. Take a look at it.

And the whole stuff is open source and licensed under LGPL.

Roy Osherove wrote more about VWG.

Google moon

Amazing details from the moon!

Remember to zoom it enough!

Douglas Crockford on programming and quality

Douglas Crockford presentation on Quality.