Home > dotnet 4 > Windsor Installer in Castle Windsor

Windsor Installer in Castle Windsor

A friend of mine was going through the asp.net mvc storefront starter kit project by Rob Conery. It’s really a nice little MVC project which guides you on how to build a real life project and the step-by-step 24 series webcasts on how to build it great.

The project implements StructureMap as the IoC container and my friend asked me if CastleWindsor has anything equivalent of the registry class.

No way this post is about which IoC container is better than the other in fact I think all are quite good and I like CastleWindsor as I am more familiar with it and it has some really good extensibility point. In the Storefront Starter Kit project the IoC registration happens through the Bootstrapper class which has the following code.

namespace Commerce.MVC.Web {

    public static class Bootstrapper {

        public static void ConfigureStructureMap() {

            StructureMapConfiguration.AddRegistry(new DBServiceRegistry());

            StructureMapConfiguration.AddRegistry(new StorefrontRegistry());

        }

    }

and the StorefrontRegistry class looks like


   public class StorefrontRegistry : Registry {

        protected override void configure() {

           
            ForRequestedType<IOrderService>()

                .TheDefaultIsConcreteType<OrderService>();

           
            ForRequestedType<ICatalogService>()

                .TheDefaultIsConcreteType<CatalogService>();

            ForRequestedType<IOrderRepository>()

                .TheDefaultIsConcreteType<SqlOrderRepository>();

       //rest of the implementation..

       }

  }

and the equivalent registry class in CastleWindsor is the IWindsorInstaller interface and this is the implementation of the interface it :-

 public class StorefrontInstaller : IWindsorInstaller

    {

      public void Install(IWindsorContainer container, IConfigurationStore store)

      {

          container.Register(

                Component.For<IOrderService>().ImplementedBy<OrderService>(),

                Component.For<ICatalogService>().ImplementedBy<CatalogService>(),

                Component.For<IOrderRepository>().ImplementedBy<SqlOrderRepository>()

                // Rest of the implementation …

            );

      }

   }

And this is how the bootstrapper method will look like with the windsor container.


   public static class Bootstrapper {

       public static void ConfigureWindsorCastle(IWindsorContainer container)

       {

          container.Install(new StorefrontInstaller());

            // Other Installer for the system…

       }

   }

 

As you can see most of the concept are quite similar in most of the IoC container and it’s not which is better than which one but it’s the design principle and how you see best fit for your design.Just don’t use IoC if you just want to do something like for an interface IMyClass you have a class MyClass and you want to inject it like

 

container.Register(Component.For<IMyClass>().ImplementedBy<MyClass>());
 

Use the SOLID design principle to design these interfaces, apply the Single Responsibility principle and DRY(Don’t repeat yourself) to design these interfaces,classes and then use the IoC container to inject the dependencies.

I thing it is a good pattern to get your component registered with your IoC container and also gives modularity on injecting these dependencies

Advertisements
  1. Tj
    September 9, 2010 at 12:32 am

    great…

  2. !40Winks
    September 13, 2010 at 12:58 pm

    These days I find IDon’tC than IoC, Prashant. I thought my work was rock SOLID until a colleague informed me it was dull and DRY. Moreover, I’ve become so sick of BootStrappers that now I wear shoes without laces. I guess all those software IOU’s finally caught up with me.

  3. September 15, 2010 at 1:41 am

    !40Winks :

    These days I find IDon’tC than IoC, Prashant. I thought my work was rock SOLID until a colleague informed me it was dull and DRY. Moreover, I’ve become so sick of BootStrappers that now I wear shoes without laces. I guess all those software IOU’s finally caught up with me.

    Hi Nathan,
    Good to hear your comment and I understand what you mean ;-). Weather you wear shoes with laces or without laces but I know you will always go for a SOLID and your information is not DRY as you do follow DRY ( Don’t Repeat yourself ) ;-). Hope to hear from you and your wisdom and comments always welcome 🙂

  4. sasireka
    August 12, 2011 at 6:52 am

    Great !!!.

    I am new to castle windsor. I have searched lot of websites for what is castle windsor and so on.Some of the websites they register the component using container.AddComponent() and some of them used container.Register(). Could you please tell me the difference between those methods.

    • August 12, 2011 at 10:29 pm

      Hi Sasireka,
      The container.AddComponent() method is obsolete and was used in older version of Windsor castle, and I recommend using the fluent api to to register your components.

  5. sasireka
    September 19, 2011 at 9:44 am

    Hi,

    I need another help about castle windsor.

    Could you please tell about how to check whether the particular assembly registered or not in the castle container.

    Actually i am using the below code for register the assembly. i need to avoid the registering process, if it was already registered.

    container.Register(AllTypes.FromAssemblyNamed(pAssemblyName).Pick().WithService.DefaultInterface());

    • September 20, 2011 at 8:34 pm

      Hi Sasireka,
      I think the best way to tackle this issue by designing your solution more correctly. First thing first your project must have some sort of BootStrapper project which is the central place of registering your components in Windsor Castle. And the second would be that you must have a unit test in which you just run the BootStrapper code and then try resolving the new interface you have added to your project, these two approach will make sure that the Infrastructure is ready before you start using the system.

      Remember the TDD principle what ever you design you should be able to test before you start using it.

  1. July 19, 2011 at 9:11 pm

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

%d bloggers like this: