На чьей ответственности должна быть регистрация типов в контейнере IoC?

Question

Допустим, у меня есть веб-приложение ASP.NET MVC, которое состоит из множества сборок. Вот очень простой пример:

• MyApp.Web
  • веб-приложение
• MyApp.Services
  • содержит интерфейсы и реализации доменных служб, например, IOrderProcessor, DefaultOrderProcessor
• MyApp.DAL
  • содержит интерфейсы и реализации репозиториев, например, IOrderRepository, SqlOrderRepository

Веб-приложение будет инициализировать контейнер IoC во время запуска (например, зарегистрировать контроллеры и т. Д.). Я не уверен, чья ответственность за регистрацию доменных служб и репозиториев.

Теперь я создал статический класс в каждой сборке, каждый из которых содержит метод, отвечающий за регистрацию типов, содержащихся в сборке. Например. для сборки DAL:

namespace MyApp.DAL
{
  public static class AssemblyInitialization
  {
    public static void RegisterTypes(IUnityContainer container)
    {
      var lm = new TransientLifestyleManager();
      container.RegisterType<IOrderRepository, SqlOrderRepository>(lm);
      ...
    }
  }
}

Эти методы затем вызываются веб-приложением во время запуска (в проекте модульного тестирования я, конечно, не смог бы использовать эти методы, но должен был бы зарегистрировать все реализации теста внутри проекта тестирования). 1034 *

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

Поэтому я ищу ваши мнения о том, как это должно быть обработано, например:

• должен ли весь процесс регистрации обрабатываться основным приложением (веб-приложением)?
• или это поставит слишком много знаний о содержимом отдельных (автономных) сборок в основное приложение?
• следует ли абстрагировать конкретный контейнер IoC с помощью собственного интерфейса?
• что еще нужно рассмотреть?

Answer 1

Запустите «начальной загрузки» в вашей точке входа. Однако вы можете делегировать регистрации каждой загруженной сборке, используя класс, реализующий IRegistration в этих сборках.

Это в значительной степени то, что вы делаете сейчас. Но вместо использования статических классов вы можете найти реализации IRegistration через размышление об инициализации.

Поскольку вы используете MVC, взгляните на Turbine, который отлично справляется с этой задачей. Или еще лучше, используйте его в своем приложении:)

Answer 2

Это всегда ответственность точки входа, в этом случае ваш MyApp.Web. Обычно это «входит / вызывается» с вашего glabal.asax.

Answer 3

ИМХО, ваш код должен отложить этот выбор как можно дольше - до последнего ответственного момента. Я использую Unity, поэтому я могу подождать, пока загрузится web.config, чтобы объявить, какие типы я хочу внедрить.

Я считаю, что если вы не используете файл конфигурации для этого, вы делаете что-то не так. Цель использования инфраструктуры DI - уменьшить и / или удалить эти зависимости времени компиляции.