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

Question

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

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

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

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

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

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

Спасибо.

Answer 1

Контейнер

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

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

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

Answer 2

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

1. Регистрация в коде:

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

2. Регистрация с файлом конфигурации:

   • пусть контейнер сделает все
   • прочитайте файл самостоятельно

Answer 3

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

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

Answer 4

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

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

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

В качестве альтернативы, вы можете свернуть свой собственный 'el-cheapo' IoC - заменить свой Big Ugly Singleton на статический шлюз - Абстрагирование контейнера IoC за синглтоном - не так?

Answer 5

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