Pull to refresh

Comments 17

IMHO мало пользы от такого велосипеде написания. Как вариант обучения — дополнять Spring Framework, Spring Boot тестами. Это и пользу сообществу принесет и позволит глубже погрузиться в этот проект. Поверьте мне, что проекту нужна помощь сообщества и борьба с накопившимся за десятилетие техническим долгом.
Как раз после «прохождения» этой статьи у разработчика уйдет неверное представление о монструозности спринга, и у него может появиться желание и смелость помочь реальному проекту.
Статья отличная!
Большое спасибо за отличный материал!
Не слушайте скептиков, делайте продолжение.
да, собственная реализация — отличный подход для понимания внутренностей чего-либо.
к сожалению, повторяя спринг без критического взгляда на его концептуальное устройства вы повторяете его со всеми присущими ему граблями, даже не задумываясь — типа, раз в спринге так сделано, значит так и надо делать :)

например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище

Какое «это»? С того момента, как я отказался в своих проектах от xml я еще ни разу не пожалел о своем решении, так что с моей точки зрения аннотации тут безусловное благо.
«Это» — использование аннотаций для решения любых фантазий, несмотря на то, что они жестко привязывают код к конкретной реализации контейнера, несмотря на то, что содержание аннотаций невозможно валидировать на этапе компиляции и тяжело рефакторить и т.д. и т.п.

Разумеется, повальное увлечение аннотациями началось раньше спринга, но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.

Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое) Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
Не совсем понял аргументацию, если честно.
но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.

Или java-конфиг, который более гибкий, нежели xml и более читаемый. Ну, и да, большинство людей за простоту, а что может быть проще написать Component над классом?

Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое)

Чем «добавленная обертка» лучше Java Based Configuration? Или чем лучше одной аннотации @_Component?

Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.

В документации к Спрингу создатели сами призывают пользоваться constructor injection. А автоскан-то чем не угодил???
Они к constructor injection призывать начали относительно поздно. И это реально стало «поздно», потому что в целом это редко выполняется даже в рамках проектов под зонтиком spring.

Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?

Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
Они к constructor injection призывать начали относительно поздно. И это реально стало «поздно», потому что в целом это редко выполняется даже в рамках проектов под зонтиком spring.

Мое мнение, что если программист сам не пришел к тому, что инжект через конструктор безусловное благо, и продолжает ляпать инжект сеттерами, то никакие призывы ему не помогут. Это нужно просто осознать. То есть тут не проблема Спринга, как такового, я считаю.

Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.

Почему же «костыли»? Тулинг уже давно стал неотъемлемой составляющей разработки, времена «я буду смотреть код в блокноте» прошли (я надеюсь!), и сейчас рулит правило «нет тулинга — нет фреймворка». Ну, и я по-началу как раз пытался обеспечить себе такую «единую точку конфигурации», но в итоге пришел к выводу, что овчинка выделки не стоит. Особенно, если конфигурация в xml…

А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?

Тогда ограничения фреймворка либо не помогут, либо будут настолько кабальными, чт придется брать другой фреймворк :) Да и часто ли такое надо? Спринг все же мейнстрим, должен подходить основной массе разработчиков, а у основной массы таких задач, как мне кажется, нет.

Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.

То есть мы руками сделали то, что Спринг прекрасно делает автоматически, руководствуясь аннотациями? :) По-моему сомнительный профит…
Спасибо за статью! Немного напоминает творения Борисова потрошителя, но все равно здорово. Ждём продолжения!
Интересный материал и метод преподнесения, плюсанул бы но карма не позволяет).
Хотелось бы продолжения серии статей.
Спасибо за труд.
Автор, выражаю огромную благодарность за такое оформление и подачу материала!
Было очень интересно узнать, что в Spring находится под капотом простым и понятным языком. С нетерпением жду следующей статьи.
Да было интересно. Спасибо. Ждем продолжения.

Большое спасибо. Я примерно представлял как оно работает, но не думал что всё настолько просто.

Спасибо за статью, очень вовремя, я как раз собирался написать spring-compatibility либу для своего фреймворка, очень поможет начать

Sign up to leave a comment.

Articles