Сравнение конфигураций Dependency Injection фреймворков

[DarkOrion]

Это чувство, когда в статье про IoC-контейнеры нет ни одного xml-конфига.
PS: а можно еще сравнение со Spring вне конкурса? В районе 2011 писал одно приложение сразу на java и шарпе, удивился насколько спринг тогда обгонял unity.

[ETman]

XML умышленно не стал рассматривать, т.к. для этого нужна отдельная статья. В добавок Spring не хочу, т.к. он мне так же не нравится, как и Unity.

[ZOXEXIVO]

XML-это тормоза. Понятно, что это гибко, но уже давно все XML конфиги удалены и забыты.
Зачем вам такая гибкость? Заменить CacheService с обычного на распределенный? Это примерно как с базой данных — ой, мы используем сотни абстракций, репозиториев и.т.п. на случай, если нам нужно будет сменить базу, а на деле это нужно в 0.0001% случаев.
Проще иметь Setup.cs на каждую сборку где статически описаны все зависимости (можно с группировкой) и все эти Setup тоже вызываются из кода без рефлексии и.т.п. Все четко и понятно.

[Razaz]

Это кстати решается через те же автофабрики типа IIndex<Key,Service>. Можно куда угодно настройку вкрутить что бы нужную имплементацию получать.

[DarkOrion]

C такой логикой IoC-контейнер не нужен, да и вообще вынос любых настроек\ресурсов в файл.
Если:
1) Вы готовы ради того, чтобы выводить 11, а не 10 строк на страницу лезть в код и пересобирать ПО;
2) Вам нужно, чтобы приложение запускалось на пару секунд быстрее (на время чтения конфига, ведь на самом деле тормозит не XML, а создание\инициализация объектов);
То да, пишите Setup.cs\Init.cs, создавайте там все объекты руками и руками же собирайте зависимости.

Если вам нужно гибкое приложение — то IoC-контейнер, настройки, конфиги.

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

[Razaz]

В принципе выставлять весь конфиг наружу — плохая идея. Можно выставлять настройки тех компонент, которые можно менять. Остальное нефиг трогать.
Смысл DI в IoC, а не в конфигах всего через Xml.

[areht]

> 1) Вы готовы ради того, чтобы выводить 11, а не 10 строк на страницу лезть в код и пересобирать ПО;

Я для этого IoC то заводить не готов.

[goncharov_a_v]

Если исходить из примеров, а так же из логики что «тот лучше, для правильного использования которого надо читать меньше документации», то Unity лучший из представленных: почти во всех примерах используется один способ регистрации. Далее, способ регистрации и внедрения важны, но есть и еще один, не менее важный, вопрос — управление жизненным циклом объектов, особенно в части IDisposable.

[ETman]

В следующей будет обзор.

[correy]

После «Autofac Качество Супер» читать не стал.

[ETman]

аргументируйте, плиз?

[Razaz]

В принципе сейчас это самый бодрый DI контейнер. Который может работать как от простенького Register -> ConstructorInjection до разных наворотов с владением объектом(Диспоузеры, Owned и тд.), скоупами, автоматическими фабриками, работой с метаданными и любыми другими хотелками. Например EventBus на Autofac+Castle Dynamic Proxy.
Плюс пачка готовых интеграций ко всему чему только можно.

[just_dmitry]

Добавьте пожалуйста к сравнению DI, встроенный в ASP.NET Core.

[djank]

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

[Razaz]

Ему бы на гитхаб, а то даже следить за проектом неудобно.
И вот это немного дико выглядит…
di.Register(Made.Of(() => GetSession(Arg.Of())));
di.WithWebApi(config);