What conventions / idioms / patterns do you use to configure IOC containers using the new Free interfaces

Question

I am in the middle of navigating a lot of code in Castle Trunk, which includes a new free interface for setting up a container. Since the project has a huge xml file of the windsorConfig file that is not amenable to maintenance, I thought I would start using this new function. I know that other containers (e.g. StructureMap 2.0) also contain smooth interfaces for configuring the container, so this question is not based on Windsor.

My question is, what conventions / idioms / patterns do you use to configure the container using the new fluent style interfaces?

My first thought was to create a static method somewhere (e.g. ContainerConfig.Config) that would load all the relevant types that the application uses in the container. My concern, after all, is that this monolithic function will turn out to be almost as indispensable as the xml configuration file (minus the angle tax).

My second thought was to break it so that each dependent assembly, by convention, would export its default configuration. I see that this is useful for hierarchies used inside the assembly. But for types used externally, should configuration be defined internally?

The more I thought about it, the more questions I raised. What do you think about this?

Answer 1

Take a deeper look at StructureMap 2.5. It offers several features that significantly reduce the workload for loading an IOC container. It offers a configuration agreement (see blog entries below)

See the following recent blog posts by Jeremy Miller (author of StructureMap)

Create Your Own Automatic Registration Convention with StructureMap

// Example from the blog post above var container = new Container(registry => { registry.Scan(x => { x.TheCallingAssembly(); x.With<DefaultConventionScanner>(); }); }); 

StructureMap 2.5.2 Released

Answer 2

I had a project in which we used Unity, and I watched a video about StructureMap, and I really liked the idea of ​​registration from the very beginning.

So, I created the following interface:

 /// <summary> /// An interface which must be implemented to create a configurator class for the UnityContainer. /// </summary> public interface IUnityContainerConfigurator { /// <summary> /// This method will be called to actually configure the container. /// </summary> /// <param name="destination">The container to configure.</param> void Configure(IUnityContainer destination); } 

And aggregates have a default Configurator class. We also wrapped our Unity IoC with a static class so that we can call IoC.Resolve<T> , and I just added the following functions to this shell:

  /// <summary> /// Configure the IoC /// </summary> public static class Configure { /// <summary> /// Configure the IoC using by calling the supplied configurator. /// </summary> /// <typeparam name="TConfigurator">The configurator to use</typeparam> public static void From<TConfigurator>() where TConfigurator : IUnityContainerConfigurator, new() { From(new TConfigurator()); } /// <summary> /// Configure the IoC using by calling the supplied configurator. /// </summary> /// <param name="configurationInterface">The configurator instance to use</param> public static void From(IUnityContainerConfigurator configurationInterface) { configurationInterface.Configure(instance); } // other configuration. } 

So, in the initialization form, either the program or the website I just called:

 IoC.Configure.From<BLL.DefaultMapping>(); 

There is a class in BLL similar to this:

 public class DefaultMapping:IUnityContainerConfigurator { public void Configure(IUnityContainer destination) { destionation.RegisterType<IRepository, SQLRepository>(); // and more.. } } 

The only drawback is that all of your layers are associated with the selected IoC container.

Update . After this answer, I posted an article on my blog containing Unity wrapper .

Answer 3

Difficult questions [and I'm not an IoC expert], but keep in mind that any "monolithic static function" should not be nearly as scary as the configuration file. You can define your own conventions for things and try to abstract things out. I use Ninject, but for Windsor, I would suggest that it would include short small functions, using things like Register with the AllTypesOf strategy:

 kernel.Register(AllTypesOf<ISomethingProvider>. FromAssembly(Assembly.Load("SomeAssembly"))); 

I don't know how internal hierarchies export their own default configuration. It seems a little scary and upside down.

Answer 4

You can try to study the structure of Ninject. Very simple, smooth interface and lightning fast;) No XML configuration and API are quite simple. Highly recommended

Ninject