Они к constructor injection призывать начали относительно поздно. И это реально стало «поздно», потому что в целом это редко выполняется даже в рамках проектов под зонтиком spring.
Мое мнение, что если программист сам не пришел к тому, что инжект через конструктор безусловное благо, и продолжает ляпать инжект сеттерами, то никакие призывы ему не помогут. Это нужно просто осознать. То есть тут не проблема Спринга, как такового, я считаю.
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
Почему же «костыли»? Тулинг уже давно стал неотъемлемой составляющей разработки, времена «я буду смотреть код в блокноте» прошли (я надеюсь!), и сейчас рулит правило «нет тулинга — нет фреймворка». Ну, и я по-началу как раз пытался обеспечить себе такую «единую точку конфигурации», но в итоге пришел к выводу, что овчинка выделки не стоит. Особенно, если конфигурация в xml…
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?
Тогда ограничения фреймворка либо не помогут, либо будут настолько кабальными, чт придется брать другой фреймворк :) Да и часто ли такое надо? Спринг все же мейнстрим, должен подходить основной массе разработчиков, а у основной массы таких задач, как мне кажется, нет.
Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
То есть мы руками сделали то, что Спринг прекрасно делает автоматически, руководствуясь аннотациями? :) По-моему сомнительный профит…
но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.
Или java-конфиг, который более гибкий, нежели xml и более читаемый. Ну, и да, большинство людей за простоту, а что может быть проще написать Component над классом?
Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое)
Чем «добавленная обертка» лучше Java Based Configuration? Или чем лучше одной аннотации @_Component?
Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
В документации к Спрингу создатели сами призывают пользоваться constructor injection. А автоскан-то чем не угодил???
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
Какое «это»? С того момента, как я отказался в своих проектах от xml я еще ни разу не пожалел о своем решении, так что с моей точки зрения аннотации тут безусловное благо.
70 секунд??? У нас какие-то разные спринги, наверное. Голое приложение на простом спринге с jetty в качестве контейнера запускается буквально пару секунд и почти не жрет памяти. Голое приложение на спринг-буте запускается чуть дольше, но тоже в пределах, ну, пусть, 10 секунд, и жрет 15 метров памяти, или что-то около того. Не могу представить, что должно подниматься что бы это занимало 70 секунд…
Если ваше приложение на спринге взлетает дольше 30 секунд, то, сдается мне, дело явно не в том javaconfig у вас используется или xml… В общем экономия на спичках.
Это играло бы рояль, если контекст приходилось бы поднимать многократно, а разница в несколько даже секунд на старте приложения мало что значит, особенно если приложение призвано работать непрерывно в течение долгого времени.
Уверен, что вы не писали хорошие тесты на свой проект, вместо расширения существующего, вы переписывали все заново (потому что тяжело расширять или даже невозможно), а о качестве и речи быть не может (ну кроме ревью реквестов, и то не у всех).
Ковырните соседей по офису, запросто может обнаружится, что тот офигенный спец, который строит офигенный продукт, в девичестве имеет красный диплом по, скажем, экономике.
Мое мнение, что если программист сам не пришел к тому, что инжект через конструктор безусловное благо, и продолжает ляпать инжект сеттерами, то никакие призывы ему не помогут. Это нужно просто осознать. То есть тут не проблема Спринга, как такового, я считаю.
Почему же «костыли»? Тулинг уже давно стал неотъемлемой составляющей разработки, времена «я буду смотреть код в блокноте» прошли (я надеюсь!), и сейчас рулит правило «нет тулинга — нет фреймворка». Ну, и я по-началу как раз пытался обеспечить себе такую «единую точку конфигурации», но в итоге пришел к выводу, что овчинка выделки не стоит. Особенно, если конфигурация в xml…
Тогда ограничения фреймворка либо не помогут, либо будут настолько кабальными, чт придется брать другой фреймворк :) Да и часто ли такое надо? Спринг все же мейнстрим, должен подходить основной массе разработчиков, а у основной массы таких задач, как мне кажется, нет.
То есть мы руками сделали то, что Спринг прекрасно делает автоматически, руководствуясь аннотациями? :) По-моему сомнительный профит…
Или java-конфиг, который более гибкий, нежели xml и более читаемый. Ну, и да, большинство людей за простоту, а что может быть проще написать Component над классом?
Чем «добавленная обертка» лучше Java Based Configuration? Или чем лучше одной аннотации @_Component?
В документации к Спрингу создатели сами призывают пользоваться constructor injection. А автоскан-то чем не угодил???
Какое «это»? С того момента, как я отказался в своих проектах от xml я еще ни разу не пожалел о своем решении, так что с моей точки зрения аннотации тут безусловное благо.
Диагноз по фотографии?
Он в свое время знатно всех в twitter.com/backendsecret повеселил, тоже эту книжку все пиарил.
СМИ сами рады его пиарить, без всякого его участия.
Вот пока вам было «ясно» и «я догадался», Маск взял да сделал. Нужна — вот она, под рукой, не нужна — оставьте себе на следующий раз.
Отличайте уже пиар на пустой болтовне и заявлениях от реальной деятельности, пусть и оказавшейся бесполезной.