Windsor custom lifestyles

Windsor provides you with a pretty limited array of options when it comes to lifestyles:

  • Singleton: each time you resolve, you get the same instance. This is, for some reason, the default lifestyle
  • Transient: each time you resolve, you get a new instance. This is what I would have wanted as default :-)
  • PerThread: it pools a singleton for each thread, so you’ll always get the same instance if you call resolve from the same thread.
  • Pooled: the documentation is not very clear about this but from the source code it seems that a pool with a given capacity is created and on each resolve one of the objects from the pool is returned. I didn’t check how which object to return is determined.
  • there’s also an undocumented PerWebRequest lifestyle and I assume it does just what it says on the tin.

Let’s say that, as it was in my case, you need a container behavior a little different than one of these: you want the container to return a different instance based on a parameter used during the type’s activation. Example:

 
IDictionary argumentsOne = new Hashtable();
argumentsOne.Add("entity", apple);
_container.Resolve<IViewModel>(argumentsOne); // a new instance 
IDictionary argumentsTwo = new Hashtable();
argumentsTwo.Add("entity", pear);
_container.Resolve<IViewModel>(argumentsTwo); // another new instance
IDictionary argumentsThree = new Hashtable();
argumentsThree.Add("entity", apple);
_container.Resolve<IViewModel>(argumentsThree); // the same instance as when called with argumentsOne

So, to get this kind of behavior from your container you need to implement your own CustomLifestyle. The easy way to do it is to subclass AbstractLifestyleManager, which provides you with some methods you can override. The interesting ones are:

  • Resolve which gets called when you try to resolve the type
  • Release which gets called when you try to release the type
  • Dispose which works as usual
  • Init, a callback invoked when your CustomLifestyle gets constructed

Obviously, Resolve should return the instance of the type, be it from your cache or from calling base.Resolve, which should get you a new one. Release should delete the right element from the cache so the next time Resolve is called a fresh instance is returned.

Here follows a sample implementation for the above scenario.

 
public class PerEntityLifestyleManager : AbstractLifestyleManager
    {
    private IDictionary<object, object> _instances = new Dictionary<object, object>();
        
    public override object Resolve(Castle.MicroKernel.CreationContext context)
    {           
        object param = context.AdditionalParameters["entity"];
        if (!_instances.Keys.Contains(param))
        {
            _instances.Add(param, base.Resolve(context));
        }
        return _instances[param];
    }

    public override bool Release(object instance)
    {
        if (_instances.Keys.Contains(instance))
        {
            _instances.Remove(instance);
            return true;
        }
        return false;
    }
}

You should then apply your lifestyle to the types you want to be resolved with it as an attribute, like this:

 
[CustomLifestyle(typeof(PerEntityLifestyleManager))]
public class MyClass : IMyInterface
{
   
}

Is C better than Ruby?

Yesterday I stumbled into this through hacker news and well, maybe the guy hasn’t really grasped the whole client-server paradigm thing but here he really made a point :

We’re engineers, and we make machines work. You use the best tool for the job to do that. You don’t choose some pretty language [Ruby] that “brings back the joy of coding” or equivalent hippy shit.

And more:

C is the dominant language right now and probably for the distant future. It’s the lingua franca of computing. Nearly every server application worth a damn is written in C.

Well, the guy here maybe needs to chill out a bit but I think he’s right: C is here to stay. Planning to use anything else for a large project where performance is crucial is insane (Java and C#, you heard me :-)). C is a really powerful and valuable tool, and every developer should have at least some knowledge of it: I started out with C64 Basic, then Assembly for a long, long time, then lots of C, after that Java, VB, C# and then Ruby. I know people like Why are promoting Ruby as a learning language but honestly, I can’t really imagine someone with no knowledge of C writing good Ruby.

But probably in the 70′s somebody made similar statements, just replacing C with FORTRAN. Right now, C is the language. What about it in 10 years? I’m really, really surprised every time I read such statements: they make me feel like story never happened. No wonder Berlusconi is gonna win the elections with 70% of the votes next week.

And even if C is the best all-purpose tool we have now, what’s the point in using it even if the situation would allow a not-so performant but much more pleasant to use tool instead? Is there some kind of pride to gain in being miserable doing your job that I’m not seeing? Ruby performs like crap, but it’s a pleasure to work with. And 99% of the times nobody cares about performance.

All these things have been said countless times by people way more authoritative than I will ever be but it seems there’s still need to state them clear…

Castle windsor oddities

I was at a customer today and they had a quite interesting situation to show me, and here it is.

Let’s create these dummy entities:

Entities

Entities

And now let’s register them the same way they did and see what happens when trying to resolve a Person:

result

As you can see Windsor actually “resolves” both Address and Job as if they were a dependency, setting both of them as a new instance! I don’t really think this is a bug but it’s totally not what I expected…

Having interfaces in between (so IPerson, IAddress and IJob) and then trying to resolve IPerson solves the “problem” (so I get a person with null Address and Job).