0

*I have an application which uses an IOC container (Autofac, but could be any).

I also have modules which are developed externally. Each module needs to specify its own setup of the DI container, defining Repositories, Services specific to its module.

At deployment, these modules are then manually registered with Autofac via XML configuration.

Normally if each module wanted to request an instance of a Type from the IOC container we could use a ServiceLocator pattern. This decouples each module from the specific IOC container type, e.g. Autofac/Unity/StructureMap/etc.

But I want to decouple each module from the IOC container at the point of registration. For example when doing the container.Register().As();

All of the IOC containers have different methods to almost achieve the same thing, so I'm wondering if there is a standard pattern for it.

Update: I'm specifically looking for a way to agnosticise the Registering of types rather than the Resolving of type instances.

peter.swallow
  • 905
  • 14
  • 38
  • You would need to write your own facade, which could be tricky considering that IoC containers have different features. – Facio Ratio Apr 26 '13 at 04:12

2 Answers2

5

The service locator pattern has fallen out of favour because of this kind of scenario. Decoupling the modules from the IOC container is definitely a good idea, but the service locator pattern means that they do still need to refer to it in some way. Writing your own generic IOC container wrapper is not a task anyone should have to endure.

A more commonly accepted pattern for this situation would be to inject the dependencies of the modules (most likely through constructor injection) and only refer to the IOC container at the entry point of the code. The modules would then be initialised with all their dependencies satisfied already. Since the IOC container is only referred to in one place, there is no need to abstract it away. You can just pick one, and if you change it later, you only need to change one class in the code.

In other words, whenever a module would ask the IOC container for an instance of an object, rather pass this instance through the constructor of the module. If the object you need to ask for has runtime dependencies, then pass a factory for them through the constructor instead.

For more detail see this article.

Martin Fowler gives a less harsh view on service locators, but I think the conclusion is the same.

Patrick Stephansen
  • 773
  • 9
  • 20
  • Thanks for your comments Patrick. I agree with what you say and am already doing this. I think my question wasn't as clear as it could have been. I'm happy with the Resolving an instance part, but my question is regarding the actual registering of the types to the container in a container-agnostic manner. i.e. the container.Register.As part. – peter.swallow Apr 17 '13 at 16:27
  • This still sounds like almost as much work as building your own IOC container, but I'm not sure I understand the situation. Are you trying to allow external developers to register their dependencies with the IOC container of their choice? If so, making them use a generic wrapper of an IOC container isn't really better than making them use Autofac. I think I'm still missing the point. – Patrick Stephansen Apr 18 '13 at 08:46
  • At the moment they create an Autofac Module within their specific assembly. This allows them to register their types and instances. This Module is then included in the main app via the web.config and included/registered at runtime. If I decided to change the specific IOC container (e.g. from Autofac to Unity), each of these externally built modules would need to change their IOC container too. I definitely don't want to write my own IOC container. The basic idea would be to create a generic interface which allows them to register their types within their assembly. Sorry I'm not being clearer:) – peter.swallow Apr 18 '13 at 09:41
  • Ok, I see now. Maybe [this question](http://stackoverflow.com/questions/1760456/should-i-encapsulate-my-ioc-container) will help, but it looks like the answers focus on resolution rather than registration (like I did). They do mention some existing products that might work for you though. – Patrick Stephansen Apr 18 '13 at 10:31
0

Its a long time since this post, but I have created a project called 'Agnostic IoC' for just such a purpose, this project is designed specifically to solve the problem which you describe and uses an agnostic core api which provide the ability to set up your registrations and then use a nuget package in the final implementation to interpret it.

https://github.com/cardinal252/Agnostic-Ioc

http://cardinalcore.co.uk/agnostic-ioc/getting-started/

Nat
  • 19
  • 3