Комментарии 20
Подскажите, пожалуйста, из какой коробки предоставляется этот механизм? А то я открыл студию, создал новый проект .Net 5, и всё же пришлось ставить нугет. С такими раскладами вроде как нет разницы какой нугет ставить.
Из коробки с надписью ".net" на боку.
Это шутка такая.
Этот DI-контейнер поддерживается командой разработки .net, является механизмом по умолчанию.
А вот на счёт "нет разницы", это не так. DI-контейнеры разные, имеют разный API. Проблемы начинаются, когда приходится использовать библиотеки, не знающие о других di, кроме IServiceCollection.
А для чего библиотекам знать про IServiceCollection, ведь это по сути билдер контейнера? IServiceProvider с другой стороны (если мне не изменяет память) реализуют все контейнеры в той или иной форме.
Есть у меня история про simpleinjector как раз об этом.
Такое поведение было в .net core 2.2, .net core 3.1, другие не использовал, так что утверждать не стану. Доступа к тому коду тоже нет, так что примеров не дам, к сожалению. Да и технические детали уже забылись, история будет о внешнем проявлении.
Был в одной небольшой компании внутренний фреймворк, где использовался simpleinjector. У него и возможностей поболее, и пожестче он был в требованиях. Так что регистрировались все зависимости в контейнере si. Кроме тех, что в startup-классе aspnet-приложения, потому что там-то все на методах расширения service collection построено. И был у simple injector метод расширения, который (вроде бы) копировал все зависимости из контейнера service collection в контейнер simple injector.
То есть si знает обо всех зависимостях, а service collection только о своих.
Коллеги как-то столкнулись с тем, что у них не резолвятся зависимости, относящиеся к их классам при использовании в какой-то сторонней библиотеке. (Уже и подзабылись детали как-то.) Когда это дело поисследовали, оказалось, что зависимости этой библиотеки регистрировались и резолвились ServiceProvider'ом, а вот используемые далее классы лежали в контейнере simpleinjector'а.
Тогда нашли обходное решение и рекомендовали его использовать в таких случаях, а вот как было дальше, увы, не знаю.
Потому что в таких случаях надо не копировать описания из service collection, а заменять основной контейнер зависимостей. Благо, точку расширения для этого в Microsoft предусмотрели. Надеюсь, что именно это "обходное" решение и нашли в итоге.
насколько я знаю, то контейнер simpleinjector реализует IServiceProvider, так что по сути можно было зарегистрировать .AddSingleton<IServiceProvider, Container>()
А вы создавайте не .Net 5 проект, а ASP.NET Core 5 проект. Там из коробки будет.
Если мы внедряем временную зависимость в зависимость с заданной областью, то она превращается в зависимость с заданной областью.
Это отношение симметрично?
Inversion of control(IoC, инверсия управления) и его формой — Dependency Injection (DI, внедрение зависимостей)
Наоборот. IoC — форма DI
Инверсия управления, это один паттернов проектирования, принципов объектного программирования, который имеет несколько способов реализации, в число которых и входит внедрение зависимостей.
Также он может быть реализован через паттерн "Фабрика", через локатор служб.
Так что приведенное мной утверждение про то, что DI является формой IoC - полностью верно.
Любой IoC это DI, но не любой DI это IoC... DI более общее понятие. По крайней мере я так думаю.
DI - это способ инверсии управления насколько я знаю. Инвертировать же управление можно не только внедряя зависимости.
Но каждый имеет право на своё мнение, так что я думаю можно и прекратить дискуссию.
Вы оба ерунду говорите.
Да, DI является реализацией IoC, но это не означает что любое применение DI реализует IoC.
Пример DI без признаков IoC — зависимость, не являющаяся точкой расширения. Например, зависимость от конкретного класса.
Пример IoC без признаков DI — aspx. Фреймворк создаёт и вызывает пользовательский код (признак IoC), но при этом управление зависимостями отсутствует в принципе.
Скажите а можно ли тут добавлять как в Спринге квалифаеры т.е. скажем две разные реализации с разными именами и инджектить в зависимости от того что мне надо разнын реализации?
Из коробки нельзя. Но если заменить контейнер зависимостей на что-нибудь более мощное — то можно.
ирония - Например на Спринг.
У меня риторический вопрос - как имя Яву под боком, можно в 2022 году иметь в передовой версии фреймворка иметь DI настолько незамутненный.
Насколько мне нравится C# как язык, настолько я не понимаю инфраструктуру фреймворков и инструментов вокруг него.
И вроде .Net Core в правильную сторону идет. Но шаг влево/вправо от самого фреймворка и как-то все странно.
Dependency Injection в .NET на почтальонах