Введение в Spring, или что делать, если по всему проекту @Autowired и @Component, а вы не понимаете, что это

[shapovalex]

В принципе неплохая статья, если бы не два но:
1. XML. Опять XML. Который устарел уже несколько лет назад и довольно сложен для понимания. К тому же дикая связь с annotation config.
2. Инъекция в приватные поля сильно затрудняет юнит тестирование.
Приходится применять ReflectionTestUtils и другие хаки. Лучше все-же использовать инъекцию через конструктор. Последние версии спринга прекрасно умеют инжектить в конструктор даже без аннотации Autowired на нем

[sshikov]

Ну, вообще-то xml может быть изменен в runtime (никто не мешает создать контекст налету, сформировав сначала кучку xml). Что до аннотаций, то это возможность времени компиляции. Так что насчет устарел я бы не был так категоричен. У них несколько разные возможности, и иногда XML может быть полезен. Да, это сильно нетипичное применение, и потенциально небезопасное к тому же.

Сложен для понимания? Ну не знаю, мне — нет, вероятно дело привычки. Поддержка со стороны IDEA только в Ultimate версии, это да, не очень удобно. Ну то есть, если это текст для начинающих, иметь представление что XML контексты бывают — это полезно.

Мне вот другое любопытно. Спрингу сто лет в обед. Autowired там появились кажется примерно в тоже время, что и JavaEE 6, т.е. лет 10 назад. Ресурсов на эту тему в интернете куча, в том числе на русском. Эта тема тут реально кому-то интересна?

[oponomarev]

Можете привести пример из практики, когда в продакшене приходилось пересоздать контекст, не модифицируя при этом код?

[sshikov]

В контексте много чего бывает, кроме бинов, которые пожалуй единственные завязаны на код. Данные, коннекты к базам и JMS, как самые очевидные примеры. В моей практике — camel routes, много раз. И не только пересоздать, а и создать новый, еще один.

[sshikov]

Зависит от проекта. Причем от версии спринга скорее не зависит. У меня опыта с этим фреймворком с 2005 года примерно, и тогда просто не было никаких других контекстов, кроме XML — но желания загрузить контекст в рантайме не возникало, хотя я и тогда знал, как это делается. Не было потребности.

А были проекты, где примерно треть контекстов вот так вот грузилась время от времени.

Опять же — я не призываю так делать, были вполне живые эксплойты на такую тему, вполне очевидно, что это позволяет выполнять фактически произвольный код, если разработчик был неаккуратен. Я просто ради того, чтобы понимать, где средства компиляции, а где рантайм.

[Samuil9999]

Да.

[Raspy]

1. Можно без xml. Вместо ClassPathXmlApplicationContext берёте AnnotationConfigApplicationContext и в качестве аргумента передаёте в него класс, помеченный аннотацией @Configuration
2. Совершенно наоборот. При тестировании вы легко используете тестовый апликейшен контекст, в котором могут быть реализованы мокированные объекты, необходимые для тестов и инъекция будет абсолютно прозрачной.

[pomazkina]

В черновой версии статьи я упоминала и про AnnotationConfigApplicationContext, но потом решила, что не стоит превращать статью в простыню и про виды контекста рассказать в следующий раз, если будет спрос.

[Throwable]

Создать сеттер и с помощью его вызова устанавливать продавцу магазин:

Это заведомо плохое решение, т.к. сразу позволяет создавать "ненастроенные" объекты как продавец без магазина. Сеттеры еще можно использовать для опциональных полей, но для обязательных — т.е. тех, при которых объект не будет работать — лучше использовать конструктор и final-поля. Именно он, собственно, и задают dependencies.

И, наконец, мы подобрались к спрингу: он предоставляет еще один способ внедрять зависимости.

А это самый быстрый и самый плохой способ. Все ваши объекты становятся въявную завязанными на контейнер и без него уже не способны работать. Ни протестировать нормально ни переиспользовать потом.

Возможно вы сейчас думаете, зачем все эти сложности. Но представьте, что у нас приложение не из 2 классов, а на несколько порядков больше и управление зависимостями уже становится не самой тривиальной задачей.

Уж поверьте, еще более нетривиальной задачей это становится со спрингом. Особенно когда в проекте несколько разрабов. Когда все внеявную завязано на текущих настройках и умолчаниях, любое изменение либо не тупо работает, либо что-то рушит. Поэтому типичный проект на спринге связывает не более десятка бинов, и используют его совсем не из-за DI, а из-за легкого бутстрапа различных технологий из коробки.

Если нужен DI, возьмите Guice.

[manulus]

Эта статья поможет вам взобраться на самую первую ступеньку: понять общую идею столь популярного фреймворка.

Из статьи не понял ни что такое Spring ни для чего он нужен и как помогают эти зависимости.