Где разместить модули Ninject в многоуровневом приложении

Для решения с одним приложением общий совет - зарегистрировать контейнер в проекте приложения (веб-приложение или проект веб-службы). Для веб-приложения это обычно Global.asax Application_Start. Это место, где вы соединяете все вместе, в терминологии DI называется корнем композиции.

В решении с несколькими приложениями у вас все равно будет один корень композиции для каждого проекта приложения. Так должно быть, поскольку каждое приложение имеет свою уникальную конфигурацию. С другой стороны, дублированный код - это всегда плохо. Вам не нужно менять три места, когда вы вводите новую абстракцию.

Хитрость заключается в том, чтобы переместить все регистрации вниз по иерархии проекта. Например, вы можете определить одну «сборку начальной загрузки», которая зависит от ваших сборок бизнес-уровня (и ниже), и позволить ей иметь все регистрации для тех сборок, которые не меняются. Затем составные корни приложений могут использовать эту сборку для получения регистраций по умолчанию и расширения ее зависимостей, специфичных для приложения.

Такая вещь может выглядеть так:

// MVC Composition root
public static void Bootstrap()
{
    var container = new Container();

    // Default registrations
    BusinessLayerBootstrapper.Bootstrap(container);

    // Application specific registrations
    container.Bind<IUserContext>().To<AspNetUserContext>();

    DependencyResolver.Current = 
        new ContainerDependencyResolver(container);
}

// Windows Service Composition root
public static void Bootstrap()
{
    var container = new Container();

    // Default registrations
    BusinessLayerBootstrapper.Bootstrap(container);

    // Application specific registrations
    container.Bind<IUserContext>().To<SystemUserContext>()
        .SingleScoped();

    // Store somewhere.
    Bootstrapper.Container = container;
}

// In the BL bootstrap assembly
public static class BusinessLayerBootstrapper
{
    public static void Bootstrap(Container container)
    {
        container.Bind<IDepenency>().To<RealThing>();
        // etc
    }
}

Хотя вам не нужно иметь отдельную сборку загрузчика (вы можете разместить этот код в самом BL), это позволяет сохранить сборки бизнес-уровня свободными от каких-либо зависимостей от вашего контейнера.

Также обратите внимание, что я просто вызываю статический метод Bootstrap() вместо использования модулей (Ninject). Я постарался, чтобы мой ответ не зависел от фреймворка, поскольку ваш вопрос является общим, и совет будет одинаковым для всех фреймворков DI. Однако, конечно, вы можете использовать функцию модуля Ninject, если хотите.

Что касается области видимости, приложение MVC должно иметь другой CompositionRoot, чем служба Windows. Я предлагаю вам попытаться организовать как можно больше по функциональным модулям (для тех частей, которые не зависят от приложения) и всем другим привязкам непосредственно в CompositionRoot проекта MVC или WindowsService.

Еще один очень хороший подход - определить общий набор соглашений, который поможет вам выразить наиболее обязывающие проблемы в нескольких строках. Поэтому ваши приложения могут иметь следующие привязки:

Приложение MVC

Bind(c => c.FromAssemblyContaining<IRepository>()
           .SelectAllClasses()
           .InheritedFrom<IRepository>()
           .Configure(b => b.InRequestScope()));

Ваше приложение-служба Windows

Bind(c => c.FromAssemblyContaining<IRepository>()
           .SelectAllClasses()
           .InheritedFrom<IRepository>()
           .Configure(b => b.InThreadScope()));

С моей точки зрения, в сочетании с функционально-ориентированным структурированием конвенционный подход является наиболее чистым.