Какой инструмент инъекции зависимостей следует использовать?

Приклеивание к одному контейнеру не имеет особого значения, если ваша система была разработана с учетом IoC / DI. При правильном подходе вы можете легко сменить библиотеку IoC по дороге.

И, конечно же, контейнер должен обеспечивать достаточную гибкость для поддержки распространенных широко используемых сценариев (управление жизненным циклом, правильная вложенность контейнеров, конфигурация XML и кода, перехват, быстрое разрешение).

Я бы рекомендовал выбрать между замком (широко используемым и иметь множество интеграционных библиотек) и Autofac (легкий, быстрый и подходящий вложенный контейнер, но не так широко используется)

Существует полный список контейнеров IoC от Hanselman

PS: Вы не хотите использовать Unity

Недавно появилось использование 6 из них ( Windsor , Unity , Spring.Net , Autofac , Ninject , StructureMap ). Я могу предложить краткое резюме каждого, наших критериев отбора и нашего окончательного выбора.

Примечание: мы не смотрели на PicoContainer.Net, так как одна из наших команд считала, что порт .Net будет довольно беден от версии Java. Мы также не смотрели на ObjectBuilder, поскольку Unity построен поверх ObjectBuilder2 и по умолчанию считается превосходным выбором.

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

Требования

• Инъекция на основе конструктора (мы не намерены использовать свойство, поле или метод инъекции)
• Программируемая конфигурация ( не XML)
• иерархии контейнеров (по одному на приложение, для каждого запроса и за сеанс, чтобы более неявно привязывать область жизненных циклов компонентов к контейнеру)
• (для более гранулярного охвата, например, переходного / одиночного)
• инъекции из интерфейса в тип или конкретный экземпляр (например, ILogger -> typeof(FileLogger) или ILogger -> new FileLogger() )
• создание продвинутого компонента / механизм создания «creaton» для предварительной / пост-инициализации
• правильная утилизация IDisposable компонентов при IDisposable контейнера

• хорошо документированная и / или онлайн-информация, доступная

  Примечание: в то время как производительность была требованием, она не учитывалась при выборе, поскольку казалось, что все рассмотренные контейнеры были подобны в соответствии с этим эталоном

Контрольная работа

Каждый контейнер использовался в типичном проекте веб-форм Asp.Net (так как это был наш целевой тип приложения). Мы использовали одну простую страницу с одним простым пользовательским элементом управления, каждый из которых наследуется от базовой страницы / базового элемента управления соответственно. Мы использовали 1 контейнер на BasePage для контейнера с областью «для каждого запроса» и 1 в global.asax для области «приложение» и попытались связать их вместе, чтобы зависимости могли быть разрешены из обоих контейнеров.

Каждое веб-приложение поделилось надуманным набором объектов домена, имитирующих многоуровневую зависимость, тип области (singleton / transient), а также управляемых и неуправляемых classов (требуется IDisposable ). Компоненты зависимостей верхнего уровня были вручную введены из методов на BasePage .

Результаты

Windsor – удовлетворяет всем критериям и имеет хорошую историю болезни, сообщество блоггеров и онлайн-документацию. Прост в использовании и, вероятно, выбор дефакто. Расширенное создание компонентов через заводскую установку. Также допускается объединение отдельных контейнеров.

Spring.Net – подробные и бесполезные документы и не очевидные / простые для программируемой конфигурации. Не поддерживал дженерики. Не выбрано

Ninject – прост в использовании с хорошей четкой документацией. Мощный набор функций, удовлетворяющий всем нашим требованиям, за исключением контейнерных иерархий, поэтому, к сожалению, не был выбран.

StructureMap – плохо документировано, хотя и имеет довольно расширенный набор функций, отвечающий всем нашим требованиям, однако не было встроенного механизма для контейнерных иерархий, хотя его можно было взломать вместе, используя петли, см. Здесь . Свободный интерфейс lambda-выражения выглядел чуть более сначала сперва, хотя можно было инкапсулировать.

Unity – хорошо документирован, прост в использовании и соответствует всем нашим критериям выбора, а также имеет простой механизм расширения, чтобы добавить необходимый нам механизм создания пред / сообщений. Контейнеры для детей должны были быть созданы из родительского контейнера.

Autofac – хорошо документирован и относительно прост в использовании, хотя конфигурация expressии lambda кажется немного сложнее, но, опять же, ее можно легко инкапсулировать. Обнаружение компонентов достигается с помощью механизма «маркировки», и все компоненты сконфигурированы спереди с помощью создателя, который был немного неудобен. Контейнеры для детей были созданы из родительского и назначенных компонентов из «тега». Допустимая общая инъекция.

Вывод

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

Вот хорошая статья, в которой сравниваются контейнеры .NET IoC. http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/

Я начал использовать Autofac год назад и не оглядывался назад.

Я поклонник Autofac, но и Windsor, и Unity сделают хорошую работу (хотя Windsor более способен, чем единство, и не требует приписывания вашего кода). Однако есть много хороших нетехнических причин для прикрепления к одному контейнеру в системе.

Используйте то, что работает. У большинства из них есть уникальные для них функции, и почти все они больше функциональны, чем Unity. Если единство – это все, что вам нужно, вы можете его использовать.

Использование единства Microsoft только потому, что это от Microsoft – плохой способ принять решение. Подумайте о том, что вам нужно и почему, и выберите тот, который вам подходит.

Однако, во-вторых, я понимаю, что, если возможно, придерживайтесь одного контейнера.

Я использовал Managed Extensibility Framework и нашел, что с ним легко работать. Он интегрирован в .NET 4 .

https://stackoverflow.com/questions/71041/which-single-iocdi-container-would-you-recommend-using-and-why

Если у вас уже нет опыта и личного предпочтения для конкретной подтехнологии, используемой одним из возможных контейнеров-контейнеров IoC, все они работают хорошо, и я не вижу никого, в частности, с «функцией убийцы», которая делает его выдающимся от других. Unity, вероятно, лучше всего подходит для решений, уже использующих P & P Enterprise Library 4.x …

IoC Container Benchmark – Сравнение производительности имеет производительность и функции сравнения таблиц для более 20 продуктов и поддерживать их в актуальном состоянии.

Вывод из статьи:

SimpleInjector, Hiro, Funq, Munq и Dynamo предлагают лучшую производительность, они очень быстрые. Попробуйте!

Особенно простой инжектор, кажется, хороший выбор. Это очень быстро, имеет хорошую документацию, а также поддерживает расширенные сценарии, такие как перехват и общие декораторы.