Почему в Simple Injector нет такой абстракции IContainer, как Unity?

Simple Injector не содержит абстракции IContainer, потому что:

• Для Simple Injector было бы бесполезно определять его, потому что в случае зависимости от IContainer вместо Container ваш код в этом случае по-прежнему будет зависеть от Simple Injector, и это приведет к блокировке поставщика, который Simple Injector пытается предотвратить.

• Любой код, который вы пишете, за исключением корня композиции приложения, не должен зависеть от контейнера или абстракции над контейнер. Оба являются реализациями анти-шаблона Service Locator.

• Вы НЕ должны использовать библиотеку DI при модульном тестировании. При модульном тестировании вы должны вручную внедрить все поддельные или фиктивные объекты в тестируемый класс. Использование контейнера только усложняет ситуацию. Возможно, вы используете контейнер, потому что создание этих классов вручную для вас слишком громоздко. Это может указывать на проблемы с вашим кодом (возможно, вы нарушаете принцип единой ответственности) или ваши тесты. (возможно, вам не хватает фабричного метода для создания тестируемого класса ).

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

• Самостоятельно определить такой интерфейс (плюс адаптер) - тривиальная задача, что оправдывает отсутствие его в библиотеке. Ваша задача как разработчика приложения - определить правильные абстракции для вашего приложения в соответствии с Принципом инверсии зависимостей . Библиотеки и фреймворки, которые имеют тенденцию делать это, в большинстве случаев не могут предоставить абстракцию, которая работает для всех.

• Сама библиотека не использует эту абстракцию, и библиотека должна, согласно Рекомендации по проектированию каркаса, в этом случае не определять такую ​​абстракцию за вас. Как указывалось в предыдущем пункте, Simple Injector все равно ошибается с абстракцией.

• И последнее, но не менее важное: контейнер Simple Injector на самом деле реализует System.IServiceProvider, который определен в mscorlib.dll и может использоваться для получения служебных объектов.

Я думаю, что приведенный здесь ответ полностью основан на признании того, что ServiceLocator является анти-шаблоном, который, в свою очередь, я не считаю, что это глобально признано истинным. См. Раздел «Поддержка расширений Windows Workflow Foundation».

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

В общем, если вы хотите следовать шаблону Locator, либо используйте его IServiceProvider, либо упростите заполнение контейнера (до синглтона) и создайте для него статическую оболочку.