Ioc / DI - Почему я должен ссылаться на все слои / сборки в точке входа приложения?

(В связи с этим вопросом EF4: почему необходимо включить создание прокси, когда включена отложенная загрузка? ).

Я новичок в DI, так что терпите меня. Я понимаю, что контейнер отвечает за создание экземпляров всех моих зарегистрированных типов, но для этого ему требуется ссылка на все библиотеки DLL в моем решении и их ссылки.

Если бы я не использовал контейнер DI, мне бы не пришлось ссылаться на библиотеку EntityFramework в моем приложении MVC3, только на мой бизнес-уровень, который будет ссылаться на мой уровень DAL / Repo.

Я знаю, что в конце дня все библиотеки DLL включены в папку bin, но моя проблема заключается в том, чтобы ссылаться на нее явно через «добавить ссылку» в VS, чтобы иметь возможность опубликовать WAP со всеми необходимыми файлами.

Если бы я не использовал контейнер DI, мне бы не пришлось ссылаться на библиотеку EntityFramework в моем приложении MVC3, только на мой бизнес-уровень, который будет ссылаться на мой уровень DAL / Repo.

Да, это именно та ситуация, которую DI старается избежать :)

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

Поскольку граф зависимостей глубоки, это означает , что большинство библиотек перетащить на много других зависимости - например , на схеме, библиотека С тянется вдоль библиотеки Н, Е, библиотеки библиотеки J, M, Библиотеки Библиотеки K и библиотек N . Это затрудняет повторное использование каждой библиотеки независимо от остальных - например, при модульном тестировании .

Тем не менее, в слабосвязанном приложении, перемещая все ссылки на композиции Root , то граф зависимостей сильно уплощенный :

Как показано зеленым цветом, теперь можно повторно использовать библиотеку C без перетаскивания каких-либо нежелательных зависимостей.

Однако, несмотря на все вышесказанное, для многих контейнеров DI вам не нужно добавлять жесткие ссылки на все необходимые библиотеки. Вместо этого вы можете использовать позднее связывание в форме сканирования сборки на основе соглашений (предпочтительно) или конфигурации XML.

Однако при этом не забудьте скопировать сборки в папку bin приложения, потому что это больше не происходит автоматически. Лично я редко считаю, что это стоит дополнительных усилий.

Более подробную версию этого ответа можно найти в этом отрывке из моей книги « Внедрение зависимостей, принципы, практики, шаблоны» .

Если бы я не использовал контейнер DI, мне бы не пришлось ссылаться на библиотеку EntityFramework в моем приложении MVC3.

Даже при использовании контейнера DI вам не нужно позволять вашему проекту MVC3 ссылаться на EF, но вы (неявно) решите сделать это, реализовав Composition Root (путь запуска, по которому вы составляете свои графы объектов) внутри вашего проекта MVC3. Если вы очень строго относитесь к защите архитектурных границ с помощью сборок, вы можете перенести логику представления в другой проект.

Когда вы перемещаете всю логику, связанную с MVC (контроллеры и т. Д.) Из запускаемого проекта в библиотеку классов, это позволяет этой сборке уровня представления оставаться отключенной от остальной части приложения. Сам проект вашего веб-приложения станет очень тонкой оболочкой с необходимой логикой запуска. Проект веб-приложения будет корнем композиции, который ссылается на все другие сборки.

Извлечение логики представления в библиотеку классов может усложнить работу с MVC. Будет сложнее подключить все, поскольку контроллеры не входят в запускаемый проект (в то время как представления, изображения, файлы css, скорее всего, должны оставаться в запускаемом проекте). Вероятно, это выполнимо, но для настройки потребуется больше времени.

Из-за недостатков я обычно советую просто оставить корневой каталог композиции в веб-проекте. Многие разработчики не хотят, чтобы их сборка MVC зависела от сборки DAL, но это не проблема. Не забывайте, что сборки - это артефакт развертывания ; вы разделяете код на несколько сборок, чтобы можно было развертывать код отдельно. С другой стороны, архитектурный слой - это логический артефакт. Вполне возможно (и часто) иметь несколько слоев в одной сборке.

В этом случае у нас будет корень композиции (слой) и уровень презентации в одном проекте веб-приложения (то есть в одной сборке). И несмотря на то, что сборка ссылок сборки , содержащие DAL, Сретение слой еще не ссылается на Access Data Layer . Это большое различие.

Конечно, когда мы делаем это, мы теряем возможность компилятора проверять это архитектурное правило во время компиляции, но это не должно быть проблемой. Большинство архитектурных правил фактически не могут быть проверены компилятором, и всегда есть что-то вроде здравого смысла. И если в вашей команде нет здравого смысла, вы всегда можете использовать обзоры кода (которые, кстати, должна делать каждая команда, IMO). Вы также можете использовать такой инструмент, как NDepend (который является коммерческим), который поможет вам проверить ваши архитектурные правила. Когда вы интегрируете NDepend в процесс сборки, он может предупреждать вас, когда кто-то проверил код, нарушающий такое архитектурное правило.

Вы можете прочитать более подробное обсуждение того, как работает корень композиции, в главе 4 моей книги « Внедрение зависимостей, принципы, практики, шаблоны» .

Если бы я не использовал контейнер DI, мне бы не пришлось ссылаться на библиотеку EntityFramework в моем приложении MVC3, только на мой бизнес-уровень, который будет ссылаться на мой уровень DAL / Repo.

Вы можете создать отдельный проект под названием «DependencyResolver». В этом проекте вы должны указать все свои библиотеки.

Теперь слой пользовательского интерфейса не требует ссылки на NHibernate / EF или любую другую библиотеку, не относящуюся к пользовательскому интерфейсу, за исключением Castle Windsor.

Если вы хотите скрыть Castle Windsor и DependencyResolver со своего уровня пользовательского интерфейса, вы можете написать HttpModule, который вызывает материал реестра IoC.

У меня есть только пример для StructureMap:

public class DependencyRegistrarModule : IHttpModule
{
    private static bool _dependenciesRegistered;
    private static readonly object Lock = new object();

    public void Init(HttpApplication context)
    {
        context.BeginRequest += (sender, args) => EnsureDependenciesRegistered();
    }

    public void Dispose() { }

    private static void EnsureDependenciesRegistered()
    {
        if (!_dependenciesRegistered)
        {
            lock (Lock)
            {
                if (!_dependenciesRegistered)
                {
                    ObjectFactory.ResetDefaults();

                    // Register all you dependencies here
                    ObjectFactory.Initialize(x => x.AddRegistry(new DependencyRegistry()));

                    new InitiailizeDefaultFactories().Configure();
                    _dependenciesRegistered = true;
                }
            }
        }
    }
}

public class InitiailizeDefaultFactories
{
    public void Configure()
    {
        StructureMapControllerFactory.GetController = type => ObjectFactory.GetInstance(type);
          ...
    }
 }

DefaultControllerFactory не использует контейнер IoC напрямую, но делегирует его методам контейнера IoC.

public class StructureMapControllerFactory : DefaultControllerFactory
{
    public static Func<Type, object> GetController = type =>
    {
        throw new  InvalidOperationException("The dependency callback for the StructureMapControllerFactory is not configured!");
    };

    protected override IController GetControllerInstance(RequestContext requestContext, Type controllerType)
    {
        if (controllerType == null)
        {
            return base.GetControllerInstance(requestContext, controllerType);
        }
        return GetController(controllerType) as Controller;
    }
}

GetControllerДелегат устанавливается в StructureMap реестре (в Виндзоре он должен быть Installer).

• Существует зависимость: если объект создает экземпляр другого объекта.
• Нет зависимости: если объект ожидает абстракцию (внедрение конструктора, внедрение метода ...)
• Ссылки на сборки (ссылки на dll, веб-службы ..) не зависят от концепции зависимости, потому что для разрешения абстракции и возможности компилировать код уровень должен ссылаться на нее.