Archive for the ‘Windsor’ Category

Workshop on Inversion of Control Containers

February 18th, 2009

Next Friday (Feb-27) I’ll be in Seattle doing a workshop on one of my favorite topics: Inversion of Control Containers. Expect some digressions on the story of ioc containers, how they evolved, what problems they solve and what problems they introduce. Also why I think the DI term should be banished – call me a purist. Windsor, MEF and maybe others will be on my radar.

If you want to attend, keep an eye on this page. Currently registrations are closed, but should open in a few days.

I truly hope I dont have a cold next week :-)

Some Castle related news

January 5th, 2009

During the holiday – and between Wow quests and dungeons – I’ve managed to apply a bunch of patches and to fix some outstanding bugs on the Components and Windsor projects.

Another interesting accomplishment is some contributions finally made in and Castle.Core, Castle.MicroKernel and Castle.Windsor are now Silverlight ready.

Last but not least, I recently applied a patch that made Castle.DynamicProxy 2 also available for Silverlight.

The pending items now are:

- Fix the build so the bits targeting SL will be correctly build and made available through our build server

- Change Windsor to use the SL version of DynProxy.

Thanks for all the patches, people. Keep them coming! :-)

Castle Windsor and the WCF Facility

December 2nd, 2008

If I recall correctly, Ayende started the WCF Facility several months ago and Craig took over and have been improving it almost daily since then. As a completely ignorant on WCF, I have no idea on how it works and how to use it.. so Mike’s post sure came handy :-)

Given the amount of changes in Craig’s last commit there’s a lot to blog about..

Session on Windsor

November 4th, 2008

Great talk on Castle Windsor from Gojko and Mike.

I especially appreciate that Mike was careful on the terms, patterns and principles – even though I have my disagreements :-) But I’ll refrain from nitpicking. Great talk again, I could never do it better.

Where no man has gone before

June 6th, 2008

Bill seems to have guts. He has posted some of his experience with a custom MonoRail + Windsor solution for a b2b app, and seems to have gone deep to customize the way components are resolved to address a business requirement. His point: majority of his clients deal with orders their own way, instead of branching the code or scattering ifs everywhere, he creates a customized component that deal with those requirement, which is automatically selected based on the client accessing the app.

To have that working, he decided to go down and speak with the devil himself. He embraced the use of containers hierarchy.

First of all a disclaimer: the support for parent/child container was added long time ago to MicroKernel/Windsor, really long time, probably in the first commits. But they never went into a _real_ real world testing. Also, I’m not sure the dependency resolution behavior is safe enough. I implemented support for one-way, bottom-up resolution to prevent someone from doing something really bad, but I’m not sure that’s enough. For all these reasons – plus a gut feeling that I shouldn’t have added this concept in the first place – I strongly discourage its use. And that’s why there are no documentation about it on castle web site, no articles (from me at least), and probably no blog posts.

Now if you like sky skiing, drives a motorcycle without helmet, have a compelling reason to use it, then why not give it a try? :-) Bill knows what he’s doing, though, he has contributed patches that demonstrates a deep understanding of the inner workings of castle.

Another idea that I played for a while was the concept of scoped containers for web apps. Mapping containers to the life styles associated with a web app: application, session, request. That would make simple to have components to lifestyles attached to an user session, for instance. However it’s a lot of work and difficult to test. I’m sure it will be available on Windsor/MonoRail 2.0

MR and Windsor set up screencast

May 26th, 2008

Quick, dirty and unrehearsed. Just show how to set up MR without external configuration, how to get Windsor integration enabled and setting up routing. Created to test Screenflow.

Mov file

Autoregistration without Binsor

May 13th, 2008

On my Global.cs I usually have:

private static void RegisterWebComponents()
{
    container.Register(AllTypes.Of<SmartDispatcherController>().
        FromAssembly(typeof(HomeController).Assembly));

    container.Register(AllTypes.Of<ViewComponent>().FromAssembly(typeof(Global).Assembly)
            .Configure(
                delegate(ComponentRegistration reg)
                {
                    reg.Named(reg.ServiceType.Name);
                }));

}

To get Windsor integration:

First, make the Global implement the IContainerAccessor

public class Global : HttpApplication, IContainerAccessor

Then add a static field to hold the container

private static WindsorContainer container;

The App_Start/End and the IContainerAccessor implementation:

protected void Application_Start(object sender, EventArgs e)
{
    container = new WindsorContainer(new XmlInterpreter());
    container.AddFacility("mr", new MonoRailFacility());

    RegisterWebComponents();
}

protected void Application_End(object sender, EventArgs e)
{
    container.Dispose();
}

public IWindsorContainer Container
{
    get { return container; }
}

To Configure MonoRail using code

Make the global implement IMonoRailConfigurationEvents and implement the method Configure:

public class Global : HttpApplication, IContainerAccessor, IMonoRailConfigurationEvents
{
    public void Configure(IMonoRailConfiguration configuration)
    {
        // Configuring ViewEngine
        configuration.ViewEngineConfig.ViewPathRoot = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "Views");
        configuration.ViewEngineConfig.ViewEngines.Add(new ViewEngineInfo(typeof(NVelocityViewEngine), false));

        // You can configure other things, and hopefully in the future 
        // we can expose a kind of fluent interface to guide you on this process
    }
}

James Kovacs’ article on IoC/Windsor

March 14th, 2008

I remember reading a few months ago on James blog that he wanted to learn Windsor. Guess he did in no time. James’ article is a very nice introduction to the shift of thinking required to use IoC containers.

I still can’t stand this “Dependency injection” term. Someday it will be banished from all computer related literature, publications, books, articles, blogs and even thoughts. In the meantime, I’ll be alone fighting it.

Windsor: for all tastes

March 7th, 2008

So, in donjon code base we have service like the following:

public class AppStarter
{
  public AppStarter(IModuleInstaller[] installers) 
  {
     ...

By default, Castle.MicroKernel will expect you to define what should be included in the array. This can be done through the external configuration or through the code, using the cool fluent interface Craig has developed.

In my case, though, I always want all module installers registered to be available to my service. How to accomplish that?

The first guess is using a custom ITypeConverter implementation. However, those are only used by the container to convert a representation into something that can fulfill a dependency. This is definitely not my case.

Second guess is using a custom dependency resolver. “What? You mean I need to write a new dependency resolver for the whole damn thing?” No, not really necessary. The default dependency resolver allow you to add more sub resolver to handle your special situations. So all I had to do was:

class ArrayResolver : ISubDependencyResolver
{
	private readonly IKernel kernel;

	public ArrayResolver(IKernel kernel)
	{
		this.kernel = kernel;
	}

	public object Resolve(CreationContext context, ISubDependencyResolver parentResolver, 
                              ComponentModel model,
                              DependencyModel dependency)
	{
		return kernel.ResolveAll(dependency.TargetType.GetElementType(), null);
	}

	public bool CanResolve(CreationContext context, ISubDependencyResolver parentResolver, 
                              ComponentModel model,
                              DependencyModel dependency)
	{
		return dependency.TargetType != null && 
			dependency.TargetType.IsArray && 
			dependency.TargetType.GetElementType().IsInterface;
	}
}

And then, when you instantiate your container, you have to register the sub dependency resolver:

Kernel.Resolver.AddSubResolver(new ArrayResolver(Kernel));

A few lines of code, and you just got Windsor doing exactly what you want.

News directly from Castle’s trunk

March 1st, 2008

This has just been committed. Checking the test cases, it shows how it should work:

container.Register( AllTypesOf<IService>.
    FromAssembly( Assembly.Load("MyServicesAssembly") ) );

Check the message for more usage examples. I hope it’s the end of the Batch Registration Facility :-)

Craig, you’re the man!