Getting hands-on for the lazy

So the first 9 posts are up for the container tutorial series...  but I haven't made much mention of what can be done to play around with the windsor container yourself while reading this series.

Well first-off ... my thoughts on getting started with the Castle project are generally practical, first off I think it's worth grabbing the second release candidate - check out what castle can do, have a general play, maybe try to generate a monorail project and get it working... and then ... well I would probably uninstall it, and grab the latest cut of the castle project and contributed projects from svn and build it yourself using nant.

This gives you opportunities to use all the "new stuff" that gets added day by day (as well as bug fixes) but also ensures your actually capable of building and contributing patches for any issues you discover.

But that's a bit of an ask for someone experimenting, especially if you don't know anything about svn... so essentially for playing around with the basics of the windsor container, you only need 4 Castle assemblies from the bleeding edge, and I'll give them to you:

And to make life easy I included those assemblies in a folder called "SharedLibs" as part of the following zip file, which contains the code for the first 9 parts... I'll do another code
drop at the end of the container tutorials to round out the series for the sake of posterity... but everything you need for the first 9 tutorials is here:

Files for Parts 1 thru 9

Good Times ;o)

Read More

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