Contents tagged with Autoregistration

  • Ioc Comparison: Autoregistration in Autofac

    Autofac is a capable and interesting IoC container. I  looked at Autofac for basic IoC here. Implementing my suite of autoregistration tests in Autofac did not require any custom extension classes, autofac handled everything that I asked of it.

    Autofac adds registrations in an atomic manner, like StructureMap. But Autofac doesn't use lamdbas - you configure a ContainerBuilder in as many steps as needed, and then create a container from this builder in a single operation.

    Continue reading...

  • IoC comparison: Autoregistration in StructureMap

    The StructureMap IoC container has guidance on using Autoregistration which I followed. Earlier I put StructureMap through its paces for basic IoC.

    For Autoregistration, StructureMap uses lambdas, even nested lambdas. The interface is not fluent. The basics are quite simple. StructureMap feels a bit like Ninject under the hood, and there are similarities – both do automatic resolution of unregistered types, and both need custom code to do more complicated Autoregistration scenarios. Both are perfectly usable with a bit customisation.

    Continue reading...

  • IoC comparison: Autoregistration in Ninject

    The Ninject IoC container has an extension that does autoregistration, or "Convention based binding" as they call it.  I have looked at basic IoC in Ninject before, and I quite like it. Autoregistration is not a third party add-on, but is part of the ninject source tree here on github. Ninject autoregistration does not work in quite the same vein as Windsor or Unity's fluent interfaces, but it feels like the "Ninject way", i.e. similar to the other parts of ninject such as using classes as modules.

    Continue reading...

  • IoC comparison: Autoregistration in Microsoft Unity

    The Microsoft Unity container does not include autoregistration, so you could do without it, roll your own or use the Unity Auto Registration addon by Artem Govorov. This post looks at Unity with this addon. Like Windsor's autoregistration API, it also uses a fluent interface. Unity's fluent interface starts with the extension method ConfigureAutoRegistration, then follows one or more Include(FilterPredicate, Then.Register.As… ) blocks, and ends with ApplyAutoRegistration();

    Continue reading...

  • IoC comparison: Autoregistration in Castle Windsor

    Castle Windsor emphasises autoregistration, probably more than any other .Net IoC container, and the API to do it is probably the most complete.

    Windsor's explicitness about registration - the lack of automatic resolution of unregistered concrete types - turns out to be an asset with autoregistration. In a sense, automatic registration and automatic resolution are two different approaches to the same problem of convention over configuration in that they allow you to create types without mentioning them in the container configuration. But they don't play that well together, and can give confusing results.

    Continue reading...

  • IoC containers: Autoregistration tests groundwork

    I have put together an assembly containing some types used to test the autoregistration features of different Inversion of Control containers.

    I will put some IoC containers (starting with Windsor) through a set of tests over these classes. The IoC container will have to find a concrete class, find an implementation for an interface, and find all implementations of a interface where multiple types implement it.

    Continue reading...

  • IoC containers: an introduction to Autoregistration

    I attended a talk by Krzysztof Kozmic at NDC2011 on IoC container patterns and antipatterns. Krzysztof contributes to the Castle Windsor IoC container, so it centered around Windsor. 

    I specifically want to talk about autoregistration, since this was a major topic of the talk, and is a best practice (at least it is in Windsor) and one that I have been gearing up to cover.

    Continue reading...

  • 1