Part 6 - Switching between lifestyles



Switching lifestyles is the theme of this post... so what's that
all about?



Well first off - what is a lifestyle, in basic terms it specifies how many instances will be available at any one time from the container - so at the one extreme we have components with a transient lifestyle, where any requests from those components will return new instances - and at the opposite end of the spectrum we have singleton components, where there is only one instance for the whole container - there are other types of lifestyle, but we'll leave those for another post.



So first off - castle is all about convention over configuration, and by convention a component in the container is a singleton... so in this example we'll look into ways in which you can switch a components lifestyle to being transient.



First off, heres our component:


public class AddingService
{
private int _total = 0;

public void AddAmmount(int ammount)
{
_total += ammount;
}

public int Total
{
get { return _total; }
}
}



It lets us add stuff... how neat is that... lets see our program:


private static void Main(string[] args)
{
WindsorContainer container = new WindsorContainer(new XmlInterpreter());

AddingService sheepCounted = container.Resolve();
AddingService catsHerded = container.Resolve();

sheepCounted.AddAmmount(10);
sheepCounted.AddAmmount(50);

catsHerded.AddAmmount(3);
catsHerded.AddAmmount(12);

Console.WriteLine("You have counted {0} sheep and herded {1} angry cats", sheepCounted.Total,
catsHerded.Total);

Console.Read();
}



And if we run it:



You have counted 75 sheep and herded 75 angry cats



That doesn't seem right - our service is retaining a count, so we want a fresh instance of the class every time we request it - which means we should shift our component to the "transient" lifestyle - lets have a go at doing it with configuration, by adding the lifestyle attribute to the components definition.




type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />








And now if we run it again:



You have counted 60 sheep and herded 15 angry cats



That looks a bit better... but I propose that in many cases when your writing a component you know what it's lifestyle should be, before it's ever registered in a container - for instance in this case this class should always be transient, so we can actually decorate the class with a "Transient" attribute and can skip having to put the lifestyle in the configuration, this is how that would look:


[Transient]
public class AddingService
{
private int _total = 0;

public void AddAmmount(int ammount)
{
_total += ammount;
}

public int Total
{
get { return _total; }
}
}



There are other lifestyles available to use - it's worth having a look through the castle wiki for more details... and we'll probably cover them in another post.



In the next part we will cover switching out implementations of components themselves.
Written on April 17, 2007