Недостатки использования двух контейнеров IoC в одном решении в .NET? - PullRequest
0 голосов
/ 22 мая 2018

Я работаю над проектом, который использует набор библиотек от другого разработчика, который использует Structuremap в качестве контейнера IoC.[У меня есть кодовая база со мной]

Приложение, в которое мы встраиваем эти библиотеки, использует контейнер Unity .

Есть ли недостаток в наличии двух контейнерных структур втакое же решение?Я хочу переместить все в тот же контейнер IoC, но как мне оправдать дополнительные усилия?

1 Ответ

0 голосов
/ 24 мая 2018

Существует различие между наличием нескольких библиотек контейнеров в одном и том же решении и одном и том же приложении , поскольку решение может состоять из нескольких работающих приложений.

Все компоненты должны быть подключены по пути запуска приложения, то есть Composition Root :

Composition Root - это (предпочтительно) уникальное место в приложении, где создаются модуливместе.

Вместе с использованием Constructor Injection, шаблон Composition Root сохраняет ваше приложение полностью слабо связанным и сохраняет код приложения отделенным от вашего DI-контейнера.

Согласно шаблону Composition Root, никакие другие части приложения не должны зависеть от DI-контейнера.Тот факт, что библиотеки, которые вы используете, делает проблематичным, потому что это приводит вас к определенному DI-контейнеру.Лучшее решение - сделать библиотеки DI-friendly .

Есть несколько недостатков использования нескольких библиотек контейнеров в одном решении :

  • Вы должны изучить две разные библиотеки DI-контейнера, каждая из которых имеет свои ограничения и причуды
  • Каждая библиотека имеет свой собственный риск необходимости замены после разработки остановки.

Кроме того, есть несколько недостатков использования нескольких библиотек контейнеров в одном приложении :

  • Сложности могутвозникают, когда один объектный граф состоит из компонентов приложения, которые поступают из разных контейнеров.Может быть трудно визуализировать графы объектов и проверить их на правильность.
  • Если какой-либо компонент разрешен из обоих контейнеров, это может привести к Torn Lifestyles

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

Другой распространенный сценарий, когда хорошо иметь два контейнера, это когда вы используете среду приложения.running использует внутренний контейнер DI для создания своих сервисов.Типичными примерами этих платформ являются ASP.NET Core и NServiceBus.В этом случае, чтобы прояснить различие, я обычно говорю о системе фреймворка фреймворка, а не о ее внутреннем контейнере, поскольку это то, чем он в принципе является.Это контейнер, который является подробностью реализации .

. В этом случае вы можете оставить встроенную «систему конфигурации» как есть для разрешения компонентов инфраструктуры ,и использовать выбранный вами DI-контейнер для построения графов объектов из компонентов приложения .

...