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

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!

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.