0
\$\begingroup\$

In my presentation layer I use an MVC pattern with DI to achieve thin controllers like so:

public class HomeController : Controller
{
    private IHomeService _service;

    public HomeController(IHomeService service)
        : base()
    {
        _service = service;
    }

    public override ActionResult Index()
    {
        HomeIndexViewModel viewModel = new HomeIndexViewModel();
        viewModel.NewsArticles = _service.GetLatestNewsArticles();
        return View(viewModel);
    }
}

I'm using Ninject thus I've configured Ninject within the presentation layer like so:

public class NinjectConfig
{
    public static IKernel CreateKernel()
    {
        StandardKernel kernel = new StandardKernel();

        kernel.Bind<IHomeService>().To<HomeService>();
        kernel.Bind<ISearchService>().To<SearchService>();

        return kernel;
    }
}

I'm a bit confused as to whether I should be configuring Ninject in the presentation layer, or whether this should be done in the application layer.

I'm also wondering whether it is acceptable to have multiple Ninject configurations in multiple layers, such as a configuration in the application layer and another in the business layer.

\$\endgroup\$
1
\$\begingroup\$

Actually, in this case you are not configuring ninject in presentation layer, as the presentation layer in case of MVC is cshtml files.

DI engines (like ninject) should be generally configured in the start-up part of application, not in any specific layer. DI has nothing to do with logical decomposition of your application into layers. DI engines only role is to automatically 'distribute' dependencies to objects, usually by interfaces. In case your application is modular and modules shouldn't see each other, than yes - in this case you probably need per-module DI set-up.

Coming back to ASP.NET MVC, in this case the initial object that are created are controllers and you need to provide implementations for it's dependencies (like you did in the code piece). Now if these dependencies - for exampl HomeService, have their own dependencies, these would need to be registered in the same ninject DI contaier right? So as you see, DI spawns across whole MVC application layers.

\$\endgroup\$
  • \$\begingroup\$ The way I see it is with the pattern I'm using the MVC in the presentation layer consists of view models, views and controllers, all of which make up the presentation layer. There are other models in other layers, such as the entities which are in the business layer. But what I take from what you have said is it is acceptable to configure DI in the layers where the configuration is required. With the additional information do you agree or does this change your view? \$\endgroup\$ – Professor of programming Jun 17 '15 at 12:04
  • \$\begingroup\$ I would generally repeat my previous statement: DI is somehow orthogonal to logical decomposition of your application. I would say that in a static, non-modular applications you usually have a single point of DI configuration. In console application that would be, probably Main(), in winforms / wpf it would be main Application class startup event (for example) and in ASP.NET it is either direct call in App_Start() or with use of automatic registration on start (I think that is in ninject for asp.net nuget package nowadays). \$\endgroup\$ – Łukasz Zwierko Jun 17 '15 at 12:19
  • \$\begingroup\$ Based on what you have said, I will move the ninject code other than the config to the infrastructure layer, I will leave the ninject config where it is as it sounds like it is already in the correct place, which leaves me thinking I'll need to implement a static global dictionary of interfaces to types which can then be used to configure Ninject when App_Start is invoked. \$\endgroup\$ – Professor of programming Jun 17 '15 at 13:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.