Fluent Interface – Programmatically Registering with Windsor

Castle Windsor is my ‘favorite’ IOC – as it offers quite a bit of functionality, and it’s fairly easy to understand and setup.  Let’s review how to programmatically add components to the container.

By default the registration of components is all done via xml configuration files.  However, Castle Windsor does support programmatic registration of components to the container.  Why would you do this?  Well, one example is where I register components in ‘one fell swoop’ that exist in an assembly, making it completely hands off when adding a new component.  Due to the autowiring nature of Windsor, most of the work is done by the container.  Let’s look at an example:

ie. I have an assembly with my ‘services’ and assembly with my ‘dao’s’.  

The flow is:  My controller uses ‘service(s)’.  My services uses dao(s).

Controller => Service Layer => Dao/Repository Layer

I’ll pseudo code this:

//The controller

public class EmployeeController
   private readly IEmployeeService EmployeeService;
  public EmployeeController(IEmployeeService EmployeeService)
        this.EmployeeService = EmployeeService;

  public ActionResult SaveEmployee(string id)
       Employee employee = EmployeeService.GetEmployeeById(id);
       employee.FirstName = ….
       return ….


//The Service:

public class EmployeeService : IEmployeeService
   private readly IEmployeeDao EmployeeDao;
  public EmployeeService(IEmployeeDao EmployeeDao)
        this.EmployeeDao= EmployeeDao;

  public void SaveEmployee(Employee employee)
     using(ITransaction trans = …BeginTransaction())

//The Dao:

public class EmployeeDao : Dao<T>
      …. Save(T entity)…

So we have our tiered environment, the controller passes off the employee object ‘stuff’ to the service.  The service handles the transactional aspects, etc… and calls the underlying Dao database calls.  The beauty here, it’s all constructor injection, no ‘new object’ etc…

So, along comes Castle Windsor.  If you noticed, I’m using a controller with action result – that is from asp.net mvc.  The MvcContrib contains code to register the controllers with the container, which can be accomplished in three lines of code in the startup of the application (Global.cs):

IWindsorContainer _container = new WindsorContainer();
ControllerBuilder.Current.SetControllerFactory(new WindsorControllerFactory(_container));

After that we can register the services and daos:

                        .Configure(c => c.LifeStyle.Transient)
                        .If(s => s.Name.Contains("Service"))

This fluent interface sample will look at each type in the Service assembly, were name contains ‘service’, and then add the interface.  (This does require a bit of naming convention on my part, ie. EmployeeService : IEmployeeService  – ‘service’ in the name, however, I do like that if I want to exclude something it can be done quite easily)

The registration of the dao is similiar to above.

                        .Configure(c => c.LifeStyle.Transient)
                        .If(s => s.Name.Contains("Dao"))

So, I’ve registered all the controllers, all the services, and all the daos.  They are autowired by Windsor, meaning, I don’t have to hand by hand register each type with instructions on who uses what – it uses reflection to handle that – seeing for example, that I have a IEmployeeService being injected – so look for that type in the container and create a new one on my behalf.

The last example is : what about the facilities ?  ie. Castle Windsor has great support for EventWiring:


And a great sample by Hammett:


The beauty of this is that you can register your subscribers in the container!  I think it’s fanatastic

We’ll take a similiar example to what Hammett uses.

ie. in my sample (read Hammett’s blog), WITHOUT Windsor, we’d have to code up all the registrations, etc…:

INotificationService notification = new DefaultNotificationService();

SuccessSubscriber subscriber1 = new SuccessSubscriber();
FailedSubscriber subscriber2 = new FailedSubscriber();

notification.Succeeded += new NotificationHandler(subscriber1.OnSuccess);
notification.Failed += new ErrorNotificationHandler(subscriber2.OnFailure);

TheService service = new TheService(notification);

//use the app:

Let’s see what is would be like with Castle Windsor and a configuration file:

Here is my config fi
le that we will convert to the fluent registration:

<?xml version="1.0" encoding="utf-8" ?>

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


            <facility id="event.wiring"
                      type="Castle.Facilities.EventWiring.EventWiringFacility, Castle.MicroKernel" />


            <!– Subscribers –>

            <component id="SuccessSubscriber"
                       type="MyEventSample.SuccessSubscriber, MyEventSample" />
      <component id="FailedSubscriber"
                       type="MyEventSample.FailedSubscriber, MyEventSample" />

            <!– Notification service –>

            <component id="notification.service"
                       service="MyEventSample.INotificationService, MyEventSample"
                       type="MyEventSample.DefaultNotificationService, MyEventSample" >
                    <subscriber id="SuccessSubscriber"
                    <subscriber id="FailedSubscriber"

            <!– Services –>

            <component id="TheService"
                       type="MyEventSample.TheService, MyEventSample" />


So, we tell Castle about the facility.  We add our components that are being used.  Then we add our subscribers in the notification service:

WindsorContainer container = new WindsorContainer(new XmlInterpreter(new ConfigResource()));

TheService service = container.Resolve<TheService>();

That is excellent – in 3 lines of code, we have all our subscribers wired up, etc… In this example, we are telling the container to read the configuration file above.

But what if, we want to dynamically register these components, without the xml (the point of the blog post – lol) ?

We do so using the fluent interfaces – with special attention given to ‘how to register a facility’:

Here is the code:

IWindsorContainer container = new WindsorContainer();
160;                             Attrib.ForName("handler").Eq("OnSuccess")

Then it is used the same way as above:

TheService service = container.Resolve<TheService>();

With some imagination, you can see how easy it would be to register all subscribers in an assembly, all services in a assembly, then wire them all up dynamically.

(To see how I did the facility you can look at this test)

So in summary, you can add items to the config, and read it.  Or you can dynamically add them in code.  It is possible as well to mix the two.  I initially did this, where I load the config with the subscriber information, then add in my components programmatically.

I hope this helps, if anyone would like some sample code to go along with this, I can provide it – just let me know. 


3 thoughts on “Fluent Interface – Programmatically Registering with Windsor

  1. Hi, could you post how to wire all handlers/subscribers dynamically? I would like to avoid wiring the event one by one. Thanks for the great article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s