IC
я просто хочу понять. появится ли суррогатный тип CompositionRoot
var aCykaBliat = new B(new A(new MetricCollector()));
aCykaBliat.RandomShitGo();
будет как то так?
Size: a a a
2021 April 06
IC
будет как то так?
R
Но ебтвою мать, если мы примитивный код инициализации объекта хотим заменить простыней регистраций, чтобы потом ебать себе мозги лайфтаймом, скоупом, багами в рантайме и все это с помощью нетривиального фреймворка с магией рефлексии, экспрешшнов и небось теперь сорсгенераторов — наъуй это надо а?
IC
это нахуй не надо в калькуляторах, я уже писал
R
var metricCollector = new MetricCollector();
var ololo = new MockOlolo();
var a = new A(metricCollector, ololo);
var b = new B(a);
b.DoWork();
I
Это глобальный спор DI vs не-DI?
R
да! Милости прошу к нашему шалашу
R
это нигде не надо
I
Тогда я ворвусь сюда с блейзор-компонентами и спрошу как там без DI обойтись? :D
IC
тогда заинжекти мне коллекцию
IMetricColletor, чтобы одну из её реализаций можно было написать отдельноR
за блезор ничего не знаю
I
Но думаю что ответ либо никак, либо наверное через такую боль, что ну нахер.
I
Мне кажется что выбор фреймворка в общем и целом ставит все точки над DI/не DI, разве нет?
I
Если фреймворк заточен под определённый стиль работы с зависимостями, то смысл плыть против течения?
оГ
I - заглавная. Точка над ней не нужна!
R
хз про блезор. Мы в некоторых местах тоже вынуждены использовать DI, пушто там майкрософт любезно все прибил гвоздями к нему, сверху щедро полив эпоксидкой. Но тут проблема в МС и его инфре и сдк, а не в том, что DI концептуально какую-то важную проблему решает
R
например, в ажуре и кое-где в аспнете
I
Т.е. у тебя AspNetCore - это DI 100% и ничего ты не сделаешь иначе (ну или через борьбу). Если у тебя какой-нибудь Giraffe, то вроде можно и обойтись (но я не пробовал)
IC
@atsapura довай пример!
KF
во во, а мой скриншот с красивой регистрацией захейтили!