Не понимаю, где создавать контейнеры IoC в системной архитектуре

Скажем, у меня есть следующие 4 сборки .net:

Winforms UI
Бизнес-логика
Доступ к данным SQL Server (реализация IRepository)
Общие интерфейсы (определение IRepository и т.д.)

Моя бизнес-логика (2) выполняет вызовы на уровень доступа к данным (3) через IRepository (определенный в 4), используя инъекцию зависимости конструктора. Однако, когда я завершаю бизнес-объект, мне нужно передать в реальный репозиторий. Я делаю это, если один класс singleton в моем бизнес-логическом слое возвращает используемый в настоящее время конкретный объект, реализующий IRepository. Я прихожу к выводу, что это плохо, поскольку мой уровень бизнес-логики теперь должен ссылаться на 3, а также на 4.

Я думаю, что мне нужен контейнер IoC, но вопрос в том, где я создаю/ставил его, как кажется, где бы я ни создавал этот (1 - UI)? также необходимо будет содержать ссылку на 3 (SQL Server Data Access). Разве я не просто перехожу к проблеме, а не к фактической развязке?

Создать контейнер IoC в пользовательском интерфейсе. Или выставить его через новую сборку.

(Я использую С#,.net 3.5 и AutoFac)

Спасибо.

Ответ 1

Контейнер IoC обычно должен быть создан в проекте хоста (точка входа приложения). Для приложения Windows.Forms проект exe.

Обычно в простых решениях (в рамках 10 проектов) только хост-проект должен иметь ссылку на библиотеку IoC.

PS: Структурирование приложений .NET с помощью Autofac IoC

Ответ 2

При регистрации компонентов существует несколько возможностей:

Регистрация в коде:
- непосредственно
  Проблема: вы должны ссылаться на все (вы здесь)
- косвенно
  Проблема: узнать, что нужно зарегистрировать
  Решение:
  - Использовать атрибуты
  - использовать маркерный интерфейс как IService
  - использовать соглашения (см. StructureMap)
Регистрация с конфигурационным файлом:
- пусть контейнер сделает все
- прочитайте файл самостоятельно

Ответ 3

Верхний уровень - это путь (UI, как сказал Ринат).

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

Ответ 4

Различие модулей и "области", определенные модулями, существуют в основном во время компиляции. Во время выполнения все это один большой беспорядок;) Это используется большинством контейнеров МОК, и они не заботятся о том, где они находятся. Контейнер IoC для веб-приложения обычно создается на самом удаленном уровне (очень близко к самому веб-контейнеру).

Ответ 5

Верно, что вы могли бы создать его в любом месте, но я бы добавил дополнительный слой, позвольте ему назвать его 3.5.

В вашем текущем 3 будет находиться ваш IoC для доступа к данным - это станет оберткой для вашего фактического DAL. Основываясь на вашей конфигурации, 3 создаст либо макет репозитория, либо конкретный.

Итак, 2 все еще ссылаются на 3, но это просто интерфейс к фактическому DAL, который настроен через вашу инфраструктуру IoC.

В качестве альтернативы вы можете перевернуть свой собственный "el-cheapo" IoC - изменить свой большой угрюмый синглтон на статический шлюз - Тестирование контейнера IoC за синглтоном - не так ли?