Как можно связать бины

Обновлено: 19.04.2024

Dependency Injection (внедрение зависимостей) – ключевой шаблон проектирования в Spring. Мы говорим фреймворку создать за нас бины (иначе говоря — объекты) и внедрить их в другие бины. И фреймворк это делает.

Но как объяснить фреймворку Spring, что такой-то бин должен стать зависимостью для другого бина? Вариантов немного, а самых частых всего два: бин внедряется либо через конструктор класса, либо с помощью сеттера. Первое называется constructor-based injection, а второе — setter-based injection.
В этой статье мы создадим бин Engine и будем внедрять его в два других бина: в бин CarWithConstructor с помощью конструктора и в CarWithSetter с помощью сеттера.

Конфигурация Maven

Чтобы начать работу с бинами, необходимо добавить в pom.xml зависимость:

Определим классы. Итак, сначала у нас есть три класса. Класс Engine:

Класс CarWithConstructor с конструктором:

И класс CarWithSetter с сеттером:

Чтобы внедрить бин, классов нам недостаточно, Spring имеет дело с бинами, а не классами. Поэтому нужно сконфигурировать эти классы так, чтобы Spring контейнер создал на их основе бины. В конфигурации заодно будут заданы и pзависимости. Конфигурировать бины можно либо с помощью аннотаций, либо с помощью XML. (Но учтите, что XML-конфигурация немного устарела.)

Конфигурация бинов с помощью аннотаций

До того как внедрять бин engine, давайте его определим:

Аннотация @Component говорит фреймворку превратить класс в бин. При запуске Spring создаст экземпляр класса Engine. Этот экземпляр будет синглтоном в нашем случае. Мы сможем его впоследствии получить из контекста приложения с помощью команды:

И он будет внедрен во все бины, где мы зададим его в качестве зависимости. Неважно каким способом – через конструктор или сеттер.
Давайте зададим пакет, в котором хранятся бины, чтобы Spring знал, где их искать. Это делается с помощью аннотации @ComponentScan:

Обычно в классе Config прописываются конфигурации, но в нашем простом приложении он пуст.

В пакете «ru.javalang.injection» Spring будет искать аннотированные с помощью @Component классы, чтобы превратить их в бины при запуске приложения и инициализации контейнера Spring.
Итак, мы определили один бин engine. Теперь можно его внедрять в другие бины. Конечно, эти другие бины тоже надо сконфигурировать. И внутри конфигурации задать зависимости (dependency injection).

Constructor Based Injection

Если в классе есть конструктор, то можно внедрить зависимость через конструктор. При создании класса контейнер Spring вызовет конструктор и передаст зависимость в качестве аргумента конструктора.
Давайте определим бин CarWithConstructor и внедрим в него бин Engine с помощью конструктора:

Аннотация @Component означает, что класс CarWithConstructor надо зарегистрировать в качестве бина.
А аннотация @Autowired перед конструктором говорит фреймворку внедрить бин engine в качестве зависимости в бин CarWithConstructor.
Обратите внимание, что начиная с версии Spring 4.3 аннотацию @Autowired можно опустить, если у класса всего один конструктор. О том, что в конструкторе надо внедрить бин, фреймворк догадается сам.

Setter Based Injection

Если в классе задан сеттер, то зависимость можно внедрить и через него. Тогда при создании экземпляра класса контейнер вызовет конструктор без аргументов, а потом сеттер, чтобы внедрить зависимость во только что созданный бин.
Определим бин CarWithSetter и внедрим в него бин engine с помощью сеттера.
Для этого используем перед сеттером аннотацию @Autowired:

Так же, как в предыдущем случае, аннотацию @Autowired перед сеттером можно опустить.
Более того, можно опустить и сеттер. И просто аннотировать поле engine:

И внедрение зависимости все равно произойдет. Несмотря на то, что тут нет ни конструктора, ни сеттера, а поле engine имеет модификатор private. Это возможно, потому что под капотом фреймворк использует рефлексию для создания бинов. (Но такой вариант (field-based dependency injection) не рекомендуется).

Чтобы получить экземпляры машин, надо обратиться к контексту приложения:

Переменная carWithConstructor будет иметь ненулевую ссылку на engine. Хотя мы не создавали ни один объект с помощью оператора new. Все бины создал фреймворк и добавил ссылки на зависимости там, где они были определены.
Обратите внимание, что все бины у нас синглтоны, и обе переменные carWithConstructor и carWithSetter ссылаются на один и тот же engine. Синглтон — самый частый жизненный цикл бина.

Конфигурация бинов с XML

А теперь сконфигурируем все то же самое с помощью XML:

Тег bean задает бин, это аналог аннотации @Component.

Constructor Based Injection

Вот часть вышеприведенного XML, которая определяет бин CarWithConstructor:

Тут constructor-arg определяет внедрение зависимости с помощью конструктора.
Атрибут ref содержит ссылку на идентификатор бина engine.

Setter-Based Injection

А это часть вышеприведенного XML, которая задает бин CarWithSetter:

Здесь тег property задает внедрение зависимости с помощью сеттера.
Обратите внимание, что если мы конфигурируем бины с помощью XML, то задать сеттер в классе необходимо. Иначе будет выброшено исключение. Потому что все послабления в конфигурациях пришли с аннотациями, с XML все гораздо строже.
За контекст, созданный с помощью XML, отвечает другой класс:

Бин из XML-контекста получаем аналогично:

Убедимся, что engine внедрен:

Какой способ внедрения зависимости лучше

Для разработчика большой разницы нет. В документации рекомендуется отталкиваться от класса – его структуры и цели. Если зависимость обязательна в данном классе, то логичнее это поле передавать в конструкторе. А значит это будет внедрение через конструктор. Соответственно если какая-то зависимость необязательна, то внедряем ее через сеттер.

Код примера есть на GitHub.

Способы внедрения зависимостей (Dependency Injection) в Spring: 6 комментариев

Большое спасибо вам за ваши статьи. Все очень коротко, ястно и лаконично объясняется…Однозначно лучше чем любой видео-урок на ютубе.

Спасибо, будем продолжать). Правда, как раз хочу записать краткие видео-уроки.

Огромная благодарность Автору статей по Spring, это самые ясные и лаконичные разъяснения работы фреймворка, которые я нашел!
Искренне Ваш, Yustas

«Более того, можно опустить и сеттер. И просто аннотировать поле car:» Кажется здесь ошибка, имелся ввиду не car а engine? И пример кода не тот.

Для подключения компонентов Spring используются два подхода: конфигурация XML и класс Java. Привязка может быть выполнена вручную путем настройки XML- файлов или с помощью классов Java. Также можно позволить Spring выполнить привязку на основе нескольких спецификаций.

Основная цель этой статьи – показать, как компоненты Spring могут быть привязаны с помощью двух упомянутых выше подходов.

Для чего используется фреймворк Spring?

Spring Framework - это одна из популярных сред разработки приложений, которая имеет следующие преимущества:

Использование только нужных модулей.
Spring предлагает множество различных пакетов и классов. А также позволяет использовать только нужные из них.
Возможность применения других технологий .

Spring использует другие технологии: фреймворки логов, ORM, таймеры Quartz, JEE и JDK и другие.

Компактность
Контейнер Spring легче по сравнению с контейнером EJB. Он развертывать приложения на основе Spring на маломощных компьютерах.
Гибкая система управления транзакциями
Интерфейс управления транзакциями Spring может использоваться обработки как глобальных транзакций (Java Transaction API), так и локальных транзакций (в одной базе данных).

Что такое привязка бинов?

Когда запускается программное приложение, совместно работают сразу несколько объектов (бинов). Также они могут использоваться независимо от других объектов.

Чтобы заставить бины работать вместе, их связывают через введение зависимостей в Spring (привязки). Когда запускается приложение на основе Spring, контекст приложения загружает определения компонентов или объектов из файла конфигурации и связывает их вместе.

Существует два подхода к привязке bean-компонентов в среде Spring:

Привязка через XML.
Привязка через классы Java.

Что такое автоматическая привязка?

Существует два способа привязки bean-компонентов в среде Spring:

Вручную, объявив bean-компоненты с помощью Dependency Injection (DI)
Позволить контейнеру Spring самостоятельно связать необходимые компоненты.

Последний способ известен как автоматическая привязка. При этом контейнеру Spring нужно указать, как он должен их связывать:

byName: контейнер Spring ищет бины, для которых в файле конфигурации XML для атрибута auto wire установлено значение byName.
byType: контейнер ищет бины, для которых в файле конфигурации XML для атрибута auto wire установлено значение byType.
constructor: выполняется поиск бинов, для которых для атрибута auto wire установлено значение constructor.
autodetect: способ автоматического подключения - через конструктор. Если он не работает, автоматическое подключение выполняется через параметр byType.

Что такое привязка через Java и XML?

Подключение bean-компонентов Spring может выполняться через классы Java и с помощью конфигурации XML. В этом разделе мы рассмотрим оба варианта:

XML: Подключение выполняется в файле конфигурации XML. Он содержит определения bean-компонентов. Когда запускается приложение, бины вызываются с помощью Dependency Injection (DI). В файле конфигурации необходимо объявить элемент и использовать элементы , .
Классы Java: Необходимо создать класс Spring Configuration и аннотировать класс @Configuration. Класс @Configuration сообщает Spring, что bean-компоненты, которые должны быть подключены и настроены в этом классе.

Настройка среды

Настройка среды для разработки приложений Spring, включает в себя всего три основных шага.

Настройка Java Development Kit
Загрузите JDK с официального сайта Oracle, а затем установите и настройте его. После этого необходимо задать переменные среды PATH и JAVA_HOME.
Настройка Eclipse IDE
Eclipse можно скачать с официального сайта . После завершения загрузки распакуйте двоичные файлы, а затем установите PATH.
Настройка библиотек Spring
Spring можно скачать здесь . Важно правильно установить CLASSPATH.

Пример приложения

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

Подключение через аннотации - у нас будет три класса Java, как показано ниже.

Листинг 1: Класс бина

В следующем классе для информирования контейнера Spring о том, что будет загружен beanWire, используются две аннотации. Аннотация @Configuration сообщает контейнеру Spring, что этот класс является источником определений бина.

Листинг 2: Класс конфигурации Bean с аннотациями

Ниже приведен последний класс для запуска приложения.

Листинг 3: Основной класс для запуска приложения

Когда эта Java-программа будет выполнена, она выдаст следующий результат.

Теперь рассмотрим, как привязывать бины через XML-файл.

Привязка через XML-файл: У нас будет два Java-файла и один XML-файл конфигурации.

Java-класс бина практически аналогичен предыдущему.

Листинг 1: Файл бина

Это XML-файл конфигурации.

Листинг 2: Конфигурационный XML-файл.

Это файл для получения компонента из XML-файла конфигурации и вызова методов.

Листинг 3: Основной Java-файл.

Запустите приложение, и оно выдаст следующий результат.

Заключение

Автоматическая привязка требует осторожности. Не все привязки могут выполняться с помощью автоматического подключения. Оно не подходит для сложных привязок, и это следует учитывать.

Дайте знать, что вы думаете по данной теме в комментариях. За комментарии, лайки, дизлайки, отклики, подписки низкий вам поклон!

Пожалуйста, опубликуйте свои мнения по текущей теме материала. За комментарии, лайки, подписки, дизлайки, отклики огромное вам спасибо!

Вадим Дворников автор-переводчик статьи « Learn How to wire Spring Beans by using XML and Java classes »

Неделя Spring на Хабре, судя по всему, открыта. Хочется сказать спасибо переводчику и комментаторам статьи "Почему я ненавижу Spring", которая не смотря на сильный негативный посыл в названии вызвала ряд интересных дискуссий, а так же тем, кто отреагировал на мою прошлую статью Как писать на Spring в 2017. Во многом благодаря комментариям к прошлой статье и появилась эта.

В этот раз мы погрузимся в пучины Spring фреймворка, разоблачим его магию, посмотрим как базовое веб приложение выглядит изнутри, и разберемся, какую-же задачу и как решает Spring Boot.

В комментариях к предыдущей статье несколько человек очень справедливо указали, что пример Hello World-а на Spring все же не очень показателен. Spring, особенно с использованием Spring Boot, дает ощущение простоты и всемогущества, но непонимание основ и внутренностей фреймворка ведет к большой опасности получить стектрейсом по логу. Что ж, чтобы немного развеять ощущение полной магии происходящего, сегодня мы возьмем приложение из предыдущей статьи и разберем, как и что происходит внутри фреймворка и от каких проблем нас отгораживает Boot. Целевая аудитория все же начинающие разработчики, но с некоторым опытом и базовыми знаниями Java и Spring. Хотя, возможно, и опытным пользователям Spring будет интересно освежить знания того, что происходит под капотом.

Начнем срывать покровы с самых базовых понятий Spring. Бин (bean) — это не что иное, как самый обычный объект. Разница лишь в том, что бинами принято называть те объекты, которые управляются Spring-ом и живут внутри его DI-контейнера. Бином является почти все в Spring — сервисы, контроллеры, репозитории, по сути все приложение состоит из набора бинов. Их можно регистрировать, получать в качестве зависимостей, проксировать, мокать и т.п.

DI контейнер

Ключевой и фундаментальный механизм Spring. Внешне очень простой, но внутри он предоставляет очень много механизмов для тонкой настройки зависимостей. По сути, любое приложение Спринг — это набор бинов, связанных вместе через DI контейнер.

Очень часто при обсуждении Spring звучит аргумент, что его можно легко заменить на любой леговесный DI контейнер (Guice, например) и получить то же самое, но легче и проще. И здесь очень важно понять — ценность Spring DI не в самом факте его наличия, а в его фундаментальности. Все библиотеки в экосистеме Spring, по сути, просто регистрируют свои бины в этом контейнере (включая и сам Spring) — и через иньекцию зависимостей разработчики приложения смогут получить нужные компоненты. Простой пример: при использовании Spring Security OAuth если сконфигурить параметры OAuth в application.properties , то Spring Security предоставит бин OAuth2RestTemplate который мы можем просто заинжектить в своем коде. И этот бин при обращении к внешнему API будет знать, куда и как пойти, чтобы получить OAuth токен, как его обновлять, в какое место нашего запроса его добавлять и т.п. Так вот ценность DI тут в том, что это просто механизм общения между нашим кодом и Spring Security. И простой заменой реализации DI на Guice не добиться, чтобы Spring Security тоже начал его использовать. А если в этом новом DI не будет интеграции со всеми библиотеками Spring-а, то и ценность его сильно падает.

Еще один очень важный момент, который многие упускают при обсуждении DI контейнера, это то, что использование инъекции зависимостей не подразумевает создания интерфейсов для каждого компонента. Это очень простая мысль, но я много раз видел, что из-за своей простоты она не всегда очевидна. Более того, создание интерфейса, если у него лишь одна реализация — считается плохой практикой. Т.е. классы вполне могут сами по себе быть объектами DI. Более того, отсутствие интерфейса даже не мешает их мокать в тестах, т.к. Mockito, например, вполне умеет мокать классы.

Контекст

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

Конфигурация

Итак, если приложение — это набор бинов, чтобы оно заработало нам нужно этот набор описать.

Конфигурация — это просто описание доступных бинов. Spring дает несколько вариантов, как можно описать набор бинов, которые сформируют приложение. Исторический вариант — это через набор xml файлов. В наши дни ему на смену пришли Java аннотации. Spring Boot построен на аннтациях чуть более, чем полностью и большинство современных библиотек в принципе тоже можно сконфигурить через аннотации. В третьем своем поколении, конфигурация бинов пришла к подходу функциональной регистрации (functional bean registration), которая станет одной из важных новых фич готовящегося к выходу Spring 5.

Типичный класс конфигурации может, выглядеть, например так:

Эта конфигурация определяет два бина, причем второй зависит от первого. И здесь в игру вступит Spring – когда мы просим предоставить инстанс PaymentProvider — Spring найдет его в контексте и предоставит нам.

Конфигурацию не обязательно описывать в одном огромном файле, можно разбить на несколько и объединять их с помощью @Import аннотаций.

Сканирование компонентов

Достаточно важный компонент Spring Framework, еще один подход к упрощению конфигурации приложения. Идея очень простая — если мы знаем, что наш класс MyCoolComponent должен регистрировать бин с именем myCoolComponent , зачем каждый раз писать @Bean MyCoolComponent myCoolComponent(dependencies. ) < return new MyCoolComponent(dependencies. ); >? Почему просто не дать Spring–у автоматом зарегистрировать и создать бин на основании нужного класса? Эту задачу и решает сканирование компонентов. Т.е. если мы объявим наш класс как

и разрешим сканирование компонентов — то Spring сам создаст и зарегистрирует бин с именем myCoolComponent , использовав конструктор класса и заинжектив туда все зависимости.

Со сканированием компонентов надо быть осторожным, т.к. по сути оно неявно меняет контекст приложения. Например, если у нас есть интерфейс и две реализации — и на каждом указан @Component , то при попытке заинжектить зависимость на интерфейс Spring бросит исключение, что есть два бина, которые удовлетворяют запросу.

Резюме

Итак, вещи которые нужно запомнить: приложение Spring, описанное интерфейсом ApplicationContext , представляет собой набор объектов (бинов), управляемых DI контейнером. Конфигурация набора бинов осуществляется с помощью классов конфигурации (аннотация @Configuration ), которые могут быть комбинированы с помощью импортов (аннотация @Import ).

Теперь переходим к следующей части. Допустим, нам надо сконфигурить подключение к MySQL базе данных. Если мы хотим использовать Spring Data JPA с Hibernate в качестве провайдера, нам потребуется сконфигурировать несколько бинов — EntityManagerFactory (основной класс JPA), DataSource для подключения непосредственно к базе через JDBC драйвер и т.п. Но с другой стороны, если мы это делаем каждый раз и, по сути, делаем одно и то же — почему бы это не автоматизировать? Скажем, если мы указали строку подключения к базе и добавили зависимость на MySQL драйвер — почему бы чему-то автоматически не создать все нужные бины для работы с MySQL? Именно это и делает Spring Boot. По сути, Spring Boot это просто набор классов конфигурации, которые создают нужные бины в контексте. Точно так же их можно создать руками, просто Boot это автоматизирует.

Автоконфигурация

Важное понятие Spring Boot это автоконфигурация. По сути, это просто набор конфигурационных классов, которые создают и регистрируют определенные бины в приложении. По большому счету, даже сам Embedded Servlet Container — это просто еще один бин, который можно сконфигурировать! Пара важных моментов, которые важно знать об автоконфигурации:

Включается аннотацией @EnableAutoConfiguration
Работает в последнюю очередь, после регистрации пользовательских бинов
Принимает решения о конфигурации на основании доступных в classpath классов, свойств в application.properties и т.п.
Можно включать и выключать разные аспекты автоконфигурации, и применять ее частично (например, только MySQL + JPA, но не веб)
Всегда отдает приоритет пользовательским бинам. Если ваш код уже зарегистрировал бин DataSource — автоконфигурация не будет его перекрывать

Условия и порядок регистрации бинов

Логика при регистрации бинов управляется набором @ConditionalOn* аннотаций. Можно указать, чтобы бин создавался при наличии класса в classpath ( @ConditionalOnClass ), наличии существующего бина ( @ConditionalOnBean ), отсуствии бина ( @ConditionalOnMissingBean ) и т.п.

Spring Boot активно использует эти аннотации чтобы оставаться как можно более незаметным и не перекрывать пользовательские конфигурации.

Теперь, имея в запасе базовые теоретические знания, разберем что же происходит при запуске приложения.

Итак, наше приложение включает такой код:

Давайте разберем что здесь происходит по шагам.

Класс DemoApplication

Этот класс помечен аннотацией @SpringBootApplication , что является мета-аннотацией, т.е. по сути, является алиасом для нескольких аннотаций:

@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan .

Т.е. наличие @SpringBootApplication включает сканирование компонентов, автоконфигурацию и показывает разным компонентам Spring (например, интеграционным тестам), что это Spring Boot приложение

Это просто хелпер, который делает пару вещей — используя список предоставленных конфигураций (а класс DemoApplication сам по себе конфигурация, см. выше) создает ApplicationContext , конфигурирует его, выводит баннер в консоли и засекает время старта приложения и т.п. Его можно заменить на ручное создание контекста: new AnnotationConfigApplicationContext(DemoApplication.class) . Как можно понять из названия, это контекст приложения, который конфигурируется с помощью аннотаций. Однако, этот контекст не знает ничего об embedded servlet container-ах, и совершенно точно не умеет себя запускать. Его наследник, уже из Spring Boot — AnnotationConfigEmbeddedWebApplicationContext делать это вполне умеет, и если мы в методе main напишем просто

То получим точно такое же работающее приложение, т.к. класс AnnotationConfigEmbeddedWebApplicationContext найдет в контексте бин типа EmbeddedServletContainerFactory и через него создаст и запустит встроенный контейнер. Обратите внимание, что все это работает в рамках общего DI контейнера, то есть этот класс можно реализовать самим.

@EnableAutoConfiguration

Эта аннотация включает автоконфигурацию. И здесь, пожалуй, ключевой момент в развенчании магии Spring. Вот как объявлена эта аннотация:

Т.е. это самый обычный импорт конфигурации, про который мы говорили выше. Класс же EnableAutoConfigurationImportSelector (и его преемник в Spring Boot 1.5+ — AutoConfigurationImportSelector ) это просто конфигурация, которая добавит несколько бинов в контекст. Однако, у этого класса есть одна тонкость — он не объявляет бины сам, а использует так называемые фабрики.

Класс EnableAutoConfigurationImportSelector смотрит в файл spring.factories и загружает оттуда список значений, которые являются именами классов (авто)конфигураций, которые Spring Boot импортирует.

Кусочек файла spring.factories (он находится в папке META-INF внутри spring-boot-autoconfigure..jar ), который нам сейчас нужен это:

Т.е. аннотация @EnableAutoConfiguration просто импортирует все перечисленные конфигурации, чтобы предоставить нужные бины в контекст приложения.

По сути, ее можно заменить на ручной импорт нужных конфигураций:

Однако, особенность в том, что Spring Boot пытается применить все конфигурации (а их около сотни). Я думаю, у внимательного читателя уже появилась пара вопросов, которые стоит прояснить.

"Но это же медленно!". И да, и нет — под рукой нет точных цифр, но сам по себе процесс автоконфигурации очень быстрый (порядка сотни миллисекунд на абстрактной машине в вакууме)

Краткое резюме

В основе "магии" Spring Boot нет ничего магического, он использует совершенно базовые понятия из Spring Framework. В кратком виде процесс можно описать так:

Аннотация @SpringBootApplication включает сканирование компонентов и авто-конфигурацию через аннотацию @EnableAutoConfiguration
@EnableAutoConfiguration импортирует класс EnableAutoConfigurationImportSelector
EnableAutoConfigurationImportSelector загружает список конфигураций из файла META-INF/spring.factories
Каждая конфигурация пытается сконфигурить различные аспекты приложения (web, JPA, AMQP etc), регистрируя нужные бины и используя различные условия (наличие / отсутствие бина, настройки, класса и т.п.)
Созданный в итоге AnnotationConfigEmbeddedWebApplicationContext ищет в том же DI контейнере фабрику для запуска embedded servlet container
Servlet container запускается, приложение готово к работе!

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

Auto-configuration report

В случае, когда что-то идет не так, Spring Boot позволяет запустить диагностику автоконфигурации и посмотреть, какие именно бины были созданы. Чтобы увидеть эту информацию, нужно запустить приложение с ключом --debug .

В ответ Spring выдаст детальный Auto-configuration report:

Строчка в Positive / Negative matches будет для каждой примененной автоконфигурации, более того, Boot сообщит, почему тот или иной бин был создан (т.е. укажет, какие из условий регистрации были выполнены).

Actuator

Spring Boot Actuator это мощный инструмент диагностики работающего приложения, который умеет давать много полезной аналитики (более того, набор этих метрик можно легко расширять из приложения).

Spring все же остается большим и не самым простым фреймворком, но это цена высокоуровневых абстракций, которые он предоставляет. И хотя знать все тонкости работы фреймворка в ежедневной разработке не нужно, знать, как он работает изнутри, все же, полезно. Надеюсь, что эта статья помогла понять важность и ценность Spring именно как экосистемы и убрала немного "магичности" в происходящем, особенно при использовании Spring Boot. Мой совет — не бойтесь углубляться в недра фреймворка, читайте исходники и документацию, благо они у Spring-a почти эталонные, на мой взгляд.

Так же стоит отметить, что в готовящемся к выходу в сентябре Spring 5 появится несколько новых концепций, направленных на создание простых приложений, и понижение уровня "магии" (хотя, как мы выяснили, магии там особо и нет). Одна из концепций это Functional Bean Registration, которая позволяет регистрировать бины в контексте с помощью функций, или даже с помощью неплохого DSL на Kotlin (а Spring 5 добавит много хорошего для поддержки Kotlin). Следующая, но еще более важная вещь, это комбинация Functional Web Framework и WebFlux (reactive web framework), которая позволит создавать веб-приложения вообще без зависимости на Spring MVC и запускать их без сервлет контейнеров. Приложение вполне сможет работать без контекста приложений и DI, и описываться просто как набор функций request -> response . Об этом можно чуть больше почитать здесь (на английском).

Сегодня я решил представить вам перевод цикла статей для подготовки к Spring Professional Certification.

Это перевод только первой статьи, если он зайдет аудитории, я продолжу выпуск переводов.

Spring 5 Design Patterns
Spring in Action 4th edition
Spring Security — Third Edition
Core Spring 5 Certification in Detail by Ivan Krizsan
Spring Documentation and Spring API javadocs

Внедрение зависимостей — это специальный паттерн, который уменьшает связь между Spring компонентами. Таким образом, при применении DI, ваш код становится чище, проще, его становится легче понять и тестировать.
Согласно паттерну DI, создание объектов для зависимостей переходит на фабрику или отдается третьей стороне. Это означает, что мы можем сосредоточиться на использовании этих объектов вместо их создания.

Уменьшенная связь между частями приложения
Улучшенное тестирование
Улучшенная архитектура приложения
Уменьшает шаблонный код
Стандартизирует разработку приложения

Улучшенное тестирование. В тестах бин может быть заменен специальным объектом(mock или stub), который реализует интерфейс бина.
Позволяет использовать механизм динамических прокси из JDK(например, при создании репозитория через Spring Data)
Позволяет скрывать реализацию

В Spring Framework интерфейс org.springframework.factory.BeanFactory предоставляет фабрику для бинов, которая в то же время является IoC контейнером приложения. Управление бинами основано на конфигурации(java или xml).

Интерфейс org.springframework.context.ApplicationContext — это обертка над bean factory, предоставляющая некоторые дополнительные возможности, например AOP, транзакции, безопасность, i18n, и т.п.

Основа Spring Framework — контейнер, и наши объекты "живут" в этом контейнере.
Контейнер обычно создает множество объектов на основе их конфигураций и управляет их жизненным циклом от создания объекта до уничтожения.

Контейнер — это объект, реализующий интерфейс ApplicationContext.

Контейнер создается при запуске приложения
Контейнер считывает конфигурационные данные
Из конфигурационных данных создается описание бинов
BeanFactoryPostProcessors обрабатывают описание бина
Контейнер создает бины используя их описание
Бины инициализируются — значения свойств и зависимости внедряются в бин
BeanPostProcessor запускают методы обратного вызова(callback methods)
Приложение запущено и работает
Инициализируется закрытие приложения
Контейнер закрывается
Вызываются callback methods

Spring обеспечивает несколько разновидностей контекста.

Есть несколько основных реализаций интерфейса ApplicationContext:

FileSystemXmlApplicationContext
ClassPathXmlApplicationContext
AnnotationConfigApplicationContext
XmlWebApplicationContext
AnnotationConfigWebApplicationContext

Примеры создания контекста:

Если вы используете JUnit 5, то вам нужно указать 2 аннотации:

@ExtendWith(TestClass.class) — используется для указания тестового класса
@ContextConfoguration(classes = JavaConfig.class) — загружает java/xml конфигурацию для создания контекста в тесте

Можно использовать аннотацию @SpringJUnitConfig , которая сочетает обе эти аннотации.
Для теста веб-слоя можно использовать аннотацию @SpringJUnitWebConfig .

Если это не веб-приложение, то есть 2 способа:

В Spring Boot приложении:

Spring Boot самостоятельно зарегистрирует shutdown-hook за вас.

Чтобы создать класс с конфигурацией на основе Java-кода, нужно аннотировать его с помощью
@Configuration .
Этот класс будет содержать фабричные методы для создания бинов в контейнере.
Эти методы должны быть аннотированы аннотацией @Bean .

Этот класс поместит в контейнер экземпляр класса DataSource. Позднее его можно будет использовать при доступе к базе данных.

Component scanning(сканирование компонентов) — Spring автоматически обнаруживает бины, которые будут находиться в контейнере. Это бины с аннотациями-стереотипами.

Однако сканирование компонентов не включено по умолчанию.
Чтобы включить сканирование, аннотируйте @Configuration-класс аннотацией @ComponentScanning . Spring будет автоматически сканировать тот пакет, в котором находится этот класс и все его подпакеты.
Можно указать и другие пакеты для сканирования, и даже классы:

Autowiring(внедрение) — Spring автоматически внедрит зависимости во время сканирования или помещения бина в контейнер.
Для внедрения зависимостей используется аннотация @Autowire .

Стереотипы — это аннотации, обозначающие специальную функциональность.
Все стереотипы включают в себя аннотацию @Component .

Component	Корневая аннотация, которая помечает класс как кандидат для автовнедрения
Controller	Указывает, что класс является контроллером для отправления данных на фронт.
@RestController	Указывает, что класс является контроллером для REST. Содержит аннотации Controller и @ResponseBody
Service	Указывает, что класс является сервисом для выполнения бизнес-логики
Repository	Указывает, что класс является репозиторием для работы с бд
@Configuration	Указывает, что класс содержит Java-конфигурацию(@Bean-методы)

Область видимости — scope, скоуп. Существует 2 области видимости по умолчанию.

Singleton	Область видимости по умолчанию. В контейнере находится всего 1 экземпляр бина
Prototype	В контейнере может находится любое количество экземпляров бина

И 4 области видимости в веб-приложении.

Область видимости указывается с помощью аннотации @Scope на @Bean методах.

Prototype Scope не потокбезопасный, т.к. он не гарантирует что один и тот же экземпляр будет вызываться только в 1 потоке.

Singleton Scope же наоборот потокобезопасный.

Singleton-бины обычно создаются сразу при сканировании.
Prototype-бины обычно создаются только после запроса.

Чтобы указать способ инициализации, можно использовать аннотацию @Lazy .
Она ставится на @Bean-методы, на @Configuration-классы, или на @Component-классы.
В зависимости от параметра(true или false), который принимает аннотация, инициализация будет или ленивая, или произойдет сразу. По умолчанию(т.е. без указания параметра) используется true.

Singleton bean можно внедрять в любой другой бин.

В сам singleton можно внедрить только prototype или singleton .
Если внедрять prototype, то для каждого singleton будет создан уникальный prototype.

Prototype может быть зависимостью для любого бина.
Внедрять можно только singleton или prototype.

BeanFactoryPostProcessor работает над описаниями бинов или конфигурационными метаданными перед тем, как бин будет создан.
Spring поставляет несколько полезных реализаций BeanFactoryPostProcessor , например, читающий property-файлы и получающий из них свойства бинов.
Вы можете написать собственную реализацию BFPP.

Для того чтобы использовать кастомный BFPP. Вы можете переопределить механизм получения данных из метафайлов.

destroyMethod — указывает на метод обратного вызова. Метод находится в бине.
initMethod — указывает на метод обратного вызова. Метод находится в бине.
name — имя бина. По умолчанию именем бина является имя метода.
value — алиас для name()

Spring использует несколько BeanPostProcessor’ов.
Например, CommonAnnotationPostProcessor или AutowiredAnnotationBeanPostProcessor .
BPP работает с экземплярами бинов, т.е. контейнер создает бин, а затем начинает работать BPP.

Есть 3 варианта для создания таких методов:

Ниже перечислены типы DI, которые могут быть использованы в вашем приложении:

DI через конструктор считается самым лучшим способом, т.к. для него не надо использовать рефлексию, а также он не имеет недостатков DI через сеттер.
DI через поле не рекомендуется использовать, т.к. для этого применяется рефлексия, снижающая производительность.
DI через конструктор может приводить к циклическим зависимостям. Чтобы этого избежать, можно использовать ленивую инициализацию бинов или DI через сеттер.

Контейнер определяет тип объекта для внедрения
Контейнер ищет бины в контексте(он же контейнер), которые соответствуют нужному типу
Если есть несколько кандидатов, и один из них помечен как @Primary , то внедряется он
Если используется аннотации @Autowire + Qualifier , то контейнер будет использовать информацию из @Qualifier , чтобы понять, какой компонент внедрять
В противном случае контейнер попытается внедрить компонент, основываясь на его имени или ID
Если ни один из способов не сработал, то будет выброшено исключение

Контейнер обрабатывает DI с помощью AutowiredAnnotationBeanPostProcessor. В связи с этим, аннотация не может быть использована ни в одном BeanFactoryPP или BeanPP.

Если внедряемый объект массив, коллекция, или map с дженериком, то Spring внедрит все бины подходящие по типу в этот массив(или другую структуру данных). В случае с map ключом будет имя бина.

Вы можете использовать разные типы внедрения:

Spring предоставляет аннотацию Qualifier, чтобы преодолеть проблему неоднозначности при DI.

Если в контейнере есть несколько бинов одного типа(SomeClass), то контейнер внедрит именно тот бин, над @Bean-методом которого стоит соответствующий квалификатор. Также можно не ставить квалификатор на метод, а использовать имя бина в качестве параметра квалификатора.
Имя бина можно можно указать через параметр аннотации Bean, а по умолчанию это имя фабричного метода.

Прокси это специальный объект, который имеет такие же публичные методы как и бин, но у которого есть дополнительная функциональность.
Два вида прокси:

JDK-proxy — динамическое прокси. API встроены в JDK. Для него необходим интерфейс
CGLib proxy — не встроен в JDK. Используется когда интерфейс объекта недоступен

Позволяют добавлять доп. логику — управление транзакциями, безопасность, логирование
Отделяет некоторый код(логирование и т.п.) от основной логики

Если в контейнере нет экземпляра бина, то вызывается @Bean-метод. Если экземпляр бина есть, то возвращается уже созданный бин.

При использовании Java-конфигурации вы можете использовать аннотацию @Profile .
Она позволяет использовать разные настройки для Spring в зависимости от указанного профиля.
Ее можно ставить на @Configuration и Component классы, а также на Bean методы.

Для этого можно использовать аннотацию @Value .
Такие значения можно получать из property файлов, из бинов, и т.п.

В эту переменную будет внедрена строка, например из property или из view.

Всех, кого интересует внутреннее устройство Spring, прошу под кат.

На схеме изображены основные этапы поднятия ApplicationContext. В этом посте мы остановимся на каждом из этих этапов. Какой-то этап будет рассмотрен подробно, а какой-то будет описан в общих чертах.

1. Парсирование конфигурации и создание BeanDefinition

Xml конфигурация — ClassPathXmlApplicationContext(“context.xml”)
Конфигурация через аннотации с указанием пакета для сканирования — AnnotationConfigApplicationContext(“package.name”)
Конфигурация через аннотации с указанием класса (или массива классов) помеченного аннотацией @Configuration -AnnotationConfigApplicationContext(JavaConfig.class). Этот способ конфигурации называется — JavaConfig.
Groovy конфигурация — GenericGroovyApplicationContext(“context.groovy”)

Цель первого этапа — это создание всех BeanDefinition. BeanDefinition — это специальный интерфейс, через который можно получить доступ к метаданным будущего бина. В зависимости от того, какая у вас конфигурация, будет использоваться тот или иной механизм парсирования конфигурации.

Xml конфигурация

Для Xml конфигурации используется класс — XmlBeanDefinitionReader, который реализует интерфейс BeanDefinitionReader. Тут все достаточно прозрачно. XmlBeanDefinitionReader получает InputStream и загружает Document через DefaultDocumentLoader. Далее обрабатывается каждый элемент документа и если он является бином, то создается BeanDefinition на основе заполненных данных (id, name, class, alias, init-method, destroy-method и др.). Каждый BeanDefinition помещается в Map. Map хранится в классе DefaultListableBeanFactory. В коде Map выглядит вот так.

Конфигурация через аннотации с указанием пакета для сканирования или JavaConfig

Конфигурация через аннотации с указанием пакета для сканирования или JavaConfig в корне отличается от конфигурации через xml. В обоих случаях используется класс AnnotationConfigApplicationContext.

Если заглянуть во внутрь AnnotationConfigApplicationContext, то можно увидеть два поля.

ClassPathBeanDefinitionScanner сканирует указанный пакет на наличие классов помеченных аннотацией @Component (или любой другой аннотацией которая включает в себя @Component). Найденные классы парсируются и для них создаются BeanDefinition.
Чтобы сканирование было запущено, в конфигурации должен быть указан пакет для сканирования.

Groovy конфигурация

Данная конфигурация очень похожа на конфигурацию через Xml, за исключением того, что в файле не XML, а Groovy. Чтением и парсированием groovy конфигурации занимается класс GroovyBeanDefinitionReader.

2. Настройка созданных BeanDefinition

После первого этапа у нас имеется Map, в котором хранятся BeanDefinition. Архитектура спринга построена таким образом, что у нас есть возможность повлиять на то, какими будут наши бины еще до их фактического создания, иначе говоря мы имеем доступ к метаданным класса. Для этого существует специальный интерфейс BeanFactoryPostProcessor, реализовав который, мы получаем доступ к созданным BeanDefinition и можем их изменять. В этом интерфейсе всего один метод.

Метод postProcessBeanFactory принимает параметром ConfigurableListableBeanFactory. Данная фабрика содержит много полезных методов, в том числе getBeanDefinitionNames, через который мы можем получить все BeanDefinitionNames, а уже потом по конкретному имени получить BeanDefinition для дальнейшей обработки метаданных.

Давайте разберем одну из родных реализаций интерфейса BeanFactoryPostProcessor. Обычно, настройки подключения к базе данных выносятся в отдельный property файл, потом при помощи PropertySourcesPlaceholderConfigurer они загружаются и делается inject этих значений в нужное поле. Так как inject делается по ключу, то до создания экземпляра бина нужно заменить этот ключ на само значение из property файла. Эта замена происходит в классе, который реализует интерфейс BeanFactoryPostProcessor. Название этого класса — PropertySourcesPlaceholderConfigurer. Весь этот процесс можно увидеть на рисунке ниже.

Давайте еще раз разберем что же у нас тут происходит. У нас имеется BeanDefinition для класса ClassName. Код класса приведен ниже.

Если PropertySourcesPlaceholderConfigurer не обработает этот BeanDefinition, то после создания экземпляра ClassName, в поле host проинжектится значение — "$" (в остальные поля проинжектятся соответсвующие значения). Если PropertySourcesPlaceholderConfigurer все таки обработает этот BeanDefinition, то после обработки, метаданные этого класса будут выглядеть следующим образом.

Соответственно в эти поля проинжектятся правильные значения.

Для того что бы PropertySourcesPlaceholderConfigurer был добавлен в цикл настройки созданных BeanDefinition, нужно сделать одно из следующих действий.

Для XML конфигурации.

PropertySourcesPlaceholderConfigurer обязательно должен быть объявлен как static. Без static у вас все будет работать до тех пор, пока вы не попробуете использовать @ Value внутри класса @Configuration.

3. Создание кастомных FactoryBean

FactoryBean — это generic интерфейс, которому можно делегировать процесс создания бинов типа . В те времена, когда конфигурация была исключительно в xml, разработчикам был необходим механизм с помощью которого они бы могли управлять процессом создания бинов. Именно для этого и был сделан этот интерфейс. Для того что бы лучше понять проблему, приведу пример xml конфигурации.

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

А что делать если я хочу каждый раз случайный цвет? Вот тут то и приходит на помощь интерфейс FactoryBean.

Создадим фабрику которая будет отвечать за создание всех бинов типа — Color.

Добавим ее в xml и удалим объявленные до этого бины типа — Color.

Теперь создание бина типа Color.class будет делегироваться ColorFactory, у которого при каждом создании нового бина будет вызываться метод getObject.

Для тех кто пользуется JavaConfig, этот интерфейс будет абсолютно бесполезен.

4. Создание экземпляров бинов

Созданием экземпляров бинов занимается BeanFactory при этом, если нужно, делегирует это кастомным FactoryBean. Экземпляры бинов создаются на основе ранее созданных BeanDefinition.

5. Настройка созданных бинов

Интерфейс BeanPostProcessor позволяет вклиниться в процесс настройки ваших бинов до того, как они попадут в контейнер. Интерфейс несет в себе несколько методов.

Оба метода в итоге должны вернуть бин. Если в методе вы вернете null, то при получении этого бина из контекста вы получите null, а поскольку через бинпостпроцессор проходят все бины, после поднятия контекста, при запросе любого бина вы будете получать фиг, в смысле null.
Если вы хотите сделать прокси над вашим объектом, то имейте ввиду, что это принято делать после вызова init метода, иначе говоря это нужно делать в методе postProcessAfterInitialization.

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

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

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

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

По умолчанию, диапазон случайных числе будет от 0 до 10.

Затем, нужно создать обработчик этой аннотации, а именно реализацию BeanPostProcessor для обработки аннотации InjectRandomInt.

Код данного BeanPostProcessor достаточно прозрачен, поэтому мы не будем на нем останавливаться, но тут есть один важный момент.

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

Первая группа разработчиков свою задачу выполнила. Теперь вторая группа может использовать эти наработки.

Хочу сказать отдельное спасибо EvgenyBorisov. Благодаря его курсу, я решился на написание этого поста.

Читайте также: