OK
было бы интересно проанализировать, сам разрабатываю несколько проектов, на одном DI, на другом не DI, если честно в какой-то момент уже и не ощущаю нигде преимуществ..
Size: a a a
2017 December 26
SK
Где что напрягает?
OK
там где DI - тесты долго запускаются, написал тест, фиксишь баг, часто запускаешь, а он не мгновенно стартует, в отличии структуры на конструкторах
SK
Oleg Kabanov
там где DI - тесты долго запускаются, написал тест, фиксишь баг, часто запускаешь, а он не мгновенно стартует, в отличии структуры на конструкторах
Долго запускаются из-за чего?
OK
там где структура без DI - напрягает, что нет стандартизации, код разношёрстный, может это от проекта зависит
OK
долго из-за инициализации контекста
SK
Oleg Kabanov
там где структура без DI - напрягает, что нет стандартизации, код разношёрстный, может это от проекта зависит
А какой стандартизации вы ожидаете? Java Lang чем не стандарт?)
SK
SK
Я кажется понял
SK
Интересное решение кстати видел на этот счет, не пробовал правда пока
MB
подход интересный, но честно говоря упирается в аннотации и нейминги, что не есть гуд
MB
Oleg Kabanov
долго из-за инициализации контекста
spring-test вроде lightweight контекст поднимает
SK
Разве? Мне казалось там для всего есть, не только для аннотаций
MB
беглым взглядом я увидел только это + проверка связей между классами/пакетами + возможность задания кастомных правил
MB
насчет DI - я тут вот что считаю, ничто не мешает DI делать вручную, но как мне кажется, главный плюс DI фреймворков(а я сейчас именно про спрингу) в том, что очень много фич предоставляется используя DI context и аспекты
MB
исторически это ж вообще концепция из ejb прилетела, что дескать мы определяем бизнес логику, а все остальное - типа транзакции, секурность и т.д. как перпендикулярные аспекты
MB
только там выродилось все это в какой-то звездец
SK
Да фактически весь энтерпрайз далеко от процедурного программирования не ушел. Что есть сервис, если не набор обычных процедур, обменивающихся между собой данными-DTOшками?