Where should I do Injection with Ninject 2+ (and how do I arrange my Modules?)

Question

I have a solution with two relevant (to this question) projects, and a few others;

1. Class library with functionality used by several other projects.
2. ASP.NET MVC application.

My question is basically where I should do IoC with Ninject 2, considering...

• The class library needs some DI love, among other things in the repository classes which need web request specific session objects (think Unit of Work).
• The MVC app needs DI since with Ninject 2 you basically inherit from NinjectHttpApplication.
• Unit tests for the class library need to be aware of this to inject a different set of repositories.
• Unit tests for the web app need to be injected for the same reason.

I have painted myself into a mental corner here, because I only saw three options to begin with. DI in the class library, DI in the web app, or both, but there are problems with each:

• I can't do DI only in the class library since the MVC app needs to inherit from NinjectHttpApplication to begin with.
• I can't do DI only in the MVC app - the class library is used by other libraries, after all, and the MVC app shouldn't know too much about the internals of the library anyway.
• I guess this is the only way out I can see: Independent IoC for both projects. The class library and the MVC app each have their own IoC setup and do DI for their stuff without really caring about each other.

Does anyone have some "best practices" or guidelines on how to do something like this? I can't imagine I'm the first person to end up in this situation, and it would sure be nice to know what the "proper" way to do this is...

Thanks!

Midlands

related: #5268025 – Learnt

Duplicate with some comments worth mining for completeness if you're really trying to get a complete insight #5734091 – Learnt

Answer 1

I don't know NInject, but unless it works vastly different than Windsor, StructureMap etc. the answers tend to stay the same, as there are some common DI patterns. With that in mind:

The first thing to realize is that DI isn't tied to a particular framework such as NInject or Windsor. It is a set of techniques and design patterns to follow. You can do DI manually using so-called Poor Man's DI, but obviously it gets much better with a DI Container.

Why is this relevant? It is relevant because once you realize this, the corollary is that the vast majority of your application's code should have no knowledge of the DI Container whatsover.

So where do you use the DI Container? It should only be used in a Composition Root, which in your case would correspond to Global.asax. You can read a bit more about this in this SO answer - although that question is about Windsor, the principle remains the same.

How about your unit tests then? They should be completely ignorant of the DI Container as well. See this other SO answer for more details.

DI can be achieved in your library with copious use of Constructor Injection. You don't need to reference any DI Container to do that, but it makes life a lot easier if you use a DI Container to resolve all dependencies from the Composition Root.

Devastation

Hi Mark - thanks for the answer, I think I get it now, at least most of it. However, if the MVC / Global.asax is responsible for setting up all DI, will it need to poke into the class library stuff as well? Consider that the class library might need to store a per web-request ISession or something like that, which will be used to construct all repository classes. Should the MVC app know about this? Just trying to wrap my head around "The Right Thing" to do. :) – Midlands

Since you are using MVC your best option is to use a custom ControllerFactory to create the Controllers with all their dependencies. You can see an example of this with Windsor in the MvcContrib source code: github.com/mvccontrib/MvcContrib/blob/… If some of the dependencies are types in your library, these should be imported by the Controller. If you need to pass ISession instances to your library, you can use the Controller's ctx to do that - it will already be set up by your custom Factory. – Devastation

Thanks again, Mark. I'll have to try it out - nothing beats actually doing stuff, I guess. Ninject is module based so it is possible I can create a separate module in my class library that is automatically used by the IoC setup in the MVC app as well, I'll just have to try it out. Mucho gracias! – Midlands

I'm currently working with a home-grown version of a dependency resolver and want to switch to one of the popular frameworks. My current method has all concrete classes in my business assembly marked as internal. To keep the DI Container in the Global.asax I would have to expose my concrete classes so they can get resolved, correct? Is there another way to keep the DI container in the composition root while hiding (or at least preventing the instantiation of) my concrete classes directly? P.S. I tried posting this on your blog but got an error. – Disapprove

Yes, you'll need to make the classes public. That's appropriate in any case, since the underlying purpose of DI is loose coupling, and thus maintainability. This means that you'd want well-designed classes to stay maintainable, and if you have that, there's no reason to hide them away. In any case, interfaces act as a level of insulation as well: blog.ploeh.dk/2011/02/28/InterfacesAreAccessModifiers.aspx – Devastation

" the corrolary is that the vast majority of your application's code should have no knowledge of the DI Container whatsover." +1. – Lepidote