SE
А незнаешь есть ли какой-то микронавто подобный DI фреймворк - которые во время компиляции уже создает бины которые будут инджектится ?
знаю конечно. Dagger. И это просто ужасно
Size: a a a
2020 March 17
AA
А незнаешь есть ли какой-то микронавто подобный DI фреймворк - которые во время компиляции уже создает бины которые будут инджектится ?
Dagger?
SE
и вообще, микронавт - это Dagger подобный фреймворк, а не наоборот
VS
знаю конечно. Dagger. И это просто ужасно
Ужасно из-за тормозов компиляции?
SE
Ужасно из-за тормозов компиляции?
из-за всего. DX просто отвратный
VS
из-за всего. DX просто отвратный
Т.е. dagger2 это только тогда, когда нужно performance любой ценой?
SK
знаю конечно. Dagger. И это просто ужасно
Ужасна концепция или имплементация?
KT
Т.е. dagger2 это только тогда, когда нужно performance любой ценой?
Там даже не про перфоманс. Полагаю есть ниша в виде устройств где reflection медленный. Там даггер единственная возможность
SE
Ужасна концепция или имплементация?
Да.
SE
Т.е. dagger2 это только тогда, когда нужно performance любой ценой?
я в большой Java агент guice вместо dagger интегрировал, пифомансно было
VS
Там даже не про перфоманс. Полагаю есть ниша в виде устройств где reflection медленный. Там даггер единственная возможность
Вроде, я видел статью Google’а, где они говорили, что у них Spring DI занимал 30% cpu time от времени работы сервисов.
Во что я легко могу поверить, т.к. у нас подобный опыт был. Первый же prototype или .getBean в Spring’е это вообще адские тормоза.
Во что я легко могу поверить, т.к. у нас подобный опыт был. Первый же prototype или .getBean в Spring’е это вообще адские тормоза.
SE
Вроде, я видел статью Google’а, где они говорили, что у них Spring DI занимал 30% cpu time от времени работы сервисов.
Во что я легко могу поверить, т.к. у нас подобный опыт был. Первый же prototype или .getBean в Spring’е это вообще адские тормоза.
Во что я легко могу поверить, т.к. у нас подобный опыт был. Первый же prototype или .getBean в Spring’е это вообще адские тормоза.
так может просто не надо использовать прототипы и getBean?
SE
в современном коде их редко найдёшь
SE
ну и есть правило - не иметь DI в hot path
SE
(применимо к любому DI)
VS
так может просто не надо использовать прототипы и getBean?
Вроде не безельники и могли бы жить.
Им бы прототайпы Взять и запретить.
Им бы и getBean тоже запретить.
Вроде не бездельники и могли бы жить.
Так-то оно так. Но раз из Spring’а не выпилили, то рано или поздно в коде появляются эти самые запрещённые к использованию классы :(
Им бы прототайпы Взять и запретить.
Им бы и getBean тоже запретить.
Вроде не бездельники и могли бы жить.
Так-то оно так. Но раз из Spring’а не выпилили, то рано или поздно в коде появляются эти самые запрещённые к использованию классы :(
SK
Вроде не безельники и могли бы жить.
Им бы прототайпы Взять и запретить.
Им бы и getBean тоже запретить.
Вроде не бездельники и могли бы жить.
Так-то оно так. Но раз из Spring’а не выпилили, то рано или поздно в коде появляются эти самые запрещённые к использованию классы :(
Им бы прототайпы Взять и запретить.
Им бы и getBean тоже запретить.
Вроде не бездельники и могли бы жить.
Так-то оно так. Но раз из Spring’а не выпилили, то рано или поздно в коде появляются эти самые запрещённые к использованию классы :(
А вот запретишь прототайп, запретишь getBean, запретишь еще всякие спорные практики вроде инжекций не через конструктор, глядишь и не останется от спринга ничего.