Search code examples
dependency-injectionioc-containersimple-injectorbootstrapperonion-architecture

How to create a launcher project for ASP.Net MVC Project

I'm a newbie to IoC and dependency injection and Onion Architecture. I am trying to create my solution architecture according to guidelines and best practices in Onion Architecture community. In my VS Solution, I have some projects for the domain core and some for infrastructure and one ASP.NET MVC for user interface. Now I want to add an IoC container to the solution. I know that the best practice is adding a bootstrapper or launcher project which has references to an IoC Container (Simple Injector in my case) and all the projects in the solution. In this way I can decouple the whole solution from IoC Container and I can easily replace it with others in the future. Now my questions:

  1. What type of project should I create for my launcher (MVC or Class library ...)

  2. How the bootstraper can launch the MVC project?

  3. Should the bootstraper has references to ASP.NET MVC packages?

    Thank you in advance

Solution

  • For most projects, this is the wrong approach.

    You should create a composition root near to the entry point of the application (in an MVC project that would be somewhere in the Application_Start event). It should not be moved into a library of its own because you are not going to reuse it anyway. The composition root is the application's configuration, so you wouldn't move it to a separate project any more than you would move the .config file to a separate project.

    Also, unless you have specific requirements to late-bind DLLs to your AppDomain (for example, uploading a plugin and launching it without restarting the application), the type of architecture really doesn't matter as far as IoC is concerned. Architecture is a logical arrangement of layers, which may or may not result in a physical separation of layers. However, from the composition root's perspective, the application should be a flat set of DLL references that contain loosely-coupled components that are coupled together in the composition root (the only part of the application that should be tightly-coupled together).

    Note this doesn't preclude you from using several classes to organize your DI registration in your composition root - it just means that you should keep that code in the main project, where it can be edited easily.

    Finally, this question gets asked in one form or another quite often on StackOverflow. For those looking for a definitive answer about the benefits of using DI correctly and the drawbacks of using it incorrectly, I recommend reading the book Dependency Injection in .NET. Once you understand what DI is and how it should be used, the architecture part becomes much more clear.