Comments 11
У меня возникло несколько вопросов:
- генерация кода, за счет чего она работает? Это Incremental Source Generator в основе или что-то другое?
- я для своих проектов, использую Jab для DI. Знакомы ли Вы с этой библиотекой? В чем принципиальные различия с Pure.Di? Какие преимущества и недостатки есть в сравнении? Почему мне стоит попробовать Pure.Di, если я пользователь Jab к примеру?)
Да, это генератор кода на основе .NET Incremental Generators и идея Pure.DI похожа на Jab, но много различий в деталях.
Jab – это все вокруг IServiceProvider, Pure.DI не привязан ни к чему
Jab – использует атрибуты для метаданных, в Pure.DI использует и атрибуты, но самое главное основной API Pure.DI похож на обычные DI контейнеры
В Jab на сколько я понял каждую зависимость нужно регистрировать атрибутом, что не очень удобно, в Pure.DI нужно определить только корни или привязки абстракций и все работает само
В Jab при построении композиции объектов везде используются вызовы GetService<T>(), это не хорошо по производительности
В связи с подходом из предыдущего пункта нет эффективного способа реализовать такие времена жизни PerResolve или PerBlock, которые очень удобны
В Jab нет эффективных фабрик как такое
Те фабрики что есть - не очень эффективны, например вот такие фокусы сделать невозможно
В Jab плохая работа с обобщёнными типами
Он не потокобезопасен, на сколько я понял
Нет множества полезны фич такие как аргументы композиции/корней
Нет возможности сделать лямбды с параметрами как такое
Нет настроек генерации кода как такие подсказки
Я не понял как там делать перехват как это или декоратор как этот
Я не понял, как там внедрять реализации по ключу - может быть не доделано еще
Там не поддерживаются BCL (Lazy, IList ...) и другие типы из коробки, я уже и не говорю про создание Span на стеке))
Нет возможности из коробки внедрять Func<> что бы создавать столько инстансов сколько нужно
и много другого
Jab - это генератор DI "на минималках", но многим его возможностей вполне достаточно, мне нет))
Не много не в тему, но интресно узнать, а какая у вас мотивация заниматься open source проектом подобным этому?
Opensource - для меня возможность изучать инструменты, с которыми работаю. А если они приносят кому-то пользу, то в двойне приятно)) Конкретно это проект мне нравится, так как на мой взгляд DI это основа основ надежных и дешевых в поддержке и доработке приложений.
Глядя на функциональность Incremental Generators, выглядит так что было бы вполне легко реализовать что-то типа greasemonkey для браузеров.
Такой подход будет сложно реализовать, так как анализируется не только исходный код, но и все бинарные зависимости. Плюс слишком много событий когда нужно будет перестраивать код –будет не удобно. Я не уверен, что до конца понял вашу мысль про greasemonkey.
Хотел одно время написать, но с приходом этой движухи с ИИ не понятно, нужно ли вообще суетиться.
Думал в направлении подключить какой-нибудь ИИ, но у меня не много в этом опыта и кажется производительность анализа графа может быть не высокой, а результат сложно прогнозировать.
Кстати думаю что в ваш проект можно analyzer добавить - который бы отлавивал стандартные ошибки использования вашего продукта, анализатор от генератора почти не отличается, а удобства использования повысит.
Да стандартные ошибки отлавливаются и указывается место и рекомендации к исправлению. Самая главная идея - все ошибки на этапе компиляции, на этапе выполнения все должно работать как задумано - ни каких исключений. Если ошибки находятся, то код не скомпилировать
Реализовать не сложно, пара функций это сбилдить dll из исходника и этот dll загрузить
Нужны и все зависимости
В этом случае
void Setup() => DI.Setup(nameof(Composition))
.Root<FormMain>("FormMain")
.Bind<IClockViewModel>().As(Singleton).To<ClockViewModel>()
.Bind<IClockViewModel>().As(Singleton).To<ClockViewModel>();на этапе компиляции будет предупреждение от том что привязка была перегружена, например:
Composition.cs(23,51): Clock.ViewModels.IClockViewModel has been overridden.
т.е. забыли Bind для IClockViewModel
Программа не упадет на запуске (если специально не включить флаг для игнора невозможности определить зависимость для внедрения). Сначала будет проверена корректность графа зависимостей, если что то не так, то мы увидим проблему на этапе компиляции. Если даже что то пойдет не так, например ошибка в генераторе, то код сгенериться не верно и его проверит компилятор. И проверку плохой код не пройдет и опять остановится на этапе компиляции. До запуска бинарника программы просто не дойдет, потому что не будет этого бинарника. Или я вас не правильно понял ))
Например, закомментируйте эту строку. Ошибка компиляции будет такой:
FormMain.cs(11, 39): Unable to resolve "Clock.ViewModels.IClockViewModel" in FormMain(Clock.ViewModels.IClockViewModel clockViewModel<--Clock.ViewModels.IClockViewModel)).
Если в IDE перейти по ошибке то он укажет на параметр IClockViewModel clockViewModel в конструкторе класса FormMain. Т.е. программа конечно не скомпилируется и бинарника, который можно запустить у вас не будет.
Pure.DI v2.1