Part 9 - Constructor Injection

9_constructor_injection.png



Constructor injection - so far inadvertantly we've been using setter inject to get our configuration information into our components... but you can also use constructors... the useful aspect of constructors is that it makes those parameters compulsory...



So lets take a look at the code for this post, first off there's an interface for a service which takes care of encoding a string for us:


public interface IEncoder
{
string Encode(string source);
}


And then we have no classes which implement this service, one we can use when testing to not encode things at all - and another which encodes a string using our particularly strong "silly" encryption...



NullEncoder.cs

public class NullEncoder : IEncoder
{
public string Encode(string source)
{
return source;
}
}


SillyEncoder.cs


public class SillyEncoder : IEncoder
{
private char[] _mixedUp = "YACBDFEGIHJLKMONPRSQTUWVXZ".ToCharArray();

public string Encode(string source)
{
string upperSource = source.ToUpper();
char[] encoded = new char[source.Length];
for (int i = 0; i < encoded.length;="">
{
encoded[i] = MapCharacter(upperSource[i]);
}
return new string(encoded);
}

private char MapCharacter(char ch)
{
if ((ch >= 'A') && (ch <=>
{
return _mixedUp[ch - 'A'];
}
return ch;
}
}



When then have a class for sending messages (currently we just send it to the console, so we can print them out and paste them onto the back of postcards) ... so lets have a look at that class:


public class SecretMessageSender
{
private readonly IEncoder _encoder;
private readonly string _from;

public SecretMessageSender(string from, IEncoder encoder)
{
_from = from;
_encoder = encoder;
}

public void SendMessage(string to, string body)
{
Console.WriteLine("to: {0}rnfrom: {1}rnrn{2}", to, _from, _encoder.Encode(body));
}
}



Notice the lack of default constructor, and that the constructor also takes an instance of type IEncoder... now Castle is smart enough to do two things for us:
  • Throw an exception if we try to get an isntance of SecreteMessageSender without having set the from configuration parameter.
  • Find the default implementation of the IEncoder registered in the container, and to supply that as the value for the second argument in the constructor.

So lets have a look at the application itself:


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

SecretMessageSender sender = container.Resolve();

sender.SendMessage("hammet", "castle is great!");

Console.Read();
}



And finally our configuration:




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




service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"
type="IoC.Tutorials.Part9.SillyEncoder, IoC.Tutorials.Part9" />


service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"
type="IoC.Tutorials.Part9.NullEncoder, IoC.Tutorials.Part9" />


type="IoC.Tutorials.Part9.SecretMessageSender, IoC.Tutorials.Part9">

SecretMessageSender
alex@bittercoder.com





So you can see we've registered both implementations of the encoder, with the silly encoder being first - so as mentioned in the last part - this will be the default - and we also register our message sender (with the required from parameter)... so what happens when we run it:



to: hammet

from: alex@bittercoder.com



CYSQLD IS ERDYQ!




Cool... but what if wanted to send an unencrypted message... well we have a few options:
  • Swap the order in which the implementations are registered
  • Remove / comment out any implementations we don't want (so comment out the silly encoder)
  • Or reference the implementation we specifically want to wire up to, using it's identifier...

So lets have a look at the last one...




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




service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"
type="IoC.Tutorials.Part9.SillyEncoder, IoC.Tutorials.Part9" />


service="IoC.Tutorials.Part9.IEncoder, IoC.Tutorials.Part9"
type="IoC.Tutorials.Part9.NullEncoder, IoC.Tutorials.Part9" />


type="IoC.Tutorials.Part9.SecretMessageSender, IoC.Tutorials.Part9">

SecretMessageSender
alex@bittercoder.com
${encoder.null}





Notice the way the parameter is formatted - instead of the markup for a property reference which starts with a hash (#) we start service references with a dollar sign ($) and then surround the components identifier with braces.



And the results of running the app now:



to: hammet

from: alex@bittercoder.com



castle is great!



And thats our first look at constructor injection... we will revisit constructor injection again in later posts, however the next part will look at setter injection.
Read More

Container tutorials...

So I've decided to do a quick little series on the windsor container - all up It'll probably cover 15 to 20 posts... each one should be very short, covering some small concept... just a little nugget.

This series will be a little different then most discussions on IoC and containers... rather then get in your face with concepts like dependency injection, and encouraging testability, it's just going to focus on the container itself, and the ways you can use it... I'm not sure if it'll be of any value, but If nothing else to gets me back into blogging regularly.

The first 7 parts are already up:


I'll be posting them in batches... so the series should be finished within a week.
Read More

Part 8 - Referencing implementations by key

8_implementations_by_key.png

So far we've looked at registering one implementation for any one service, you could call them the "default" implementation, because it's the implementation the container returns when you ask for that service... but your not limited to only having one implementation registered, and the way to do this is by giving each implementation that's registered a unique key.


There are many reasons for doing this... but in this example we'll look at one reason - because we want to vary the configuration info used...


So here's our component's code:



public class FileReader
{
private string _fileName;

public string FileName
{
get { return _fileName; }
set { _fileName = value; }
}

public string ReadToEnd()
{
return File.ReadAllText(_fileName);
}
}



It's a simple class which lets us read the contents of a file as many times as we like... so we're going to try registering it twice, with different configurations (and different identifiers) in the container.




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



file1.txt


file2.txt






So far so good, lets have a look at the app itself - notice that the file1Reader and file2Reader instances are "resolved" with an extra parameter - which is the id, or key, used to select a
particular implementation... but what about the default instance, which reader will that be?


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

FileReader defaultReader = container.Resolve();
FileReader file1Reader = container.Resolve("reader.file1");
FileReader file2Reader = container.Resolve("reader.file2");

Console.WriteLine("Default contents: {0}", defaultReader.ReadToEnd());
Console.WriteLine("File1 contents: {0}", file1Reader.ReadToEnd());
Console.WriteLine("File2 contents: {0}", file2Reader.ReadToEnd());

Console.Read();
}



And here's the results of running the program:



Default contents: This is the contents of file 1.

File1 contents: This is the contents of file 1.

File2 contents: This is the contents of file 2.




So you can see that file1Reader and defaultReader are the same - and file1Reader was the first FileReader to be registered in the container -and that's the rule, the first one
registered is the default... which is another example of convention over configuration with Castle, rather then having to explicitly denote which is the default with some more xml noise.


Though with a little thinking you can find plenty of ways to access implementations by key to solve certain problems, for the
unimaginative ... how about an application where you can provide a uri to send plain text messages to ... and depending on the scheme
you need to find an implementation that can do the work of sending the message.



You have a bunch of destinations, addressed by Uri...
  • file://c:/temp/log.txt
  • ftp://ftp.google.com/log.txt
  • http://www.bittercoder.com/SimpleMessageService.aspx
  • fax://64215559555


And then you can just register the implementations/schemes you wish to support...
  • messageSender.file
  • messageSender.ftp
  • messageSender.http
  • messageSender.fax

And then look them up as required, using something like


Uri uri;
// blah blah blah
string key = "messageSender."+ uri.Scheme;
if (container.Kernel.HasComponent(key))
{
ISender sender = container.Resolve(key);
// send the message at this point...
sender.SendMessage("hi there");
}
else
{
// no implementation registered...
throw new NotImplementedException("no sender registered for scheme: " + uri.Scheme);
}


Personally I wouldn't do this ;o) but there's certainly no technical reason why you couldn't... notice how we check that a
component is registered for that key - we could just let the container throw an exception... but then we wouldn't know how to
check that a container has a certain key registered in it, would we!



The next part will be on constructor injection... and following that setter injection.
Read More

Part 7 - Switching implementations



So this time we're going to look at how you can not only change configuration for a component at runtime, but actually change which component is doing the work for us... powerful stuff :)



So the "trick" here is to abstract out what features we expect our component to support from it's implementation, and stuff those into an interface... so in this case I have an idea for a simple service which lets us get the "message of the day" - so lets look at my interface:


public interface IMessageOfTheDay
{
string GetMessageOfTheDay();
}


Now we have two implementations of this service, one that lets us have a static message set via configuration:


public class StaticMessageOfTheDay : IMessageOfTheDay
{
private string _message;

public string Message
{
set { _message = value; }
}

public string GetMessageOfTheDay()
{
return _message;
}
}



And another, which goes to wiki quotes and grabs the quote of the day:


public class WikiQuotesMessageOfTheDay : IMessageOfTheDay
{
public string GetMessageOfTheDay()
{
WebClient client = new WebClient();
string content = client.DownloadString("http://en.wikiquote.org/wiki/Main_Page");

string toFind = "

";
int start = content.IndexOf(toFind) + toFind.Length;
int length = content.IndexOf("

return content.Substring(start, length);
}
}



so - our program is pretty simple:


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

IMessageOfTheDay motd = container.Resolve();

Console.WriteLine("MOTD: {0}", motd.GetMessageOfTheDay());

Console.Read();
}



And so how do we swap between implementations, well we need to introduce an additional attribute to our components configuration called "service" where we specifiy what service our component implements... in this case it will be "IMessageOfTheDay" - so heres the configuration when using the Static MOTD class:





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




service="IoC.Tutorials.Part7.IMessageOfTheDay, IoC.Tutorials.Part7"
type="IoC.Tutorials.Part7.StaticMessageOfTheDay, IoC.Tutorials.Part7">

Welcome to my container tutorials






And running the program gives us:



MOTD: Welcome to my container tutorials



But we can now swap to a different component with the same service at run-time, and get a different implementation... here's how that looks:




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



service="IoC.Tutorials.Part7.IMessageOfTheDay, IoC.Tutorials.Part7"
type="IoC.Tutorials.Part7.WikiQuotesMessageOfTheDay, IoC.Tutorials.Part7" />




And now running the program gives us:



MOTD: Man is not an end but a beginning. We are at the beginning of the second week. We are children of the eighth day.



A quote from Thorton Wilder - exciting huh, this seperation between interface and implementation is what makes doing so many cool things with an Inversion of control container possible... soak up the idea.



Next time we'll take a look at getting different implementations by using their "key" - have you been wondering what the "id" attribute is for in our component definitions?? Well wonder no more.
Read More

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.
Read More