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:


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.


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?

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 explicity 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


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.