В каких случаях следует заказывать регистрацию зависимостей?

Question

Я прочитал вопрос Ioc/DI - Why do I have to reference all layers/assemblies in entry application?

Таким образом, в растворе Asp.Net MVC5, корень композиции находится в проекте MVC5 (и имеющий узел, отвечающий за внедрение зависимости всех регистраций не имеет смысла).

Внутри этой картинки мне непонятно, какой лучший подход среди следующих.

Подход 1

Конкретные реализации являются public class ... и все регистрации положения централизованы в пределах корня композиции (например, в одном или более файлов в папке CompositionRoot). Проект MVC5 должен ссылаться на все сборки, обеспечивающие привязку хотя бы одной конкретной реализации. Никакая библиотека не ссылается на библиотеку DI. Проект MVC может содержать интерфейсы, которые должны быть связаны без каких-либо недостатков.

подход 2

Конкретные реализации являются internal class .... Каждая библиотека предоставляет локальный обработчик конфигурации DI. Например,

public class DependencyInjectionConfig { 
    public static void Configure(Container container) { 
     //here registration of assembly-provided implementations 
     //... 
    } 
} 

, который должен зарегистрировать свои собственные реализации. Корень композиции запускает регистрацию, вызывая все методы Configure(), всего по одному для каждого проекта. Проект MVC5 должен затем ссылаться на все сборки, обеспечивающие привязку хотя бы одной конкретной реализации. Библиотеки must ссылка библиотека DI. В этом случае проект MVC5 не может содержать интерфейсы (в противном случае была бы круговая ссылка): для привязки общедоступных интерфейсов потребуется сборка ServiceLayer.

подход 3

То же, что подход 2, но локальные модули конфигурации обнаруживаются динамически с помощью сборки отражения (по соглашению?). Поэтому проект MVC5 не ссылается на библиотеки. Проект MVC может содержать и может ссылаться на библиотеки. Библиотеки must ссылка библиотека DI.

Какова наилучшая практика здесь? Есть ли другая возможность?

* EDIT (2016-12-22) * Благодаря полученным ответам, я опубликовал this github project описывая лучшее решение, которое я нашел до сих пор.

Answer 1

Обычно мне нравится инкапсулировать эти типы вещей в каждый проект. Так, например, у меня может быть следующее. (Это очень упрощенный пример, и я буду использовать AutoFac в этом примере, но я бы предположил, что все рамки DI имеют что-то вроде следующего).

Общая площадь только для POCOs и интерфейсов.

// MyProject.Data.csproj 
namespace MyProject.Data 
{ 
    public Interface IPersonRepository 
    { 
    Person Get(); 
    } 

    public class Person 
    { 
    } 
} 

Внедрение Хранилища и доступа к данным

// MyProject.Data.EF.csproj 
// This project uses EF to implement that data 
namespace MyProject.Data.EF 
{ 
    // internal, because I don't want anyone to actually create this class 
    internal class PersonRepository : IPersonRepository 
    { 
    Person Get() 
    { // implementation } 
    } 

    public class Registration : Autofac.Module 
    { 
    protected override void Load(ContainerBuilder builder) 
    { 
     builder.Register<PersonRepository>() 
     .As<IPersonRepository>() 
     .IntancePerLifetimeScope(); 
    } 
    } 
} 

Потребитель

// MyPrject.Web.UI.csproj 
// This project requires an IPersonRepository 
namespace MyProject.Web.UI 
{ 
    // Asp.Net MVC Example 
    internal class IoCConfig 
    { 
    public static void Start() 
    { 
     var builder = new ContainerBuilder(); 

     var assemblies = BuildManager.GetReferencedAssemblies() 
     .Cast<Assembly>(); 

     builder.RegisterAssemblyModules(assemblies); 
    } 
    } 
} 

Так зависимостями выглядеть следующим образом:

MyProject.Data.csproj 
- None 

MyProject.Data.EF.csproj 
- MyProject.Data 

MyProject.Web.UI.csproj 
- MyProject.Data 
- MyProject.Data.EF 

В этой установке, Web.UI не может знать что-нибудь abo что зарегистрировано и по какой причине. Он знает только, что проект EF имеет реализации, но не может получить к ним доступ.

Я могу отказаться от EF, чтобы сказать Dapper очень легко, поскольку каждый проект инкапсулирует его собственные реализации и регистрации.

Answer 2

Вы обнаружили настоящую проблему. (Можно было бы сказать, что это хорошая проблема есть.) Если приложения ввода A ссылки B, B ссылки C и B и/или C требуют некоторого DI регистрации, что делает A (приложение ввода) ответственность за знание достаточно о деталях B и C для регистрации всех зависимостей.

Решение состоит в том, чтобы иметь отдельную сборку, которая обрабатывает составление всех регистраций для B и C.A указывает, что он содержит всю конфигурацию контейнера, которую A должен использовать B и C.

Преимущества

• A не знает больше, о B и C, чем она должна
• Ни A, B, ни C должны быть привязаны к одной конкретной структуры DI как Unity или Виндзор.

Here's an example. Это класс шины событий, который лучше всего работает с контейнером DI. Но для его использования вам не нужно знать все о зависимостях, необходимых для регистрации. Итак, для Виндзора я создал DomainEventFacility. Вы только что позвонили

_container.AddFacility<DomainEventFacility>(); 

и все зависимости зарегистрированы. Единственное, что вы регистрируете, - это обработчики событий.

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