Pure DI для .NET

    Для того чтобы следовать принципам ООП и SOLID часто используют библиотеки внедрения зависимостей. Этих библиотек много, и всех их объединяет набор общих функции:

    • API для определения графа зависимостей

    • композиция объектов

    • управление жизненным циклом объектов

    Мне было интересно разобраться как это работает, а лучший способ сделать это - написать свою библиотеку внедрения зависимостей IoC.Container. Она позволяет делать сложные вещи простыми способами: неплохо работает с общими типами - другие так не могут, позволяет создавать код, без зависимостей на инфраструктуру и обеспечивает хорошую производительность, по сравнению с другими похожими решениям, но НЕ по сравнению с чистым DI подходом.

    Используя классические библиотеки внедрения зависимостей, мы получаем простоту определения графа зависимостей и теряем в производительности. Это заставляет нас искать компромиссы. Так, в случае, когда нужно работать с большим количеством объектов, использование библиотеки внедрения зависимостей может замедлить выполнение приложения. Одним из компромиссов здесь будет отказ от использования библиотек в этой части кода, и создание объектов по старинке. На этом закончится заранее определенный и предсказуемый граф, а каждый такой особый случай увеличит общую сложность кода. Помимо влияния на производительность, классические библиотеки могут быть источником проблем времени выполнения из-за их некорректной настройки.

    В чистом DI композиция объектов выполняется вручную: обычно это большое количество конструкторов, аргументами которых являются другие конструкторы и так далее. Дополнительных накладных расходов нет. Проверка корректности композиции выполняется компилятором. Управление временем жизни объектов или любые другие вопросы решаются по мере их возникновения способами, эффективными для конкретной ситуации или более предпочтительными для автора кода. По мере увеличения количества новых классов или с каждой новой зависимостью сложность кода для композиции объектов возрастает все быстрее и быстрее. В какой-то момент можно потерять контроль над этой сложностью, что в последствии сильно замедлит дальнейшую разработку и приведет к ошибкам. Поэтому, по моему опыту, чистый DI применим пока объем кода не велик.

    Что если оставить только лучшее от этих подходов:

    • определять граф зависимостей используя простой API

    • эффективная композиция объектов как при чистом DI

    • решение проблем и "нестыковок" на этапе компиляции

    На мой взгляд, эти задачи мог бы на себя взять язык программирования. Но пока большинство языков программирования заняты копированием синтаксического сахара друг у друга, предлагается следующее не идеальное решение - использование генератора кода. Входными данными для него будут .NET типы, ориентированные на внедрение зависимостей и метаданные/API описания графа зависимостей. А результатом работы будет автоматически созданный код для композиции объектов, который проверяется и оптимизируется компилятором и JIT.

    Итак, представляю вам бета-версию библиотеки Pure.DI! Цель этой статьи - собрать фидбек, идеи как сделать ее лучше. На данный момент библиотека состоит из двух NuGet пакетов beta версии, с которыми уже можно поиграться:

    • первый пакет Pure.DI.Contracts это API чтобы дать инструкции генератору кода как строить граф зависимостей

    • и генератор кода Pure.DI

    Пакет Pure.DI.Contracts не содержит выполняемого кода, его можно использовать в проектах .NET Framework начиная с версии 3.5, для всех версий .NET Standard и .NET Core и, кончено, же для проектов .NET 5 и 6, в будущем можно добавить поддержку и .NET Framework 2, если это будет актуально. Все типы и методы этого пакета это API, и нужны исключительно для того, чтобы описать граф зависимостей, используя обычный синтаксис языка C#. Основная часть этого API был позаимствована у IoC.Container.

    .NET 5 source code generator и Roslyn стали основой для генератора кода из пакета Pure.DI. Анализ метаданных и генерация происходит на лету каждый раз когда вы редактируете свой код в IDE или автоматически, когда запускаете компиляцию своих проектов или решений. Генерируемый код не “отсвечивается” рядом с обычным кодом и не попадает в системы контроля версий. Пример ниже показывает, как это работает.

    Возьмем некую абстракцию, которая описывает коробку с произвольным содержимым, и кота с двумя состояниями “жив” или “мертв”:

    interface IBox<out T> { T Content { get; } }
    
    interface ICat { State State { get; } }
    
    enum State { Alive, Dead }

    Реализация этой абстракции для “кота Шрёдингера” может быть такой:

    class CardboardBox<T> : IBox<T>
    {
        public CardboardBox(T content) => Content = content;
    
        public T Content { get; }
    }
    
    class ShroedingersCat : ICat
    {
      // Суперпозиция состояний
      private readonly Lazy<State> _superposition;
    
      public ShroedingersCat(Lazy<State> superposition) =>
        _superposition = superposition;
    
      // Наблюдатель проверяет кота 
      // и в этот момент у кота появляется состояние
      public State State => _superposition.Value;
    
      public override string ToString() => $"{State} cat";
    }
    

    Это код предметной области, который не зависит от инфраструктурного кода. Он написан по технологии DI, а в идеале SOLID.

    Композиция объектов создается в модуле с инфраструктурным кодом, который отвечает за хостинг приложения, поближе к точке входа. В этот модуль и необходимо добавить ссылки на пакеты Pure.DI.Contracts и Pure.DI. И в нём же следует оставить генератору кода “подсказки” как строить граф зависимостей:

    static partial class Glue
    {
      // Моделирует случайное субатомное событие,
      // которое может произойти, а может и не произойти
      private static readonly Random Indeterminacy = new();
    
      static Glue()
      {
        DI.Setup()
          // Квантовая суперпозиция двух состояний
          .Bind<State>().To(_ => (State)Indeterminacy.Next(2))
          // Абстрактный кот будет котом Шрёдингера
          .Bind<ICat>().To<ShroedingersCat>()
          // Коробкой будет обычная картонная коробка
          .Bind<IBox<TT>>().To<CardboardBox<TT>>()
          // А корнем композиции тип в котором находится точка входа
          // в консольное приложение
          .Bind<Program>().As(Singleton).To<Program>();
      }
    }
    

    Первый вызов статического метода Setup() класса DI начинает цепочку “подсказок”. Если он находится в static partial классе, то весь сгенерированный код станет частью этого класса, иначе будет создан новый статический класс с постфиксом “DI”. Метод Setup() имеет необязательный параметр типа string чтобы переопределить имя класса для генерации на свое. В примере в настройке использована переменная “Indeterminacy”, поэтому класс Glue является static partial, чтобы сгенерированный код мог ссылаться на эту переменную из сгенерированной части класса.

    Следующие за Setup() пары методов Bind<>() и To<>() определяют привязки типов зависимостей к их реализациям, например в:

    .Bind().To()

    ICat - это тип зависимости, им может быть интерфейс, абстрактный класс и любой другой не статический .NET тип. ShroedingersCat - это реализация, ей может быть любой не абстрактный не статический .NET тип. По моему мнению, типами зависимостей лучше делать интерфейсы, так как они имеют ряд преимуществ по сравнению с абстрактными классами. Одна из них - это возможность реализовать одним классом сразу несколько интерфейсов, а потом использовать его для нескольких типов зависимостей. И так, в Bind<>() мы определяем тип зависимости, а в To<>() его реализацию. Между этими методами могут быть и другие методы для управления привязкой:

    • дополнительные методы Bind<>(), если нужно привязать более одного типа зависимости к одной и той же реализации

    • метод As(Lifetime) для определения времени жизни объекта, их может быть много в цепочке, но учитывается последний

    • и метод Tag(object), который принимает тег привязки, их может быть несколько на одну привязку, и учитываются все

    На данный момент существует несколько времен жизни, а их список будет пополняться:

    • Transient - значение по умолчанию, когда объект типа будет создаваться каждый раз

    • Singleton - будет создан единственный объект типа, в отличие от классических контейнеров здесь это будет статическое поле статического класса

    • PerThread - будет создано по одному объекту типа на поток

    • PerResolve - в процессе одной композиции объект типа будет переиспользован

    • Binding - позволяет использовать свою реализацию интерфейса ILifetime в качестве времени жизни

    Тег используется в случае, когда один и тот же тип зависимости имеет несколько реализаций, и все они необходимы для внедрения. Например, можно добавить еще одного кота и даже с несколькими тегами:

    .Bind().Tag(“Fat”).Tag(“Fluffy”).To()

    Обратите внимание, что методы Bind<>() и To<>() - это универсальные методы. Каждый содержит один параметр типа для определения типа зависимости, и ее реализации соответственно. Вместо неудобных открытых типов, как например, typeof(IBox<>) в API применяются маркеры универсальных типов, как “TT”. В нашем случае абстрактная коробка - это IBox<TT>, а ее картонная реализация это CardboardBox<TT>. Почему открытые типы менее удобны? Потому что по открытым типа невозможно однозначно определить требуемую для внедрения реализацию, в случае когда параметры универсальных типов это другие универсальные типы. Помимо обычных маркеров TT, TT1, TT2 и т.д. в API можно использовать маркеры типов с ограничениями. Их достаточно много в наборе готовых маркеров. Если нужен свой маркер c ограничениями, создайте свой тип и добавьте атрибут [GenericTypeArgument] и он станет маркером универсального типа, например:

    [GenericTypeArgument]
    public class TTMy: IMyInterface { }

    Метод To<>() завершает определение привязки. В общем случае реализация будет создаваться автоматически. Будет найден конструктор, пригодный для внедрения “через конструктор” с максимальным количеством параметров. При его выборе предпочтения будут отданы конструкторам без атрибута [Obsolete]. Иногда нужно переопределить то, как будет создаваться объект или, предположим, вызвать дополнительно еще какой-то метод инициализации. Для этого можно использовать другую перегрузку метода To<>(factory). Например, чтобы создать картонную коробку самостоятельно, привязка

    .Bind<IBox>().To<CardboardBox>()

    может быть заменена на

    .Bind<IBox>().To(ctx => new CardboardBox(ctx.Resolve()))

    To<>(factory) принимает аргументом lambda функцию, которая создает объект. А единственный аргумент lambda функции, здесь это - ctx, помогает внедрить зависимости самостоятельно. Генератор в последствии заменит вызов ctx.Resolve() на создание объекта типа TT на месте для лучшей производительности. Помимо метода Resolve() возможно использовать другой метод с таким же названием, но с одним дополнительным параметром - тегом типа object.

    Время открывать коробки!

    class Program
    {
      // Создаем граф объектов в точке входа
      public static void Main() => Glue.Resolve<Program>().Run();
    
      private readonly IBox<ICat> _box;
    
      internal Program(IBox<ICat> box) => _box = box;
    
      private void Run() => Console.WriteLine(_box);
    }

    В точке входа void Main() вызывается метод Glue.Resolve<Program>() для создания всей композиции объектов. Этот пример соответствует шаблону Composition Root, когда есть единственное такое место, очень близкое к точке входа в приложение, где выполняется композиция объектов, граф объектов четко определен, а типы предметной области не связаны с инфраструктурой. В идеальном случае метод Resolve<>() должен использоваться один раз в приложении для создания сразу всей композиции объектов:

    static class ProgramSingleton
    {
      static readonly Program Shared = 
        new Program(
          new CardboardBox<ICat>(
            new ShroedingersCat(
              new Lazy<State>(
                new Func<State>(
                  (State)Indeterminacy.Next(2))))));
    }

    Вследствии того, что привязка для Program определена со временем жизни Singleton то метод Resolve<>() для типа Program каждый раз будет возвращать единственный объект этого типа. О многопоточности и ленивой инициализации не стоит беспокоится, так как этот объект будет создан гарантированно один раз и только при первой загрузке типа в момент первого обращения к статическому полю Shared класса статического приватного класса ProgramSingleton, вложенного в класс Glue.

    Есть еще несколько интересных вопросов, которые хотелось бы обсудить. Обратите внимание, что конструктор кота Шрёдингера

    ShroedingersCat(Lazy<State> superposition)

    требует внедрения зависимости типа Lazy<> из стандартной библиотеки классов .NET. Как же это работает, когда в примере не определена привязка для Lazy<>? Дело в том, что пакет Pure.DI из коробки содержит набор привязок BCL типов таких как Lazy<>, Task<>, Tuple<..>, типы кортежей и другие. Конечно же, любую привязку можно переопределить при необходимости. Метод DependsOn(), с именем набора в качестве аргумента, позволяет использовать свои наборы привязок.

    Другой важный вопрос, какую зависимость нужно внедрить чтобы иметь возможность создавать множество объектов определенного типа и делать это в некоторый момент времени? Все просто - Func<>, как и другие BCL типы поддерживается из коробки. Например, если вместо ICat, тип-потребитель запросит зависимость Func<ICat>, то станет возможным получить столько котов сколько и когда нужно.

    Еще одна задача. Есть несколько реализаций с разными тегами, требуется получить все их. Чтобы получить всех котов, требуемую для внедрения зависимость можно определить как IEnumerable<ICat>, ICat[] или другой интерфейс коллекций из библиотеки классов .NET, например IReadOnlyCollection<T>. Конечно же, для IEnumerable<ICat> коты будут создаваться лениво.

    Для простого примера, как кот Шрёдингера, такого API будет вполне достаточно. Для других случаев помогут привязки To<>(factory) c lambda функцией в аргументе, где объект можно создать вручную, хотя они не всегда удобны.

    Рассмотрим ситуацию, когда есть множество реализаций для внедряемой зависимости, тип-потребитель имеет предпочтения по реализациям и мы хотим использовать автоматические привязки. В API есть все необходимое. Каждая реализация отмечается уникальным тегом в привязке, а внедряемая зависимость, например в параметре конструктора, отмечена атрибутом TagAttribute:

    • привязка: .Bind<ICat>().Tag(“Fat”).Tag(“Fluffy”).To<FatCat>()

    • и конструктор потребителя: BigBox([Tag(“Fat”)] T content) { }

    Помимо TagAttribute есть другие предопределенные атрибуты:

    • TypeAttribute - когда нужно обозначить тип внедряемой зависимости вручную, не полагаясь, на тип параметра конструктора, метода, свойства или поля

    • OrderAttribute - для методов, свойств и полей указывается порядок вызова/инициализации

    • OrderAttribute - для конструкторов указывается на сколько один предпочтительнее других

    Но, если использовать любой из этих предопределенных атрибутов в типах предметной области, то модуль предметной области будет зависеть от модуля Pure.DI.Contracts. Это может быть не очень большой проблемой, но все же рекомендуется использовать свои аналоги атрибутов, определенных в модуле предметной области, чтобы не добавлять лишних зависимостей и держать код в чистоте. Для этой цели есть три метода, оставляющие подсказки генератору кода о том какие атрибуты использовать в дополнение к предопределенным:

    • TypeAttribute<>()

    • TagAttribute<>()

    • OrderAttribute<>()

    В качестве параметра типа они принимают тип атрибута, а в качестве единственного необязательного параметра - позицию аргумента в конструкторе атрибута откуда брать значение: типа, тега или порядка, соответственно. По умолчанию позиция аргумента равна 0, следовательно, значения будут взяты из первого аргумента конструктора. Позицию следует переопределять, например, когда вы добавили свой атрибут, такой как “InjectAttribute”, и его конструктор содержит и тег, и тип одновременно.

    Теперь немного о генераторе и генерируемом коде. Генератор кода, используя синтаксические деревья и семантические модели Roslyn API, отслеживает изменения исходного кода в IDE на лету, строит граф зависимостей и генерирует эффективный код для композиции объектов. При анализе выявляются ошибки или недочеты и компилятор получает соответствующие уведомления. Например, при обнаружении циклической зависимости появится ошибка в IDE или в терминале командной строки при сборке проекта, которая не позволит компилировать код, пока она не будет устранена. Будет указано предположительное место проблемы. В другой ситуации, например, когда генератор не сможет найти требуемую зависимость, он выдаст ошибку компиляции с описанием проблемы. В этом случае необходимо либо добавить привязку для требуемой зависимости, либо переопределить fallback стратегию: привязать интерфейс IFallback к своей реализации. Её метод Resolve<>() вызывается каждый раз когда не удается найти зависимость и: возвращает созданный объект для внедрения, бросает исключение или возвращает значение null для того чтобы оставить поведение по умолчанию. Когда fallback стратегия будет привязана генератор изменит ошибку на предупреждение, полагая что ситуация под вашим контролем, и код станет компилируемым.

    Надеюсь, это библиотека будет полезной. Любые ваши замечания и идеи очень приветствуются.

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

      0
      *Режим пассивной агрессии*
      Может стоит вместо увеличения мощи DI, стоит уменьшать сложность внедняемых сервисов?
        0
        Не совсем понятна мысль про сложность сервисов и мощи DI? Если будет больше деталей, обсудим :)
          +6
          Под «мощью» DI я имел ввиду количество фич. Под сложностью, в этом конкретном случае, имелась ввиду сложность конструирования. Композиция, дженерики, иньекции не только в конструктор итд.

          Программирование это не только поиск и применение «клевых» решений, попытки попасть в практичность продукта, но и работа со сложностью в общем ее смысле. Если за ней не следить, то потом никто не сможет понять проект (и назовет его легаси, который невозможно поддерживать). Работать стоит надо не над «мощью» инструментов, а над уменьшения сложности кода. Это экономит на разработку «мощных» инструментов.

          Идеальный код — тот который не написан.
            +1
            Под «мощью» DI я имел ввиду количество фич. Под сложностью, в этом конкретном случае, имелась ввиду сложность конструирования. Композиция, дженерики, иньекции не только в конструктор итд.

            На мой взгляд в реальном приложении все бывает гораздо сложнее, чем можно вообразить: пятиэтажные дженерики, внедрения куда попало, например, чтобы избавиться от циклических зависимостей и другие странные вещи. Не все же люди гении и сразу пишут простой код “тот который не написан”.
            Программирование это не только поиск и применение «клевых» решений, попытки попасть в практичность продукта, но и работа со сложностью в общем ее смысле. Если за ней не следить, то потом никто не сможет понять проект (и назовет его легаси, который невозможно поддерживать). Работать стоит надо не над «мощью» инструментов, а над уменьшения сложности кода. Это экономит на разработку «мощных» инструментов.

            Идеальный код — тот который не написан.

            Я с вами согласен. Я думаю, что кодинг — это итеративный процесс. Код усложняется, когда добавляются новый фичи, потом упрощается, когда его рефакторят. Вот такой «маятник».
        +1

        А теперь внимание, два вопроса:


        1. Чем это лучше уже существующих библиотек (начиная с банального Autofac)?
        2. Интегрируется ли это с Microsoft.Extensions.DependencyInjection?
          +2
          Не лучше и не хуже. Предполагается что это не библиотека внедрения зависимостей, там нет классического контейнера.
          Представьте, что вы работаете над абстракциями и их реализациями некоторой предметной области. Например, вы добавляете новый параметр в конструктор какой-то реализации. А невидимый помощник тут же пытается построить граф зависимостей с учетом этого последнего изменения. Мгновенно проверяет валиден ли он, подсказывает что нужно поправить и подсвечивает код с проблемами и дает рекомендации.
          Параллельно с вами это помощник создает код для композиции объектов вашей предметной области так, как если бы вы это делали сами вручную. Нет контейнеров, нет зависимостей на библиотеки кода, нет рефлексии типов. Просто код, который вы можете сами написать руками. Резюмируя:

          1. Это банально сильно быстрее :)
          2. Пока нет, но если будет интерес людей, то почему бы и нет
            +1
            Не лучше и не хуже.

            Хуже, потому что не имеет такого количества интеграций. Так зачем мне это использовать, если оно при этом не лучше?


            Мгновенно проверяет валиден ли он, подсказывает что нужно поправить и подсвечивает код с проблемами и дает рекомендации.

            … по сотне проектов с неявными зависимостями?


            Параллельно с вами это помощник создает код для композиции объектов вашей предметной области так, как если бы вы это делали сами вручную.

            Вот только "вручную" я не могу (точнее могу, но код будет уродлив) объявить в одном проекте реализацию зависимости, которую использовать в другом проекте динамически (подложили сборку в бин — используется, не подложили — не используется). А еще я не могу предложить потребителям зависимость, реализация которой им при этом недоступна (интерфейс — public, реализация — internal). Значит и ваш "помощник" не сможет.


            Это банально сильно быстрее

            Бенчмарки в студию, на реальном проекте, чтобы было видно вклад в общую производительность. У нас вот в реальной системе накладные расходы на Autofac начинают быть заметными только тогда, когда мы ошибаемся (например, начинаем создавать зависимость тысячи раз за запрос).


            Пока нет, но если будет интерес людей, то почему бы и нет

            А как вы, если у вас нет контейнера, поддержите IServiceProvider?

              +1
              Хуже, потому что не имеет такого количества интеграций. Так зачем мне это использовать, если оно при этом не лучше?

              Так я же не навязываю, не хотите не используйте.
              … по сотне проектов с неявными зависимостями?

              Ну Resharper как-то справляется, пока есть идея, и какая-то простенькая реализация
              подложили сборку в бин — используется, не подложили — не используется

              Уверен, что это не задача библиотек контейнеров. Например, некоторые люди хранят данные в формате ключ значение в Dictionary не потому, что когда-либо им понадобится быстрый поиск значения по ключу, а потому что … не знаю почему, лень было написать свой тип, или хотя бы тупл использовать и положить его в лист может быть
              А еще я не могу предложить потребителям зависимость, реализация которой им при этом недоступна (интерфейс — public, реализация — internal).

              Ну используйте InternalsVisibleTo или напишите код, который это делает и полагайтесь на него. Это как бы не задача контейнера
              Бенчмарки в студию, на реальном проекте, чтобы было видно вклад в общую производительность. У нас вот в реальной системе накладные расходы на Autofac начинают быть заметными только тогда, когда мы ошибаемся (например, начинаем создавать зависимость тысячи раз за запрос).

              Бенчмарки чего? Этого кода?
              new CardboardBox<ICat>(
                      new ShroedingersCat(
                        new Lazy<State>(
                          new Func<State>(
                            (State)Indeterminacy.Next(2))))));
              

              Если вы вызываете много раз Resolve из кода, на мой взгляд это не совсем DI. В идеале ваш код не должен знать про инфраструктуру
              А как вы, если у вас нет контейнера, поддержите IServiceProvider?

              Вариантов как сделать множество. Ведь там все достаточно просто. Хотелось бы выбрать правильный. Сейчас же поддерживаются BCL типы
                0
                Ну 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? Там даже скоупы есть — которых у вас, заметим, нет.

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

                  Когда слишком много проектов и кода может быть имеет смысл использовать бинарные зависимости.

                  Вот только «вручную» я не могу (точнее могу, но код будет уродлив) объявить в одном проекте реализацию зависимости, которую использовать в другом проекте динамически (подложили сборку в бин — используется, не подложили — не используется). А еще я не могу предложить потребителям зависимость, реализация которой им при этом недоступна (интерфейс — public, реализация — internal). Значит и ваш «помощник» не сможет.


                  Я смутно понимаю задачу. Это что то похожее на плагины, которые автоматом подтягиваются из папки и internal типы загружаются рефлекшеном? И это ответсвенность IoC/DI? То-есть контейнер ходит по файловой системе? Я не хочу углублятся в этот вопрос, но да Pure DI не будет ходить по файловой системе, так как это слишком частный случай

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


                  В случае Pure.DI нет библиотеки. Что мерить не очень понятно.

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


                  Под инфпаструкторой я имел ввиду инфраструктурный код, например код, хостинга приложения, логирование, метрики… и композиция

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

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


                  Ну еще и две недели не прошло как я подумал про этот проект и треть из этого времени проболел, так что все впереди :)
                    0
                    Это что то похожее на плагины, которые автоматом подтягиваются из папки и internal типы загружаются рефлекшеном?

                    "Похожее". Это система с точками расширения. internal, кстати, здесь не при чем, это отдельная задача.


                    И это ответсвенность IoC/DI?

                    Ответственность DI-контейнера — предоставить зависимости, когда потребитель запрашивает, ну скажем, IEnumerable<IFileProvider>. А вот откуда это множество берется — уже зависит от задачи. У нас вот оно часто собирается динамически, просто потому, что система сложная (и еще и расширяемая).


                    То-есть контейнер ходит по файловой системе?

                    Нет, контейнер не ходит по файловой системе.


                    В случае Pure.DI нет библиотеки. Что мерить не очень понятно.

                    Мерять надо производительность приложения, использующего разные варианты DI. Не важно, библиотека, не библиотека.


                    Под инфпаструкторой я имел ввиду инфраструктурный код, например код, хостинга приложения, логирование, метрики… и композиция

                    Вот именно это я и пишу.


                    Ну еще и две недели не прошло как я подумал про этот проект и треть из этого времени проболел, так что все впереди

                    В таком случае и понимание всех проблем прикладного использования у вас все еще впереди.

            +1

            Есть проекты где просто нельзя использовать сторонние библиотеки в виду каких-либо ограничений. Вариантов несколько:


            • не использовать, делать все руками
            • IL Merge (но что делать если вдруг надо подписывать сборки? Только отложенную подпись чур не предлагать, геморрой еще тот)
            • генераторы кода, наподобие представленного в статье

            По мне так третий пункт наиболее оптимальный.
            Единственное что, я бы хотел видеть сгенерированный код вживую, чтобы можно было подебажить и все такое. Насколько я понял, кодогенерация рослином, используемая тут, этого не даст. Поправьте, если не прав.


            А так в целом, как по мне, идея отличная, еще с анонса АПИ для кодогенерации размышлял о таком.

              0
              Есть проекты где просто нельзя использовать сторонние библиотеки в виду каких-либо ограничений.

              Значит, и эту будет нельзя использовать.


              (но вообще, конечно, я бы предпочел просто не иметь дела с такими проектами, потому что ну зачем?)

                0
                Значит, и эту будет нельзя использовать.

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


                Но возможно я что-то пропустил… В таком случае согласен, что особо смысла нет, за исключением особо привередливых к производительности проектов.

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

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

                    +2

                    Есть довольно древний PaaS (который раньше был on-premise, а потом переехал в облако), у него в рантайме есть .NET определенной версии, и, собственно, все.
                    Других библиотек в общий домен подгрузить нельзя.
                    Есть плагины, которые хранятся в базе, и запускаются в песочнице. 1 плагин — 1 dll.
                    Соответственно, никакой возможности зареференсить другую сборку, т.к. ни о какой динамической подгрузке речи нет — грузится только то, что вызвано напрямую.


                    Соответственно, в момент компиляции что угодно можно вызывать, если оно сгенерит код и отойдет в сторонку. Хоть .NET Core, хот PowerShell. В рантайме — только ссылки на стандартные либы .NET.


                    Вот так и живем...

                      0

                      Воу. Просто воу.


                      Я бы, конечно, смотрел в сторону включения всех зависимостей в сборку (как это, скажем, в IdentityServer3 было сделано, и это тот самый ILMerge). Но еще раньше, будем честными, я бы смотрел в сторону выхода.

                        0

                        Ну, ILMerge-то никто не отменял. Да и банальный Assembly.Load спокойно работает в песочницах, так что в сложных случаях можно просто покидать все зависимости в ресурсы.


                        Но, вообще говоря, я бы этот PaaS с такими ограничениями просто не использовал. Поддержка плагинами своих зависимостей реализуется довольно просто, пусть и с ограничениями, и если в древнем сервисе её до сих пор не сделали — значит, им просто наплевать на пользователей.

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

                      Один пакет кодогенерации это анализатор, который не добавляет зависимость
                      Пакет API обычный — там нет кода и он позволяет использовать свои атрибуты разметки из модулей предметной области что не добавить в них ни каких зависимостей

                      Ну если скажем добавить JSON с подсказками к построению графа зависимостей то и контракты будут не нужны
                    +1
                    По мне так третий пункт наиболее оптимальный.
                    Единственное что, я бы хотел видеть сгенерированный код вживую, чтобы можно было подебажить и все такое. Насколько я понял, кодогенерация рослином, используемая тут, этого не даст. Поправьте, если не прав.

                    Можно увидеть результаты. Я вот тут же гифку прицепил, где редактирую код и одновременно с этим меняется код построения композиции
                  0

                  Было бы интересно сравнить с DryIocZero.

                    +1
                    Я как раз вчера добавил сюда github.com/danielpalme/IocPerformance :)
                    Но эти тесты не особо показательны, так как они по сути тестируют метод Resolve(), который создает композиции по 3 — 15 объектов, вызывая его миллионы раз. Тестируется работа той или иной реализации Dictionary<,>. А за без контейнерный вариает просто выдается еще какая то одна реализация Dictionary<,> :)

                    Я предполагаю, что создание композиции в идеальном случае выполняется один раз в приложении в самом начале его работы и она состоит из тысяч объектов. Иначе это сервис локатор какой то.

                    Еще плохо, что этот достаточно популярный репозиторий не использует github.com/dotnet/BenchmarkDotNet и собирает статистику весьма примитивными способами.
                    0

                    Это же Dagger только для .NET, поддержка Xamarin планируется?

                    +2

                    Мне понравилась идея с <ТТ> — в отличие от Bind(typeof(IBox< >)).To(typeof(MyBox<>)) здесь компилятор сможет проверить, что MyBox<T> реализует IBox<T>, если я правильно понял. Определение циклических зависимостей и прочих ошибок на этапе компиляции, а не при запуске, как в классических DI фреймворках, тоже полезная фишка.
                    Но что касается производительности, мне действительно трудно представить кейс, когда resolve ощутимо сказывается на перфомансе. Коллега пару лет назад тестировал несколько библиотек (Ninject, Autofac, MS DI, если правильно помню) и пришёл к выводу, что разрешение даже огромного графа зависимостей занимает довольно ничтожное время, сравнение по этому критерию не имеет смысла. Если у вас есть данные в подтверждение противоположной точки зрения, будет любопытно взглянуть.

                      0
                      Мне понравилась идея с <ТТ> — в отличие от Bind(typeof(IBox< >)).To(typeof(MyBox<>)) здесь компилятор сможет проверить, что MyBox реализует IBox, если я правильно понял.

                      Да все верно.

                      Но что касается производительности, мне действительно трудно представить кейс, когда resolve ощутимо сказывается на перфомансе. Коллега пару лет назад тестировал несколько библиотек (Ninject, Autofac, MS DI, если правильно помню) и пришёл к выводу, что разрешение даже огромного графа зависимостей занимает довольно ничтожное время, сравнение по этому критерию не имеет смысла. Если у вас есть данные в подтверждение противоположной точки зрения, будет любопытно взглянуть.


                      Во многом я соглашусь с вами.
                      Новые объекты в приложении могут появляется постоянно на протяжении всего времени его работы и их может быть очень много, они появляются и исчезают непрерывно с большой скоростью. Приложение может работать месяцами.
                      Скорость зависит от способа, которым граф резолвится. Продвинутые библиотеки внедрения компилируют лямда функции для того, чтобы его собрать и тогда сам процесс композиции действительно быстрый, но, чтобы скомпилировать лямбду тоже нужно время. Я бы не сказал, что Ninject, Autofac относятся к продвинутым в плане производительности, а в MS DI все хорошо. Вот тут я делал замеры. Понятно эти все замеры плохо отражают реальность, но какое-то представление о потерях дают.
                      0

                      Выглядит очень круто. Если source generators приживутся, то это подход имеет все шансы стать основным.

                      0

                      Я вот что-то задумался внезапно. А как в этом решении сделать следующее: есть некий компонент, достаточно сложный, чтобы уже использовать DI (возьмем как пример IdentityServer4); соответственно, у него есть сервисы, выраженные в интерфейсах, для большей части из которых есть реализации по умолчанию, для некоторых реализаций нет вообще (их должен предоставить потребитель, чтобы синтегрировать компонент), некоторые реализации потребитель заменить (стандартными средствами, по крайней мере) не может; при этом, что важно, потребитель может сам пользоваться сервисами, предоставляемым компонентом, для своих целей.


                      Итого, нам нужно:


                      • включить в DI полный граф зависимостей стороннего компонента
                      • доопределить недостающие зависимости
                      • переопределить некоторые ранее определенные реализации

                      Как это сделать с использованием Pure.DI?

                        0
                        Как вариант на этапе или до компиляции получил бы метаданные для построения графа зависимостей стороннего компонента. Как? Можно скажем написать .NET tool который это сделает и сложит все в JSON заранее, ведь эти данные не изменятся. Генератор может это и сам сделать – это же обычный .NET процесс, но нужно ли? Собственно и хотелось собрать ваши идеи. А далее все как обычно, добавил или переопределил привязки.
                          0
                          Как вариант на этапе или до компиляции получил бы метаданные для построения графа зависимостей стороннего компонента.

                          Ммм, а что делать с более чем одной реализацией для сервиса (которые компонент оставляет на выбор потребителя)?


                          А что делать с теми реализациями (да и сервисами), которые internal для компонента?


                          Ну то есть, грубо говоря, вот у вас есть простенькая цепочка:


                          public interface IFacade
                          public interface IStorage
                          internal class Facade
                          {
                            public Facade(Engine engine)
                          }
                          internal class Engine
                          {
                            public Engine(IStorage storage)
                          }

                          Потребителю нужно IFacade, и он может задать свою реализацию IStorage (а по умолчанию будет использоваться реализация в памяти). Какой код будет сгенерен?


                          Ну и да, я все-таки не понимаю: так кто же поставляет эти метаданные, автор компонента или потребитель?

                            0
                            Представьте, что у вас нет контейнеров, а есть просто набор типов в DI стиле. Как вы поступите в этой ситуации? Pure DI сейчас сделает за вас рутинную работу, проверит граф и напишет код композиции, на этом, пока, вся его зона ответственности.
                            Но если рассматривать эту ситуацию как идею для новой фичи, то можно добавить API чтобы Pure DI используя, например, полные имена типов создавал эти объекты этих типов рефлекшеном и лямбда функциями:
                            .Bind<IFacade>().To(“Abc.Façade, myassembly”)

                            Ну и да, я все-таки не понимаю: так кто же поставляет эти метаданные, автор компонента или потребитель?

                            Ну вот вы пользуетесь библиотекой что бы решить этот вопрос, кто и что ей поставляет? Здесь тоже самое
                              0
                              Представьте, что у вас нет контейнеров, а есть просто набор типов в 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 никакой общей абстракции как раз и не приносит.

                        0
                        Этот прдход имеет смысл только для Apple. В веб проектах проще и надежнее использовать майкрософтовскую реализацию. Все прочие движки DI из веб-сервисов сам выпилил и вам советую. Потому что если нужен функционал которого нет в M.E.DI — то это говорит об архитектурном недостатке. С очень большой натяжкой подобный подход подойдет наверно в программировании под Apple — но не уверен что там нужно DI в такой форме
                          0
                          MS Dependency injection – хорош. Но не все приложения web и должна быть альтернатива
                            0

                            У M.E.DI вроде бы нет никаких специфичных для web зависимостей.

                              0
                              Я и не утверждал обратного. Просто автор комментария пишет что
                              В веб проектах проще и надежнее использовать майкрософтовскую реализацию

                              и мне кажется это неплохая мысль, но не все приложения web
                                0

                                В веб-проектах (если мы под ними понимаем ASP.NET Core) проще и надежнее использовать M.E.DI, потому что он там уже есть. Точнее, говоря, вам придется использовать его базовую абстракцию, а уж какую реализацию вы выберете — на ваше усмотрение (хотя, как верно пишут выше, в ощутимой части случаев можно ограничиться дефолтной от M.E.DI, и все будет хорошо).


                                Но за пределами ASP.NET Core, внезапно, как только вы хотите, скажем IHttpClientFactory — вам тоже нужен M.E.DI, они связаны. Или если вы хотите Microsoft.Extensions.Logging — вам тоже удобнее будет взять M.E.DI, потому что есть готовая инфраструктура и настройки. Или Microsoft.Extensions.Options.


                                Поэтому, конечно, не все приложения web, но если вы хотите опираться на весьма ощутимую инфраструктуру, сделанную MS и другими компаниями для .NET Core, вам намного удобнее иметь в проекте как минимум абстракцию от M.E.DI.

                                  0
                                  Спасибо за идею. Я уверен добавить интеграцию будет не очень сложно. Честно говоря я уже думал это сделать
                                    0
                                    Точнее, говоря, вам придется использовать его базовую абстракцию

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

                                      –1

                                      Я когда пробовал перенести IHttpClientFactory, воткнулся в то, что фактически ее приходилось целиком скопировать, чтобы оно завелось. Это не то, чего мне хотелось.

                                      –1
                                      Базовая абстракция M.E.DI — это IServiceProvider, или ещё что-то?
                                      Если только IServiceProvider, то он — часть даже не M.E.DI, а базового дизайна библиотеки .NET (используется в куче мест в ней, в том числе — жутко древних: System.Web.HttpContext, System.ComponentModel.ISite...) И реализовать его в дополнение к уже написанному коду вряд ли сложно будет — какой-то его аналог в любом средстве отображения интерфейсов на реализации по-любому уже должен быть (как можно иначе — не представляю), а после чего останется только сам интерфейс прикрутить, из одного метода.
                                      Но вот если поддержка scoped lifetime нужна — там надо и кое-что из абстракций M.E.DI тащить, да: реализовывать IServiceScopeFactory и IServiceScope. Но это IMHO — не так уж и много. Другое дело, что преимуществ от того же решения из статьи не просматривается: отсутстве необходимости в дополнительных сборках для работы приложения таковым не является, ибо M.E.DI нынче AFAIK уже даже в стандартный рантайм перенесли.
                                        0
                                        Базовая абстракция M.E.DI — это IServiceProvider, или ещё что-то?

                                        IServiceProvider + IServiceCollection.


                                        какой-то его аналог в любом средстве отображения интерфейсов на реализации по-любому уже должен быть (как можно иначе — не представляю)

                                        Ну вот в посте, если я ничего не путает, никакого отображения в рантайме нет, все в компайл-тайме. А IServiceProvider нужно в рантайме.


                                        ибо M.E.DI нынче AFAIK уже даже в стандартный рантайм перенесли.

                                        Что-то не похоже: Microsoft.Extensions.DependencyInjection.Abstractions, Microsoft.Extensions.DependencyInjection

                                          0
                                          (все, готово...)
                                          IServiceProvider + IServiceCollection.

                                          IServiceCollection самому реализовывать не надо. Достаточно на сборку нужную сослаться: IServiceCollection — это чисто данные, сущность совершенно пассивная, просто список зарегистрированных описателей сервисов типа ServiceDescriptor, там — только описание, как реализованы сервисы, а поведения для получения их реализаций там нет.
                                          Стандартная реализация этого интерфейса — ServiceCollection — содержит внутреннее поле типа List и совершенно прямолинейно отображает свойства и методы IServiceCollection на методы этого List. Никакой другой логики там нет. Если использовать стандартный способ инициализации для Generic Host, то HostBuilder.Build сам этот класс создаст, сам выполнит все делегаты, его заполняющие, которые ему через ConfigureServices в очередь накидали, и сам вызовет нужную реализацию IServiceProviderFactory, если ее правильно указать (методы для этого там есть).
                                          А логика создания реального DI-контейнера из этого списка регистраций находится в другом месте: в классе, реализующем IServiceProviderFactory (DefaultServiceProviderFactory по умолчанию). Вот реализацию этого интерфейса под нестандартный DI действительно надо делать самому, чтобы использовать стандартные куски из .NET — ASP.NET или ещё чего: оно все там конфигурирует сервисы в рантайме, путем добавления делегатов, пишущих записи в IServiceCollection.
                                          А если в Compile time зависимости разрешать, как автор предполагает — то тогда да, придется исходники ASP.NET в проект включать и компилить вместе с проектом (шутка, если что: в реальности никто так заморачиваться ради достоинств обсуждаемого решения не будет, особенно если этих достоинств нет)
                                          Ну вот в посте, если я ничего не путает, никакого отображения в рантайме нет

                                          А это тогда что: public static void Main() => Glue.Resolve().Run();?
                                          Что делает Resolve? Если судить по коду выше — похоже, что принимает параметр-тип Program и создает объект, реализующий этот тип. Конкретно здесь специально отображение не нужно, конечно — можно создать экземпляр самого класса, который передан параметром-типом (а конструктор — сгенерить на этапе компиляции) но интерфейс-то так не создашь? Значит, нужен список отображения. Впрочем, могу допустить, что он сумел эту таблицу хитро обработать и прошить все, что из нее следует, в сгенеренном коде, так что ее теперь в рантайме ни достать, ни пополнить.
                                          Допускаю, что вы правы — но тогда тем хуже для автора.

                                          Что-то не похоже: Microsoft.Extensions.DependencyInjection.Abstractions, Microsoft.Extensions.DependencyInjection

                                          Не туда смотрите. Смотрите в репозиторий:
                                          github.com/dotnet/runtime/tree/main/src/libraries/Microsoft.Extensions.DependencyInjection.Abstractions
                                          github.com/dotnet/runtime/tree/main/src/libraries/Microsoft.Extensions.DependencyInjection
                                            +1
                                            IServiceCollection реализовывать не надо

                                            Его надо поддержать. Т.е. надо все, что там зарегистрировано, умудриться аккуратно перенести в свой контейнер. Которого в посте нет.


                                            А это тогда что: public static void Main() => Glue.Resolve().Run();?

                                            А вот это вы спросите у автора поста, но если я его правильно понял, то это сгенеренный метод, за которым нет никакого контейнера.


                                            но интерфейс-то так не создашь? Значит, нужен список отображения.

                                            Да нет, не нужен список отображения, достаточно сгенерить метод Resolve<IA>() => new A().


                                            Не туда смотрите. Смотрите в репозиторий:

                                            И что? Там как раз лежат исходники тех пакетов, на которые я ссылки дал.

                                              0
                                              Т.е. надо все, что там зарегистрировано, умудриться аккуратно перенести в свой контейнер.

                                              Да, надо реализовывать IServiceProviderFactory.
                                              Которого в посте нет.

                                              Что ж, поверим автору — но тогда ему работы прибавится для адаптации к использованию разных полезным компонентов .NET Core, да.
                                              А вот это вы спросите у автора поста, но если я его правильно понял, то это сгенеренный метод, за которым нет никакого контейнера.

                                              Дык, я ему лучше так поверю. И вам тоже.
                                              И что? Там как раз лежат исходники тех пакетов, на которые я ссылки дал.
                                              Смотря для кого: для тех кому нужно исходники найти — они в в репозитории стандартного рантайма, а кому нужно программу установить — таки да, в установочном пакете рантайма нужной DLL нет, надо с NuGet качать. Но в SDK, подозреваю, они есть, по крайней мере VS2019 их цепляет без вопросов, и приложение при запуске на отладку из нее — тоже. На изолированной машине ему сложновато было бы это из NuGet скачать. Другое дело, что речь я вел об исходном SDK, который вместе с VS приехал.
                                                –1
                                                но тогда ему работы прибавится для адаптации к использованию разных полезным компонентов .NET Core, да.

                                                Это ровно то, о чем я и говорил изначально.

                                              0
                                              А это тогда что: public static void Main() => Glue.Resolve().Run();?
                                              Что делает Resolve? Если судить по коду выше — похоже, что принимает параметр-тип Program и создает объект, реализующий этот тип.

                                              Метод Resolve() создает композицию с рутом типа T.
                                              который передан параметром-типом (а конструктор — сгенерить на этапе компиляции) но интерфейс-то так не создашь

                                              И почему интерфес не создашь?… это же генератор кода

                                              Я не очень понимаю ваши сомнения. Классическихе IoC библиотеки = рантайм логика + рефлекшн. Библиотеки как Pure.DI = синтаксические деревья вашего кода + семантическая модель вашего кода и всех его зависимостей, со всей инфой как в рефлекшене + рантайм логика, которую можно легко добавить в ваш проект + рефлекшн если нужно, но зачем, и все что угодно.
                                                0
                                                И почему интерфес не создашь?

                                                Экземпляр интерфейса создать нельзя, по правилам языка — я это имел в виду. Можно создать экземпляр типа, который его реализует, но для этого одного параметра-типа у обобщенного метода недостаточно, надо знать два типа — интерфейса и реализации.
                                            0
                                            M.E.DI нынче AFAIK уже даже в стандартный рантайм перенесли.

                                            Мммм.


                                            https://docs.microsoft.com/en-us/dotnet/standard/runtime-libraries-overview#extensions-to-the-runtime-libraries


                                            Some libraries are provided in NuGet packages rather than included in the runtime's shared framework. For example [...] Dependency injection
                                              0
                                              Ну, не знаю. В VS2019 оно давно уже в стандартной части обитает, приезжает сразу со студией, никаких пакетов дополнительно ставить не потребовалось.
                                              (на изолированной-то от интернета машине я бы это сразу заметил).
                                                0
                                                В VS2019 оно давно уже в стандартной части обитает

                                                У меня VS2019, и эти пакеты ставятся из нюгета. Что, в общем-то, неудивительно, потому что связь между версией студии и версией фреймворка не самая прямая.


                                                Документация пишет — нюгет. Сам нюгет эти пакеты тоже упоминает. Не вижу оснований думать, что они есть в рантайме.

                                                  0
                                                  Я проверил: в том что называется runtime — их нет.
                                    +2

                                    Привет,
                                    Интересно знает ли автор о двух других DI-IoC имплементациях на сорс генераторах:



                                    По поводу резолва графа только один раз в реальных приложениях и бесполезности бенчмарка миллиона резолвов, это наверное не так, если вы резолвите для unit-of-work, например для веб реквеста, сессии, транзакции и т.д., что похоже на реальный мир и может потребовать миллионов резолвов.

                                      0
                                      Интересно знает ли автор о двух других DI-IoC имплементациях на сорс генераторах:

                                      Да я случайно наткнулся на них когда делал генерацию кода :) Но идея немного другая но похожая.

                                      По поводу резолва графа только один раз в реальных приложениях и бесполезности бенчмарка миллиона резолвов, это наверное не так, если вы резолвите для unit-of-work, например для веб реквеста, сессии, транзакции и т.д., что похоже на реальный мир и может потребовать миллионов резолвов.

                                      В этом случае не нужен резолв каждый раз. Просто внедрите «фабрику». Вызов Resolve много раз в раных местах — это сервис локатор
                                        +1
                                        В этом случае не нужен резолв каждый раз. Просто внедрите «фабрику». Вызов Resolve много раз в раных местах — это сервис локатор

                                        "Обычно" этого нельзя сделать, потому что вы не контролируете этот резолв — его делает внешний фреймворк через абстракцию типа IServiceProvider :/

                                          0
                                          Да что касается IServiceProvider это так. Наверно там предполагается что реализация может поменяться при каждом следующем вызове :) Но это «обычно» только для asp.net
                                            0
                                            Наверно там предполагается что реализация может поменяться при каждом следующем вызове

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

                                              0
                                              Не подскажете, как этого добиться?
                                              В самом интерфейсе подходящего метода нет.
                                              Или вы под реализацией имеете в виду конкретный экземпляр класса, а не его тип?
                                                0
                                                Не подскажете, как этого добиться?

                                                Очень просто:


                                                services.AddTransient<IService>(provider => WeatherIsFine ? new ServiceA() : new ServiceB());
                                                  0
                                                  Так понятно. Я-то думал, что речь о переконфигурации контейнера после его создания.
                                                    0

                                                    А зачем что-то переконфигурировать, если описанный выше метод позволяет любое изменение поведения?


                                                    (А еще под IServiceProvider может лежать не-дефолтная реализация. Тот же Autofac до пятой, что ли, версии, позволял менять уже собранные контейнеры.)

                                                0

                                                Граф должен быть определённым. Это не очень хорошо.

                                                  –1

                                                  Это, может быть, и не очень хорошо, но это иногда необходимо. У вас никакая часть конфигурации приложения не меняется в рантайме? Я очень за вас рад. А бывают системы, в которых какие-то вещи, выраженные как сервисы, конфигурят на лету.

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

                                                Если тип реализующего класса, то отнюдь: в IServiceProvider даже нет метода для этого самого изменения реализации. И для реализующего его по умолчанию класса ServiceProvider — тоже.
                                                А ваш Pure DI — он не умеет делать реализацию в виде функции?
                                                Если умеет, то и вы так же можете.
                                                  0

                                                  Да умеет, но не для этого. Выстрелить в ногу можно всегда если сильно захотеть :)

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

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


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

                                                    0
                                                    На самом деле, там просто предполагают, что провайдер не обязан поддерживать Func, а стандартный контракт подразумевает, что если вы хотите новый экземпляр — вы его запрашиваете у провайдера.

                                                    Добавить поддержку Func или чего то своего — это не проблема, еще один тип в сотнях регестрируемых даже при минимальной конфигурации. И через него можно запрашивать новый экземпляр пер реквест. В любом случае нужно было сделать что то, что бы не подталкивать людей использовать все это хозяйство как локатор сервисов, когда каждый может внедрить себе провайдер сервисов, а потом создавать все что угодно.

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

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

                                                    Я думаю люди из Microsoft предположили что создание первого контроллера это и есть «точка входа» и от этой точки нужно делать композицию. И к тому же потратить лишние 100% в случае хорошей реализации мапы и 350% в случае библиотеки MS dependency на каждый новый Resolve по сравнению с тем, если этого не делать — наверно это не так уж и много. По моим измерениям это примерно 35 наносек. на вызов на Intel Xeon E5-2673 или 25 на моем ноутбучном Intel Core i7-10875H для MS dependency. Но у некоторых библиотек внедрения как, например, Autofac — это уже 15 000, Ninject 115 000 лишних ns
                                                      0
                                                      Добавить поддержку Func или чего то своего — это не проблема

                                                      Добавить куда? Там контракт с минимумом методов, вы предлагаете в него добавить поддержку, которую надо навязать всем имплементаторам ради не очень понятной пользы.


                                                      И через него можно запрашивать новый экземпляр пер реквест.

                                                      Дадада, per request. Как вы только с помощью Func сделаете per-request сервисы?


                                                      В любом случае нужно было сделать что то, что бы не подталкивать людей использовать все это хозяйство как локатор сервисов

                                                      А кому нужно-то? И зачем?


                                                      Всегда можно поднять «фабрики» со всеми типами контроллеров и добавить их использование в логику маршрутизации.

                                                      И чем эти "фабрики" будут отличаться от обычного сервис-провайдера — кроме того, что их придется повторить для каждого случая, когда нам нужен резолв по типу (например, для middleware)? Ну вот посмотрите на IMiddlewareFactory.


                                                      Я думаю люди из Microsoft предположили что создание первого контроллера это и есть «точка входа» и от этой точки нужно делать композицию.

                                                      Это точно не так, потому что DI начинает работать намного раньше.


                                                      Но у некоторых библиотек внедрения как, например, Autofac — это уже 15 000

                                                      Я уже говорил, кажется, что у нас в большом проекте используется Autofac, и накладные расходы от его добавления заметны только тогда, когда мы ошибаемся.

                                                        0
                                                        А кому нужно-то? И зачем?

                                                        Как дополнительная иллюстрация: вот есть в ASP.NET Core такие милые штуки как ApplicationSerices и RequestServices. Они, конечно, service locator по определению Симана, анти-паттерн, все такое. Не буду спорить, да, service locator. Но с ними удобно, и они позволяют писать намного более читаемый код, нежели без них (я сравниваю с OWIN, в котором пайплайн был концептуально такой же, но *Services не было).


                                                        Кому станет лучше, если вы их уберете? Как начнет выглядеть код? Точно ли он будет лучше?

                                                          0

                                                          Это вам решать, я для себя решил :)

                                                            +1

                                                            И что же вы для себя решили, как с вашим подходом будет выглядеть типичный Startup.Configure?

                                                          –1

                                                          Добавить тип, и его резолвить, а он сможет создавать неограниченное количество объектов определённого типа что бы избежать обращения к мапе каждый раз. Этим они и будут отличаться. И про них знает только асп. Интересы не меняются. Пере реквест он сможет разрулить или спец время жизни.


                                                          Вот когда начинает работать DI это и сделать


                                                          Возможно, если у вас увеличится нагрузка то почувствуете расходы.

                                                            +1
                                                            Добавить тип, и его резолвить, а он сможет создавать неограниченное количество объектов определённого типа что бы избежать обращение к мапе каждый раз. Этим они и будут отличаться. И про них знает только асп. Интересы не меняются. Пере реквест он сможет разрулить или спец время жизни.
                                                            Вот когда начинает работать DI это и сделать

                                                            Ничего не понял, включая даже то, на что конкретно вы отвечаете.


                                                            Возможно, если у вас увеличится нагрузка то почувствуете расходы.

                                                            У нас уже достаточно большая нагрузка. Просто у нас есть другие потери производительности, на фоне которых DI пренебрежимо мал.

                                                  +1
                                                  Просто внедрите «фабрику»

                                                  …и внутри этой фабрики вручную делать всё то, что обычно делает контейнер?

                                                    0

                                                    Это я так называю Func<T>() Про контейнер в идеале должна знать 1 строчка нашего кода где то в районе Main()

                                                      0

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


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

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

                                                        Справедливости ради, написано:


                                                        Все просто — Func<>, как и другие BCL типы поддерживается из коробки.
                                                          –1

                                                          А, теперь вижу.

                                                          –1

                                                          Он поддерживает небольшой набор времени жизни и простую возможность определить свои.

                                                            0

                                                            "Определить свои" — это через ILifetime, я правильно помню?


                                                            А как тут понять, как это время жизни началось и закончилось?

                                                              0

                                                              Когда в стратегию придёт запрос на резолв, она определит от куда взять объект. Когда нужно объект удалить это стратегия решает сама. Контейнера нет

                                                                +1

                                                                Решает на основании чего? Вот хотим мы сделать банальный (в том смысле, что обязательный сейчас) per scope lifetime, как его реализовать?

                                                                  –1
                                                                  А в чем там сложность то? Есть реализация IServiceScopeFactory, которая создает объекты типа IServiceScope, которые обычные сервис провайдеры, но хранят у себя объекты, которые можно утилизировать и делают это когда их утилизируют. За одно хранит свои «синлтоны». Я делал это не раз. Подумаю как сделать здесь красиво
                                                                    +1
                                                                    А в чем там сложность то?

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


                                                                    Есть реализация IServiceScopeFactory, которая создает объекты типа IServiceScope

                                                                    … и куда вы эти объекты, простите, запихнете вашему ILifetime?

                                                                      –1
                                                                      Ну примеров много погуглите или вам нужен именно мой код?
                                                                      Я их верну из фабрики и забуду про них а ASP позаботится об их утилизации вместе с их содержимым.
                                                        +1

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


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


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

                                                          +1

                                                          На самом деле, даже без Func интересно — а кто вызывает Dispose у вброшенных сервисов и когда? Для простоты, возьмем синглтоны...

                                                            0

                                                            Ещё раз это Pure.DI — это не контейнер. Здесь синглтон это, то как его делают когда нет контейнеров — настоящий статическое поле в приватном статическом классе, до которого не добраться другими способами, кроме как попросить внедрить. Если вы хотите использовать синглтон как в классических библиотеках контейнеров нужно использовать Binding lifetime. Определить стратегию и привязать к требуемый типам. Эта ваша стратегия уже сложит dispisables куда вам нужно и вы их освободите когда вам нужно. Это все есть в статье с примером реального кода

                                                              +1

                                                              Вот то, что вы предлагаете, "делать, как делают, когда нет контейнеров" — это неудобно. Зачем?

                                                                –1

                                                                Это зависит от ситуации, мне ок в 99%

                                                                  –1

                                                                  "Мне ок" — это сильный аргумент, когда в посте вы пишете "Надеюсь, это библиотека будет полезной. Любые ваши замечания и идеи очень приветствуются."

                                                                    0

                                                                    Неудобно — это такой-же сильный аргумент. Я не пишу ASP.Net приложения. И в 70% использую transient в 30% синглтон. Поэтому мне ок. В экзотических .1% напишу свою стратегию.

                                                                      +1
                                                                      Неудобно — это такой-же сильный аргумент.

                                                                      Понимаете ли, вы просили "любые замечания". "Мне неудобно" — это как раз такого вида замечание, особенно когда оно основано на опыте использования альтернатив.


                                                                      И в 70% использую transient в 30% синглтон. Поэтому мне ок.

                                                                      Ну то есть, я так понимаю, что вам ок, что вы не знаете, когда будут подиспожены ваши синглтоны?


                                                                      В экзотических .1% напишу свою стратегию.

                                                                      Вот в этом и разница. Для вас диспоз синглтона — это "экзотический 1%". А для меня он встречается в каждом приложении, потому что где-то там в контейнере живет логгер, который надо детерминировано закрыть.

                                                                        –1
                                                                        Используя Pure DI на данный момент, я как раз абсолютно точно буду понимать когда они будут подиспожены, потому что сделаю это явно. Может быть я добавлю набор лафтаймов, которые сделаю это автоматически. Или «стратегию» регистрации таких объектов. Не хотелось бы не наворачивать API, его перусложнение ни к чему хорошему не приведет.

                                                                        Я думаю вопрос с утилизацией логера можно очень легко решить используя Pure.DI и сейчас. Но сесли вы бы предложили идею, было бы хорошо
                                                                          +1
                                                                          Используя Pure DI на данный момент, я как раз абсолютно точно буду понимать когда они будут подиспожены, потому что сделаю это явно.

                                                                          Это называется "никогда", если вкратце. Потому что написать удобный disposal для разнородных объектов, которые еще и создаются неизвестно когда — это не так-то просто.


                                                                          Но сесли вы бы предложили идею, было бы хорошо

                                                                          Угу, у меня есть прекрасная идея: давайте заведем нечто, что отслеживало бы жизненные циклы созданных сущностей, и назовем его, ну не знаю, контейнер?

                                                                            –2
                                                                            Это называется «никогда», если вкратце. Потому что написать удобный disposal для разнородных объектов, которые еще и создаются неизвестно когда — это не так-то просто.

                                                                            У меня другой опыт.
                                                                            Угу, у меня есть прекрасная идея: давайте заведем нечто, что отслеживало бы жизненные циклы созданных сущностей, и назовем его, ну не знаю, контейнер?

                                                                            Сделано с блэкджеком и шлюхами
                                                                              +1
                                                                              У меня другой опыт.

                                                                              Возможно. Но пока что опыт-опытом, а в коде этого не видно.


                                                                              Кстати, as an aside. Вашему посту сильно помогли бы примеры сгенеренного кода для разных сценариев, потому что сейчас их посмотреть просто негде, и понять, как оно будет работать в реальной жизни, несколько сложно.


                                                                              Сделано с блэкджеком и шлюхами

                                                                              Boring. В том смысле, что это "просто еще один DI-контейнер", у меня уже два разных есть, не вижу смысла в третьем.

                                                                                0
                                                                                Да, я собирался сделать еще пост, после улучшательств и применения в проекте.

                                                                                Я разочарован тем, что языки программирования фактически остановились в своем развитии они очень похожи и часто подталкивают людей к написанию «странного» кода. Подумал, что контейнеры мы используем не от хорошей жизни и что мог бы предложить скажем D# для решения проблем, которые сейчас решают контейнеры. И это было бы взаимно: решая проблемы сильной связанности можно было бы, например сильно упростить сборку мусора. Так как граф был бы формализован, не было бы статики и кучи методов new по всему коду.
                                                                                Короче пока это просто идея и пару дней пробной реализации.
                                                                                  +1
                                                                                  Я разочарован тем, что языки программирования фактически остановились в своем развитии

                                                                                  Остановились? Что-то не видно.


                                                                                  часто подталкивают людей к написанию «странного» кода.

                                                                                  Языки? Точно не люди и их опыт?


                                                                                  что мог бы предложить скажем D# для решения проблем, которые сейчас решают контейнеры.

                                                                                  Но зачем? Если вы почитаете, что тот же Симан пишет сейчас, вы заметите, что он двигается, скажем, в совершенно другом направлении, нежели "язык для решения проблем, которые решает контейнер".


                                                                                  Так как граф был бы формализован, не было бы статики и кучи методов new по всему коду.

                                                                                  В приложении на основании DI и так сейчас нет ни статики, ни кучи new, и это никак не связано с "формализацией" графа. Так что не очень понятно, что вы имеете в виду.

                                                                                    0
                                                                                    Что нового появилось в C#9 или в Kotlin 1.4.3?

                                                                                    Хороший API будет сильно мешать его неправильному использованию или даже сделает это невозможным, так должны делать хорошие языки программирования.

                                                                                    Я имею ввиду, что можно было бы пересмотреть концепцию порождения объектов, наследования типов. Изменить/разработать синтаксис в соответствии с этим подходом и двинуться вперед, а не топтаться на месте тыря мелкие рюшечки у конкурентов.
                                                                                      0
                                                                                      Что нового появилось в C#9

                                                                                      https://docs.microsoft.com/en-us/dotnet/csharp/whats-new/csharp-9


                                                                                      Я имею ввиду, что можно было бы пересмотреть концепцию порождения объектов, наследования типов.

                                                                                      И все еще непонятно, чего конкретно вы пытаетесь достичь.

                                                                                        0
                                                                                        Что нового появилось в C#9

                                                                                        Это был риторический вопрос.
                                                                                        И все еще непонятно, чего конкретно вы пытаетесь достичь.

                                                                                        Я не пытаюсь этого достичь. Мне просто хотелось бы чтобы C# или другой язык сделал не нужным использование контейнеров внедрения, а принес синтаксис и изменения в CLR, которые бы делали все автоматически за программиста.
                                                                                          +1
                                                                                          Мне просто хотелось бы чтобы C# или другой язык сделал не нужным использование контейнеров внедрения, а принес синтаксис и изменения в CLR, которые бы делали все автоматически за программиста.

                                                                                          Но зачем? Зачем вшивать в язык (а, значит, делать ровно одним способом и не обязательно самым оптимальным) то, что может сделать библиотека?

                                                                                            0
                                                                                            Ответил в главной ветке
                                                  +1

                                                  Зачем вы назвали очередной перегруженный DI контейнер таким название? Для маркетинга? Pure DI — это принцип использования DI без каких бы то ни было контейнеров. Не надо добавлять в мир путаницы.

                                                    0

                                                    Чем он перегружен по вашему мнению? Если будет больше деталей будет понятнее суть проблемы. Можно убрать все лишнее.


                                                    Идея в том что он пишет код в стиле чистого DI, так если бы вы это делали сами не использует рефлекшн, компилятор проверяет корректность того что он сгенерил и оптимизирует как часть вашего инфраструктурного кода — просто как помощник в процессе разработки. Он не создаёт ни одного дополнительного инстанса при композиции, помимо тех которые нужны в ней. Не добавляет зависимости. Нет ни какого класса контейнера, есть статический метод построить композицию объектов с корнем типа T.


                                                    Что вы бы сделали по другому не так как он если бы придерживались концепции чистого DI?

                                                      0

                                                      Суть претензии в том, что при использовании любого контейнера код можно писать в стиле чистого DI, ваш не является чем-то особенным.

                                                        –1

                                                        Любой контейнер это зависимость на библиотеку +контейнерый класс. Чистый DI это набор вложенных конструкторов в идеальном случае когда внедрение через конструктор

                                                          –1

                                                          А то как будто у вас нет библиотеки, от которой придётся зависеть!

                                                            0

                                                            Есть генератор кода, который не добавляет зависимостей сборки в классическом понимании — в рантайме их нет. Есть зависимость на контракты — они нужны что бы, используя синтаксис C#, описать граф, но можно обойтись без неё если, скажем, добавить возможность брать эти метаданные из JSON или из спец комментариев к коду :)

                                                              +2

                                                              Во-первых, зависимость на контракты — всё ещё зависимость.


                                                              Во-вторых, вы как-то странно понимаете суть Pure DI. Идея Pure DI — не в отсутствии зависимостей от библиотек, а в том, что все зависимости описываются параметрами конструктора. И все нормальные контейнеры, так или иначе, подобный способ внедрения зависимостей поддерживают.

                                                                0

                                                                Я же написал, что можно избавиться и от них, но пока не придумал способа как это сделать удобно и причин

                                                                  0

                                                                  Суть чистого DI — все сделать по технологии DI, но своими силами, я так этот понимаю

                                                                    +1

                                                                    И вот тут нас снова догоняет вопрос: а зачем? Откуда самоцель "своими руками"?

                                                                      0
                                                                      Причем тут самоцель? Я сформулировал то, как я понимаю термин pure DI и почему думаю, что данная библиотека соответсвует своему названию и это не просто маркетинг. Какие-то сильные стороны я перечислил в статье.
                                                                        0

                                                                        … но не упомянули ни одной слабой стороны, хотя и пишете, что оставляете "только лучшее от этих подходов" (я так понимаю из контекста — чистый DI и DI-контейнеры).

                                                                          0
                                                                          Да я думаю на слабыми местами и попытаюсь их убрать, для этого хочу попробовать ее в реальном проектах. Есть планы попробовать здесь. Это прототип визуально/DSL-ного билд тула который будет одинаково работать локально и на CI сервере, под докером и под WSL и позволит делать очень прикольные вещи
                                                              +1
                                                              Любой контейнер это зависимость на библиотеку +контейнерый класс.

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

                                                      –2
                                                      Когда-то давно изобрели ООП – отлично, появилось много языков программирования что бы поддержать эти принципы. В начале 2000-x начало складываться понимание как ООП применять на практике, но я не припомню, что было сделано что-то существенное что бы учесть этот опыт. Я не историк языков программирования, не их дизайнер и рассуждаю как обычный пользователь. Для меня было всего пара значительных шагов в развитии C#. Первый это поддержка обобщенного программирования добавлением универсальных типов. Второй это LINQ и даже не сам LINQ, а возможность легко работать с кодом в виде деревьев выражений и использовать их для мета-программирования.

                                                      Задумайтесь какие последствия могли бы быть если бы DI поддержали на уровне C#, CLR и IL. Например, можно было бы:
                                                      — добавить специальные DI типы похожие на классы, но
                                                      * без наследования, а только лишь с реализациями
                                                      * без конструкторов
                                                      * без возможности создания через new
                                                      * с понятным синтаксисом внедрения
                                                      * отделить внедряемые зависимости от состояния
                                                      * убрать всю статику и возможность ее использования
                                                      * для зависимостей не нужна Nullability и проверки
                                                      — добавить конструкции языка для описания графа зависимостей
                                                      — поддержать эффективное и потоко-безопасное создание всей композиции объектов разом спец. инструкциями IL (граф определен заранее на момент компиляции)
                                                      — убрать виртуализацию методов внутри композиции, улучшить производительность, так как в композиции будут уже определенные реализации без наследования (как, наверное, планировалось с «sealed»)
                                                      — оптимизировать то, как DI типы хранятся в heap
                                                      — оптимизировать GC для них так как граф известен
                                                      — в целом, склонить разработчиков использовать интерфейсы в зависимостях и композицию вместо наследования
                                                      И это только то, что как-то относится к DI, а если подумать про другой опыт использования ООП. Повторюсь, я не дизайнер языков и рассуждаю как пользователь.
                                                        +1
                                                        Для меня было всего пара значительных шагов в развитии C#.

                                                        Вы, похоже, вообще игнорируете движение C# в сторону мультипарадигменного (а не ОО) языка.


                                                        Задумайтесь какие последствия могли бы быть если бы DI поддержали на уровне C#, CLR и IL.

                                                        Была бы адская мешанина.


                                                        без наследования, а только лишь с реализациями

                                                        И вот прямо сразу: почему без наследования-то? Я только в этом месяце успешно отнаследовался от чужой реализации нужного мне сервиса, заоверрайдил один метод, и все у меня хорошо. А как иначе вы предлагаете расширять функциональность?


                                                        Повторюсь, я не дизайнер языков и рассуждаю как пользователь.

                                                        В том-то и беда, что вы рассуждаете только с точки зрения использования, причем только своего использования. Кажется (за разумное время не смог найти ссылку), у Липперта было развернутое объяснение, как language design team оценивает новые фичи в языке, и это, внезапно, очень сложный процесс, особенно с точки зрения оценки "кому мы навредим".

                                                          0
                                                          Вы, похоже, вообще игнорируете движение C# в сторону мультипарадигменного (а не ОО) языка.

                                                          Я использую все новый фичи и они мне нравятся. Я говорю о значительных изменениях для себя.
                                                          Была бы адская мешанина.

                                                          Почему?
                                                          И вот прямо сразу: почему без наследования-то? Я только в этом месяце успешно отнаследовался от чужой реализации нужного мне сервиса, заоверрайдил один метод, и все у меня хорошо. А как иначе вы предлагаете расширять функциональность?

                                                          Потому что пронаследоваться правильно довольно сложно, а если это сделать плохо то DI работать не будет. Плюс добавляется большая связанность кода, за счет использования protected members родителей. При этом любое наследование легко заменить композицией.
                                                            0
                                                            Я говорю о значительных изменениях для себя.

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


                                                            Почему?

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


                                                            Потому что пронаследоваться правильно довольно сложно

                                                            А сделать DI просто? Нет, совсем нет.


                                                            Плюс добавляется большая связанность кода, за счет использования protected members родителей.

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


                                                            При этом любое наследование легко заменить композицией.

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

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

                                                              Что вы имеете по «игнорируете и мультипарадигменность»? Часто использую функциональный стиль, мне нравится использовать события/Observer/IObservable/RX, активно использовал Concurrency and Coordination Runtime пока он был актуален и TPL сейчас. Почему игнорирую? Я не предаю этому такого значения как универсальные типы, понятно, что это субъективно.
                                                              Потому что немедленно возникает вопрос «когда какие типы использовать».

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

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

                                                              Это его выбор, я пока не готов положиться исключительно на функциональный подход, искусственно себя ограничивая, пока DI прекрасно работает в ООП
                                                                +1
                                                                Почему игнорирую? Я не предаю этому такого значения как универсальные типы, понятно, что это субъективно.

                                                                Я не знаю, почему вы "не придаете этому такого значения".


                                                                Вопросы возникаю и когда использовать структуру или класс, readonly структуру, record.

                                                                А вы предлагаете это еще усложнить.


                                                                Я не уверен в этом. Откладывает решение на потом

                                                                Вы не знаете конкретного случая, поэтому не стоит утверждать, что это порождает технический долг.


                                                                Это его выбор, я пока не готов положиться исключительно на функциональный подход, искусственно себя ограничивая, пока DI прекрасно работает в ООП

                                                                … поэтому вы предлагаете искусственно ограничить всех, внеся DI прямо в язык и CLR. Круто.

                                                        0
                                                        Я не знаю, почему вы «не придаете этому такого значения».

                                                        Это не страшно, это ведь только мои предпочтения.
                                                        А вы предлагаете это еще усложнить.

                                                        Я предлагаю добавить в «это» порядка.
                                                        Вы не знаете конкретного случая, поэтому не стоит утверждать, что это порождает технический долг.

                                                        Во-первых, я не утверждал, а сделал предположение, а во-вторых, не по-вашему конкретному случаю а по вашей фразе «Иногда связанный код — это хорошо»
                                                        … поэтому вы предлагаете искусственно ограничить всех, внеся DI прямо в язык и CLR. Круто.

                                                        Кого я предлагал ограничить? Я поделился идеями добавить новый функционал и не пытался кого-то ограничить
                                                          +1
                                                          Я предлагаю добавить в «это» порядка.

                                                          Как добавление еще одной сущности добавляет порядка в существующие?


                                                          Во-первых, я не утверждал, а сделал предположение, а во-вторых, не по-вашему конкретному случаю а по вашей фразе «Иногда связанный код — это хорошо»

                                                          Да, хорошо, потому что не порождает технического долга.


                                                          Кого я предлагал ограничить?

                                                          Людей, которым нужно наследование, конструкторы, создание через new, динамические графы зависимостей — короче, все то, что вы предлагаете убрать в ваших "DI-типах".


                                                          А если вы только добавите, то не будет работать ваше же "хороший API будет сильно мешать его неправильному использованию или даже сделает это невозможным, так должны делать хорошие языки программирования", потому что "неправильные", по вашему мнению, использования останутся возможными.

                                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                        Самое читаемое