Home > dotnet 4, SOLID > Service locator pattern with Windsor Castle

Service locator pattern with Windsor Castle

I have done a couple of post on SOLID and interface driven design and I hope it gives you some insight into designing the architecture, and how you leverage good design principles and architecture to develop a loosely coupled systems.

For me it’s the architecture which is more important than the actual technology. As you can see some of my examples are in ASP.NET MVC, but it can be applied to any technology.

You can’t just use SOAP, web XML RPC and call it a loosely coupled architecture. It’s the interface design( the contract ), the separation of concern and SOLID principles which gives a  remarkable design.

One of the key thing to which I give a lot of emphasis is Inversion of Control/ Dependency Injection principle. Like other principles it is a very simple one and it’s not limited to ASP.NET MVC. If you are doing any workflow development, SOA services, enterprise level web services, integration project, middleware anything consider using this principle as well. As your system grows you will see it benefits.

If you want to know what a service locator pattern is then please refer to architecture and patterns guru Martin Fowler here. The idea is to have one registry of object and it’s dependencies and the service locator will find these services and register with the Ioc container.

One more important things is that when i talk about services it has nothing to do with SOA and web services. Consider it as a component which implements an interface and does the job. This is more of an architecture debate and I leave it up to you guys to decide what to call what, important thing is loosely coupled architecture and components.

So in order to use service locator with castle windsor you have to download it from the codeplex website. The service locator is also available for others IoC/DI like SPRING.NET, Unity, StructureMap , Autofac etc and you can get it from codeplex. Add the WindsorServiceLocator.cs file to your project.

 

Add reference to castle.core.dll and casle.windsor.dll in your project, if you’re new to Castle windsor please refer to my previous article “Getting started with Castle Windosr” in order to get up and running with it.

Now we will start thinking . . .

As we know that Castle Windsor has an interface call IWindsorInstaller and it has got just one method contract i.e Install. Which is quite fantastic as we are already seeing some SOLID principle i.e. Interface Segregation and Single Responsibility :)

Lets make use of this interface and create some installers. I prefer it this way as you are compartmentalized how your components(services) will get register with your IoC container

 

public class PersonInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<IPerson>().ImplementedBy<Person>()
            );

    }
}

and a couple more for a better illustration.

public class LoanApprovalServiceInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<ILoanApprovalService>()
                     .ImplementedBy<LoanApprovalService>()
            );

    }
}

 

public class CreditHistoryCheckInstaller : IWindsorInstaller
{
    public void Install(IWindsorContainer container, IConfigurationStore store)
    {
        container.Register(
            Component.For<ICreditHistoryCheck>()
                    .ImplementedBy<CreditHistoryCheck>()
            );

    }
}

 

This is just an example and I am sure in a real life production system each of these units(installers) will have many components registering.

Now what we are going to do is register these installers with our IoC container and ask service locator to search for these installers and execute the install method in each installer .

 

IWindsorContainer container = new WindsorContainer();
var servicelocator = new WindsorServiceLocator(container);
container.Register(
    Component.For<IWindsorInstaller>()
             .ImplementedBy<PersonInstaller>(),

    Component.For<IWindsorInstaller>()
             .ImplementedBy<CreditHistoryCheckInstaller>(),

    Component.For<IWindsorInstaller>()
             .ImplementedBy<LoanApprovalServiceInstaller>()
    );

ServiceLocator.SetLocatorProvider(() =>
                        new WindsorServiceLocator(container));

var installers =
    ServiceLocator.Current.GetAllInstances<IWindsorInstaller>();

foreach (var installer in installers)
{
    installer.Install(container,null);
}

 

In the code you will not see much advantage as it is quick prototype but imagine when your system is big and you have 100+ or 500+ interfaces and services.This is where you are thinking like an architect and thinking, how much the system will grow? how you will cope up with the changes ? and what different blocks and component you can chop and change without affecting other parts of the system ?

Suppose for above example in PersonInstaller along with Person I have a PersonRule component which implements a business rule (behaviour)and that rule changes you simply change the PersonRule component by implementing the interface and creating a new class.It’s dependencies on other components will not change as all other components use the interface and not a hard-coded class. It’s your IoC container which will decide which component will get created and not the calling code. (again single responsibility principle)

Hope this will give you some insight into the architecture and design of your current and future projects and feel free to get in touch with me, I still have so many interesting and mind boggling scenarios and ideas.

About these ads
  1. November 24, 2010 at 7:04 am

    Great Article and got an insight into Castle a bit. Used Unity in one of the inherited project, conceptually, both looks similar but not sure if Unity has got this installer functionality in it.

    • November 26, 2010 at 4:44 am

      Thanks Nimesh. Yes Unity is slightly different in regards to Installers although it makes some of the pluming quite easy but I have seen some code where people have really destroyed the SOLID principle of programming becuase of Unity. The problem is in writing that code and not with Unity.

  2. bet365
    November 24, 2010 at 10:44 am

    hi I was fortunate to approach your blog in yahoo
    your subject is terrific
    I learn much in your subject really thank your very much
    btw the theme of you blog is really admirable
    where can find it

    • November 25, 2010 at 10:15 pm

      Thanks a lot and I am glad that you are finding my stuff useful, I will try my best to keep up with the quality and will keep on blogging about interesting stuff which I have come across in my current project.

      BTW the theme is INove and is quite a popular wordpress theme and link to download is http://wordpress.org/extend/themes/inove

      Cheers !!!

      Prashant Brall

  1. November 22, 2010 at 7:58 am
  2. November 22, 2010 at 9:28 am
  3. December 1, 2010 at 6:05 am

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

Follow

Get every new post delivered to your Inbox.

Join 42 other followers

%d bloggers like this: