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>();
AddingService catsHerded = container.Resolve<AddingService>();
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 catsThat 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.
<configuration>
<configSections>
<section name="castle"
type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
</configSections>
<castle>
<components>
<component id="adding.service" type="IoC.Tutorials.Part6.AddingService, IoC.Tutorials.Part6" lifestyle="transient" />
</components>
</castle>
</configuration>
And now if we run it again:
You have counted 60 sheep and herded 15 angry catsThat 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.