Comments 13
В чем преимущество Autofac от Microsoft.Extensions.DependencyInjection?
Модули, возможность подтянуть типы автоматом через рефлексию, более тонкая настройка резолвов. Но обычно и стандартного хватает.
NeoNN описал просто набор дополнительного сахара, но там есть и вещи, которые невозможны в принципе в стандартном DI, их туда просто еще не завезли.
Например, декораторы, или упомянутые интерцепторы.
Еще там есть очень полезная регистрация по ключу, но в .NET 8 её поспешно добавили, ибо без нее DI был совсем дохленький в плане функционала.
Из "сахара" там есть возможность указания делегата для резолва конкретного аргумента конструктора (или свойства, неважно), в то время как в стандартном DI нужно будет писать new X(sp.resolve, sp.resolve, sp.resolve....).
Короче, Autofac в целом делает жизнь намного проще, если у вас проект не самый простенький.
Я видел слишком много неудачных примеров использования декораторов/интерсепторов на "не самых простеньких проектах", чтобы считать их наличие плюсом. Скорее хорошо, что в стандартном DI контейнере этого нет.
Это как говорить, что молоток плохой, ибо есть люди, которые им по голове бьют)
Да, допустим интерцепторы редко когда нужны, но их наличие ведь не делает библиотеку более плохой, не так ли?
Соглашусь. На самом деле в автофаке самый большой плюс это "настроил и забыл", если все конвенции стандартные, то для микросервисной архитектуры чего-то большего и не надо. Ни интерцепторов, ни декораторов. Если используются сложные концепции - кто-то явно перемудрил.
Так это есть в стандартном: ActivatorUtilities.CreateInstance
А мне одному кажется, что по коду не хватает generic-типов. Видимо везде пропали угловые скобки и их содержимое. Например в самом начале:
// Регистрируем ConsoleLogger как реализацию ILogger
builder.RegisterType().As();Что и вместо чего регистрируется - только из комментария понятно
Я сначала подумал что тут магия какая-то невероятная и впал в шок от настолько неявной привязки)
Но залез в документацию, там:
// Create your builder.
var builder = new ContainerBuilder();
// Usually you're only interested in exposing the type
// via its interface:
builder.RegisterType<SomeType>().As<IService>();
// However, if you want BOTH services (not as common)
// you can say so:
builder.RegisterType<SomeType>().AsSelf().As<IService>();Поэтому да, у автора видимо типы отвалились
В статье мне не понравилось, что она написана как будто десять лет назад, когда в .NET Framework штатных контейнеров сервисов не было, а для использования сторонних контейнеров для внедрения зависимостей в MVC приходилось делать лишние телодвижения (кому интересно - могут найтим книжку А.Фримана по MVC4 - они там подробно описаны).
Но сейчас-то мы живем на десять лет позже, когда в .NET давно есть стандартный контейнер зависимостей, который много где используется, а например ASP.NET Core и Background services без контейнера зависимостей просто работать не могут. И - когда вместо стандартного контейнера вполне можно подключить сторонний, чтобы им пользовались все компоненты .NET котрым этот контейнер нужен.
Вместо этого автор сосредоточился на специфических для Autofac методах, вместо того, чтобы использовать стандартный для любого контейнера IServiceProvider и всю остальную обвязку из Microsoft.Extensions.DependencyInjection - одноообразно которая работает и со встроенным контейнером, и со сторонними. То есть автор показывает примеры работы, специфичные именно для конкретного стороннего контейнера, вместо того, чтобы указать универсальные примеры.
В частности, показывая конфигурирование контейнера сервисов в Startup-классе, автор зачем-то сосредоточился на специфичном для Autofac конфигурировании внутри ConfigureContainer, тогда как все то же самое вполне делается в не зависящем от контейнера и куда более привычном ConfigureServices (это - не говоря о том, что вообще странно в 2024 году приводить примеры настройки ASP.NET Core на устаревшем несколько лет назад шаблоне приложения, где используется Startup-класс.
И с учетом того, что статья рекламирует курсы, возникают нехорошие подозрения и об актуальности этих самых курсов ;-)
Управление зависимостями с Autofac в C#