Remove Dependency on IoC Container?

Generally speaking, most dependencies can be injected into your class at the time it is created. However, in this particular case, you need a component that must be created on demand at the time of use. In such cases, it is very difficult to completely remove dependency on an IoC container.My approach has always been to create a factory that is injected into the class at creation time, which in turn encapsulates all direct IoC usage.

This allows your factories to be mocked for testing, rather than the IoC container itself...which tends to be a lot easier: In Presentation. Csproj class PresentationController { public PresentationController(IDataContextFactory dataContextFactory, IRepositoryFactory repositoryFactory) { #region . NET 4 Contract Contract.

Requires(dataContextFactory! = null); Contract. Requires(repositoryFactory!

= null); #endregion _dataContextFactory = dataContextFactory; _repositoryFactory = repositoryFactory; } private readonly IDataContextFactory _dataContextFactory; private readonly IRepositoryFactory _repositoryFactory; public void Action() { using (IDataContext dc = _dataContextFactory.CreateInstance()) { var repo = _repositoryFactory. CreateUserRepository(); // do stuff with repo... } } } // In Factories.API. Csproj interface IDataContextFactory { IDataContext CreateInstance(); } interface IRepositoryFactory { IUserRepository CreateUserRepository(); IAddressRepository CreateAddressRepository(); // etc. } // In Factories.Impl.

Csproj class DataContextFactory: IDataContextFactory { public IDataContext CreateInstance() { var context = IoC.Resolve(); // Do any common setup or initialization that may be required on 'context' return context; } } class RepositoryFactory: IRepositoryFactory { public IUserRepository CreateUserRepository() { var repo = IoC.Resolve(); // Do any common setup or initialization that may be required on 'repo' return repo; } public IAddressRepository CreateAddressRepository() { var repo = IoC.Resolve(); // Do any common setup or initialization that may be required on 'repo' return repo; } // etc.} The benefit of this approach is, while you can not completely eliminate the IoC dependency itself, you can encapsulate it in a single kind of object (a factory), decoupling the bulk of your code from the IoC container. This improves your codes agility in light of, say, switching from one IoC container to another (i.e. Windsor to Ninject) It should be noted, an interesting consequence of this, is that your factories are usually injected into their dependents by the same IoC framework they use.

If you are using Castle Windsor, for example, you would create configuration that tells the IoC container to inject the two factories into your business component when it is created. The business component itself may also have a factory...or, it may simply be injected by the same IoC framework into a higher-level component, etc. Etc. , ad inf.

Generally speaking, most dependencies can be injected into your class at the time it is created. However, in this particular case, you need a component that must be created on demand at the time of use. In such cases, it is very difficult to completely remove dependency on an IoC container.My approach has always been to create a factory that is injected into the class at creation time, which in turn encapsulates all direct IoC usage.

This allows your factories to be mocked for testing, rather than the IoC container itself...which tends to be a lot easier: // In Presentation. Csproj class PresentationController { public PresentationController(IDataContextFactory dataContextFactory, IRepositoryFactory repositoryFactory) { #region . NET 4 Contract Contract.

Requires(dataContextFactory! = null); Contract. Requires(repositoryFactory!

= null); #endregion _dataContextFactory = dataContextFactory; _repositoryFactory = repositoryFactory; } private readonly IDataContextFactory _dataContextFactory; private readonly IRepositoryFactory _repositoryFactory; public void Action() { using (IDataContext dc = _dataContextFactory.CreateInstance()) { var repo = _repositoryFactory. CreateUserRepository(); // do stuff with repo... } } } // In Factories.API. Csproj interface IDataContextFactory { IDataContext CreateInstance(); } interface IRepositoryFactory { IUserRepository CreateUserRepository(); IAddressRepository CreateAddressRepository(); // etc. } // In Factories.Impl.

Csproj class DataContextFactory: IDataContextFactory { public IDataContext CreateInstance() { var context = IoC.Resolve(); // Do any common setup or initialization that may be required on 'context' return context; } } class RepositoryFactory: IRepositoryFactory { public IUserRepository CreateUserRepository() { var repo = IoC.Resolve(); // Do any common setup or initialization that may be required on 'repo' return repo; } public IAddressRepository CreateAddressRepository() { var repo = IoC.Resolve(); // Do any common setup or initialization that may be required on 'repo' return repo; } // etc.} The benefit of this approach is, while you can not completely eliminate the IoC dependency itself, you can encapsulate it in a single kind of object (a factory), decoupling the bulk of your code from the IoC container. This improves your codes agility in light of, say, switching from one IoC container to another (i.e. Windsor to Ninject).

It should be noted, an interesting consequence of this, is that your factories are usually injected into their dependents by the same IoC framework they use. If you are using Castle Windsor, for example, you would create configuration that tells the IoC container to inject the two factories into your business component when it is created. The business component itself may also have a factory...or, it may simply be injected by the same IoC framework into a higher-level component, etc.Etc.

, ad inf.

Thanks for the answer. The only problem is that the IoC that I'm using should have a scope, relative to a using statement. Then if I Resolve say IDataContext it will resolve the single instance for that particular scope.

I don't want my controllers etc to be aware of an IoC container, but is there really any way around this? – TheCloudlessSky Jul 1 '10 at 10:54 What I'm wondering is if a Controller should be able to call IoC. Resolve?

If not, who should be making this call? – TheCloudlessSky Jul 1 '10 at 12:01 Could you explain a little more about this scope? What IoC container are you using?

Generally speaking, coupling any of your code to the container framework in any way is a negative kind of coupling...you should avoid that at all costs. In my experience, a scope (or context) is rarely, if ever, required for an IoC container to work. If it does work that way, I would find an alternative container, or find a way to supply that context to the factories that resolve your objects and keep your IoC framework decoupled as much as possible.

– jrista Jul 1 '10 at 16:24 Well actually I'm trying to write my own very simple IoC container. I'm doing it mostly for my own learning. I'm using ASP.NET MVC and so regardless of what IoC container, who makes the call to Resolve.

I understand about using the Factory, but where does the Factory lie? Should it be the only thing in the application that has a reference to the container? – TheCloudlessSky Jul 1 '10 at 16:56 Yes, the factories should be the only things that reference your IoC container.

As to where you put your factories, I guess that is up to you. It ultimately depends on who the primary consumers of those factories are. Some like to include factories in their API's, however I think that creates an undesirable coupling between the API, the Factory, and the implementations the factory creates.

My preference is usually to locate the factories along side the consumers...which in your case, would be your controllers. Put them into their own projects, one with interfaces, the other with implementation – jrista Jul 1 '10 at 17:18.

I was on a project a while ago that hadn't settled on an IoC container. They managed the uncertainty by disallowing non-IoC specific features of their container and also by wrapping Resolve with their own class. This is also something I've seen advocated a few times in blog posts... remove the last dependency, the dependency on the dependency injection container.

This is a workable technique, but at some point you have to choose the tools you use and be willing to accept that you'll pay costs to switch to alternative tools. For me, IoC containers fall into the category of things you probably ought to embrace wholeheartedly, so I question this level of factoring. If you want to look into this further, I suggest the following link: blog.objectmentor.com/articles/2010/01/1....

One alternative is to re-write the method to accept Func delegates. This removes the dependency from the method and allows you to unit test it with a mock: public void Action(Func getDataContext, Func getUserRepository) { using(IDataContext dc = getDataContext()) { IUserRepository repo = getUserRepository(); // Do stuff with repo... } }.

I blogged about this very issue recently: How I use IoC Containers Pulling from the container.

Thanks for the links. So, it again comes down to using a factory. And from what I read, in order to instantiate the factory, you still have to have a reference to the IoC container, correct?

– TheCloudlessSky Jul 1 '10 at 12:19 No you don't need any kind of reference to the container to get the factory, that's the whole point. – Krzysztof Koźmic Jul 1 '10 at 12:57 Ok so the factory has the reference to the container then? Where does the factory live?

I understand how the factory is created, I'm just not sure where to put it. – TheCloudlessSky Jul 1 '10 at 16:03 I notice in your blog post you talk about one call to Resolve. I'm trying to implement my own IoC container (for learning) and was wondering how this can be achieved?

– TheCloudlessSky Jul 1 '10 at 16:10 You also state that you make one Resolve call for the "root" (in my case the MVC Controller), where would it go? – TheCloudlessSky Jul 1 '10 at 16:16.

Have a second dependency injector to inject the first one, and have the first one inject the second one ;-).

You may laugh, but I've seen people advocate this, apparantly in seriousness. – mschaef Jun 30 '10 at 23:14.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.