Как стать автором
Обновить

Комментарии 15

Это чувство, когда в статье про IoC-контейнеры нет ни одного xml-конфига.
PS: а можно еще сравнение со Spring вне конкурса? В районе 2011 писал одно приложение сразу на java и шарпе, удивился насколько спринг тогда обгонял unity.
XML умышленно не стал рассматривать, т.к. для этого нужна отдельная статья. В добавок Spring не хочу, т.к. он мне так же не нравится, как и Unity.
XML-это тормоза. Понятно, что это гибко, но уже давно все XML конфиги удалены и забыты.
Зачем вам такая гибкость? Заменить CacheService с обычного на распределенный? Это примерно как с базой данных — ой, мы используем сотни абстракций, репозиториев и.т.п. на случай, если нам нужно будет сменить базу, а на деле это нужно в 0.0001% случаев.
Проще иметь Setup.cs на каждую сборку где статически описаны все зависимости (можно с группировкой) и все эти Setup тоже вызываются из кода без рефлексии и.т.п. Все четко и понятно.
Это кстати решается через те же автофабрики типа IIndex<Key,Service>. Можно куда угодно настройку вкрутить что бы нужную имплементацию получать.
C такой логикой IoC-контейнер не нужен, да и вообще вынос любых настроек\ресурсов в файл.
Если:
1) Вы готовы ради того, чтобы выводить 11, а не 10 строк на страницу лезть в код и пересобирать ПО;
2) Вам нужно, чтобы приложение запускалось на пару секунд быстрее (на время чтения конфига, ведь на самом деле тормозит не XML, а создание\инициализация объектов);
То да, пишите Setup.cs\Init.cs, создавайте там все объекты руками и руками же собирайте зависимости.

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

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

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

Я для этого IoC то заводить не готов.
Если исходить из примеров, а так же из логики что «тот лучше, для правильного использования которого надо читать меньше документации», то Unity лучший из представленных: почти во всех примерах используется один способ регистрации. Далее, способ регистрации и внедрения важны, но есть и еще один, не менее важный, вопрос — управление жизненным циклом объектов, особенно в части IDisposable.
В следующей будет обзор.
После «Autofac Качество Супер» читать не стал.
аргументируйте, плиз?
В принципе сейчас это самый бодрый DI контейнер. Который может работать как от простенького Register -> ConstructorInjection до разных наворотов с владением объектом(Диспоузеры, Owned и тд.), скоупами, автоматическими фабриками, работой с метаданными и любыми другими хотелками. Например EventBus на Autofac+Castle Dynamic Proxy.
Плюс пачка готовых интеграций ко всему чему только можно.
Добавьте пожалуйста к сравнению DI, встроенный в ASP.NET Core.
Посмотрите ещё в сторону DryIoc — лидера по производительности в обзоре, на который вы дали ссылку. Приличная документация, качественный код, покрытый тестами, автор (белорус, насколько я понял) поддерживает проект уже довольно долгое время и оперативно реагирует на баг-репорты, поставка в виде дллэлки или файлом в проект. В моём проекте эта библиотека помогла тем, что смогла «решить» довольно запутанный граф зависимостей с generics и множественными конструкторами (конечно, это промах в архитектуре, но всё же). Короче, маст, как говорится, хэв.
Ему бы на гитхаб, а то даже следить за проектом неудобно.
И вот это немного дико выглядит…
di.Register(Made.Of(() => GetSession(Arg.Of())));
di.WithWebApi(config);
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.