DZ
Кстати вот пишу на флаттер время от времени, там недавно появилась либа injectable вдохновлённая ангуляром
Size: a a a
2020 March 03
DZ
Правда во флаттере нет рефлексии (в дарте есть, через мирроры) но в injectable это реализуется через кодогенерации на основе декораторов
DZ
AoT DI )
MY
кстати в динамические модули терь можно и импорты передавать норм выходит
А разве так не всегда было?
IK
А разве так не всегда было?
давным давно не получалось такое, там не было imports
OR
Инверсия зависимости нужна для того, чтобы выскоуровневые политики не заисили от низкоуровневых (т.е. например, бизнес-логика не зависела от отображения). Фактически нужно избавиться от прямых импортов низкоуровневых политик внутри высокоуровневых политик. Это даёт DI. Но ‘нормальный’ DI должен быть построен на интерфейсах, nest же предлагает по умолчанию DI на типах классов, которые мы импортим откуда? из реализации. Т.е. наши зависимости остаются не развернутыми.
Аминь! Пропагандируемый официально способ инжекта – днище, как по мне лучше использовать
@Inject(someToken), тогда и не стыдно будет в глаза роберту мартину на питерском холи смотретьOR
А разве так не всегда было?
в 6.0.0 точно завезли
KA
Инверсия зависимости нужна для того, чтобы выскоуровневые политики не заисили от низкоуровневых (т.е. например, бизнес-логика не зависела от отображения). Фактически нужно избавиться от прямых импортов низкоуровневых политик внутри высокоуровневых политик. Это даёт DI. Но ‘нормальный’ DI должен быть построен на интерфейсах, nest же предлагает по умолчанию DI на типах классов, которые мы импортим откуда? из реализации. Т.е. наши зависимости остаются не развернутыми.
Ну можно же провайдить и импортировать абстрактные классы вместо интерфейсов и тогда мы подходим близко к тому о чем ты говоришь
AM
Ну можно же провайдить и импортировать абстрактные классы вместо интерфейсов и тогда мы подходим близко к тому о чем ты говоришь
да, можно. Но документация так не учит — это плохо.
KA
да, можно. Но документация так не учит — это плохо.
Тут согласен
GS
да, можно. Но документация так не учит — это плохо.
это уже обсуждалось на гитхабе?
AM
это уже обсуждалось на гитхабе?
Не искал. Но Камиль изначально был против усложнения, в итоге сейчас мы получим разработчиков, которые воспринимают DI просто как способ удобно забрасывать зависимости и не задумываются про направления связей. Индустрию это не продвинет вперёд.
DZ
Инверсия зависимости нужна для того, чтобы выскоуровневые политики не заисили от низкоуровневых (т.е. например, бизнес-логика не зависела от отображения). Фактически нужно избавиться от прямых импортов низкоуровневых политик внутри высокоуровневых политик. Это даёт DI. Но ‘нормальный’ DI должен быть построен на интерфейсах, nest же предлагает по умолчанию DI на типах классов, которые мы импортим откуда? из реализации. Т.е. наши зависимости остаются не развернутыми.
++
DZ
Можно сделать так, interface SomeService и потом SomeServiceImpl implements SomeService
Далее provide SomeService useClass SomeserviceImpl
Далее provide SomeService useClass SomeserviceImpl
DZ
Типа того должно работать вроде
KA
Можно сделать так, interface SomeService и потом SomeServiceImpl implements SomeService
Далее provide SomeService useClass SomeserviceImpl
Далее provide SomeService useClass SomeserviceImpl
вот именно, что нет. вместо этого как раз абстрактные классы
DZ
На ангуляре стопудов работает
DZ
В несте не проверял
DZ
Но должно по идее
DZ
Да как по мне не велика проблема тут, тк сервисы простые часто