Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
IMHO мало пользы от такого велосипеде написания. Как вариант обучения — дополнять Spring Framework, Spring Boot тестами. Это и пользу сообществу принесет и позволит глубже погрузиться в этот проект. Поверьте мне, что проекту нужна помощь сообщества и борьба с накопившимся за десятилетие техническим долгом.
Большое спасибо за отличный материал!
Не слушайте скептиков, делайте продолжение.
Не слушайте скептиков, делайте продолжение.
да, собственная реализация — отличный подход для понимания внутренностей чего-либо.
к сожалению, повторяя спринг без критического взгляда на его концептуальное устройства вы повторяете его со всеми присущими ему граблями, даже не задумываясь — типа, раз в спринге так сделано, значит так и надо делать :)
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
к сожалению, повторяя спринг без критического взгляда на его концептуальное устройства вы повторяете его со всеми присущими ему граблями, даже не задумываясь — типа, раз в спринге так сделано, значит так и надо делать :)
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
например, те же аннотации, которые команда спринга притащила, чтобы уйти от xml и протолкнула в j2ee и многие другие фреймворки, в итоге везде вокруг имеем это печальное зрелище
Какое «это»? С того момента, как я отказался в своих проектах от xml я еще ни разу не пожалел о своем решении, так что с моей точки зрения аннотации тут безусловное благо.
«Это» — использование аннотаций для решения любых фантазий, несмотря на то, что они жестко привязывают код к конкретной реализации контейнера, несмотря на то, что содержание аннотаций невозможно валидировать на этапе компиляции и тяжело рефакторить и т.д. и т.п.
Разумеется, повальное увлечение аннотациями началось раньше спринга, но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.
Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое) Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
Разумеется, повальное увлечение аннотациями началось раньше спринга, но благодаря спрингу теперь большинство людей просто в упор не видят альтернативы в области DI конфигурации. То есть или xml или аннотации, судя по вашему комментарию.
Самое смешное, что спринг внутри поддерживает вайринг неаннотированных классов. Добавить обертку для красоты, и можно пользоваться, создавая контейнер в чистом ява-коде (нет, Java Based Configuration — это не то же самое) Но изначальный выбор спринга в пользу member injection вместо constructor injection, а потом такая же вредная идея с автосканом компонентов создала, закрепила и распространила на все подпроекты спринга именно такой подход.
Не совсем понял аргументацию, если честно.
Или java-конфиг, который более гибкий, нежели xml и более читаемый. Ну, и да, большинство людей за простоту, а что может быть проще написать Component над классом?
Чем «добавленная обертка» лучше Java Based Configuration? Или чем лучше одной аннотации @_Component?
В документации к Спрингу создатели сами призывают пользоваться 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, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?
Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
Они к constructor injection призывать начали относительно поздно. И это реально стало «поздно», потому что в целом это редко выполняется даже в рамках проектов под зонтиком spring.
Мое мнение, что если программист сам не пришел к тому, что инжект через конструктор безусловное благо, и продолжает ляпать инжект сеттерами, то никакие призывы ему не помогут. Это нужно просто осознать. То есть тут не проблема Спринга, как такового, я считаю.
Автоскан оставляет вас без единой точки конфигурации, чем сложнее проект, тем тяжелее вам понять как взаимосвязаны компоненты, что находится в контексте, а что нет. Приходится использовать костыли IDE.
Почему же «костыли»? Тулинг уже давно стал неотъемлемой составляющей разработки, времена «я буду смотреть код в блокноте» прошли (я надеюсь!), и сейчас рулит правило «нет тулинга — нет фреймворка». Ну, и я по-началу как раз пытался обеспечить себе такую «единую точку конфигурации», но в итоге пришел к выводу, что овчинка выделки не стоит. Особенно, если конфигурация в xml…
А если у вас не один контекст на приложение, а множество динамически создаваемых иерархических контейнеров разграничивающих области видимости?
Тогда ограничения фреймворка либо не помогут, либо будут настолько кабальными, чт придется брать другой фреймворк :) Да и часто ли такое надо? Спринг все же мейнстрим, должен подходить основной массе разработчиков, а у основной массы таких задач, как мне кажется, нет.
Под оберткой я имел в виду один единственный класс агрегирующий beanFactory, и позволяющий добавлять в контекст неаннотированные классы. В итоге вы можете в одном месте на чистом ява-коде описать весь контейнер.
То есть мы руками сделали то, что Спринг прекрасно делает автоматически, руководствуясь аннотациями? :) По-моему сомнительный профит…
Спасибо за статью! Немного напоминает творения Борисова потрошителя, но все равно здорово. Ждём продолжения!
Интересный материал и метод преподнесения, плюсанул бы но карма не позволяет).
Хотелось бы продолжения серии статей.
Спасибо за труд.
Хотелось бы продолжения серии статей.
Спасибо за труд.
Автор, выражаю огромную благодарность за такое оформление и подачу материала!
Было очень интересно узнать, что в Spring находится под капотом простым и понятным языком. С нетерпением жду следующей статьи.
Было очень интересно узнать, что в Spring находится под капотом простым и понятным языком. С нетерпением жду следующей статьи.
Отличная статья, жду продолжения
Да было интересно. Спасибо. Ждем продолжения.
Большое спасибо. Я примерно представлял как оно работает, но не думал что всё настолько просто.
Спасибо! Очень интересно!
Спасибо за статью, очень вовремя, я как раз собирался написать spring-compatibility либу для своего фреймворка, очень поможет начать
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Реализация Spring Framework API с нуля. Пошаговое руководство для начинающих. Часть 1