Pure DI для .NET

Ну Resharper как-то справляется

… вот как раз на то, как Решарпер на таких проектах справляется, я и любуюсь, да.

Уверен, что это не задача библиотек контейнеров.

Вы — уверены. А я вот совершенно не уверен, потому что это вполне себе задача композиции приложения, и зачем мне для нее иметь два инструмента вместо одного?

Ну используйте InternalsVisibleTo

Вы не поняли. Мне надо, чтобы код-потребитель ничего не знал про реализацию. Вообще.

Это как бы не задача контейнера

Да нет, помогать мне решать задачу декомпозиции приложения — это как раз задача контейнера.

Бенчмарки чего? Этого кода?

Нет, реального приложения, которое бы использовало такой DI.

Если вы вызываете много раз Resolve из кода, на мой взгляд это не совсем DI.

А я не говорил про "вызов resolve", я говорил про создание зависимостей. С точки зрения прикладного кода, там просто конструкторы и параметры этих конструкторов. Прикладной код не знает, когда и как создаются те объекты, которые в эти параметры прилетают.

В идеале ваш код не должен знать про инфраструктуру

Я и пишу инфраструктуру. Достаточно сложно самому про себя не знать.

Вариантов как сделать множество. Ведь там все достаточно просто.

Может быть, и просто. Но пока у вас нет поддержки хотя бы сценария использования в ASP.NET Core / Generic Host, это выглядит академическим исследованием, а не прикладным кодом.

И это не потому, что я такой привередливый, а потому что я начинаю очередной реальный проект — ну не знаю там, хочу маленькую AWS Lambda с небольшим количеством компонентов — и мне нужно как минимум логирование и настройки. Я бы с удовольствием оперся на Microsoft.Extensions.Logging и Microsoft.Extensions.Options — но им для нормальной работы нужен Microsoft.Extensions.DependencyInjection. Подтащить его, очевидно, просто, но в этот момент возникает, все-таки, вопрос: что я выиграю от использования вашего (еще не написанного) решения по сравнению с базовой имплементацией в M.E.DI? Там даже скоупы есть — которых у вас, заметим, нет.

Насколько я понял из статьи, это все compile-time зависимости и в runtime они не поедут.

Я, если честно, плохо представляю себе, что это за ситуация, когда вам нельзя third-party runtime зависимости, но можно third-party compile-time зависимости.

Насколько я понял из статьи, это все compile-time зависимости и в runtime они не поедут.

Представьте, что у вас нет контейнеров, а есть просто набор типов в DI стиле. Как вы поступите в этой ситуации?

Ну как-как… как поступили в IdentityServer3? Завернули DI внутрь, выставили наружу интерфейс для конфигурации (если вам надо прокинуть сервис из основного контейнера — добро пожаловать в копипасту). Для предоставления своих сервисов наружу можно сделать сервис-провайдер, что, в общем-то, тоже невесело.

(А потом в IdentityServer4 перешли на conforming container от M.E.DI, и вся эта требуха просто пропала)

Но если рассматривать эту ситуацию как идею для новой фичи, то можно добавить API чтобы Pure DI используя, например, полные имена типов создавал эти объекты этих типов рефлекшеном и лямбда функциями:

Это ровно обратное тому, что мне надо. Мне надо вот так:

.Register<ILogger, MyLogger>() //общее для всего приложения
.RegisterMyComponentServices() //будет использовать логгер из приложения
.Register<IStorageForComponent, MyStorage>() //даем компоненту нашу реализацию его сервиса
.Register<MyController>() //потребляет в конструкторе сервис, предоставляемый компонентом

Ну вот вы пользуетесь библиотекой что бы решить этот вопрос, кто и что ей поставляет?

Я пользуюсь абстракцией (тот самый conforming container). И мое приложение, и используемый им компонент опираются на одну и ту же абстракцию, поэтому могут использовать общий подход к DI. А ваш Pure.DI никакой общей абстракции как раз и не приносит.

Точнее, говоря, вам придется использовать его базовую абстракцию

Уточнение: на самом деле без этого можно обойтись, но кода будет очень много.

Наверно там предполагается что реализация может поменяться при каждом следующем вызове

Ну вообще может, да.

Наверно там предполагается что реализация может поменяться при каждом следующем вызове :)

Да что касается IServiceProvider это так. Наверно там предполагается что реализация может поменяться при каждом следующем вызове

На самом деле, там просто предполагают, что провайдер не обязан поддерживать Func<T>, а стандартный контракт подразумевает, что если вы хотите новый экземпляр — вы его запрашиваете у провайдера. Поэтому ASP.NET Core хочет новый экземпляр контроллера (они per-request) — она запрашивает его у провайдера, потому что это единственный гарантированный контрактом провайдера способ получить новый экземпляр "сервиса".

А для вящего счастья, мы не можем запросить для контроллера Func<T>, потом что тип контроллера не известен в компайл-тайме — мы узнаем его только после роутинга, поэтому резолвить мы будем самым наивным образом, через Resolve(Type).

А ваш контейнер что, позволяет строить реализации Func<T> автоматически? Тогда почему об этом нигде не написано?

Кстати, что будете делать со временем жизни зависимостей?

Кстати о Func<T>.

Как управлять временем жизни с таким подходом?

Вот мы запросили Foo (через Func<Foo>), Foo зависит от Bar, Bar зависит от Baz, Baz реализует IDisposable. Кто вызовет метод Dispose у Baz?

Любой контейнер это зависимость на библиотеку +контейнерый класс.

Если все правильно сделать — только в инфраструктуре (а иногда — и вовсе только в composition root). Это само по себе не проблема.

Я и говорю: когда вы выделяете «значительные изменения», вы игнорируете и мультипарадигменность, и, заодно, TPL.

Потому что немедленно возникает вопрос «когда какие типы использовать».

Ну да, так задумано. Иногда связанный код — это хорошо, потому что он решает конкретную узкую задачу.

Только если все объекты опираются на такой подход. Вы, фактически, получаете фрактал компонуемых объектов, до тех пор пока в самом конце вы не получите тривиальную функцию… и в этот момент, собственно, становится понятно, почему же Симан уходит от DI.