Java Blog

В следующем примере используются метаданные конфигурации на основе XML для DI на основе сеттера. Небольшая часть конфигурационного файла Spring XML определяет некоторые определения bean-компонентов следующим образом: <bean id="exampleBean" class="examples.ExampleBean"> <!-- инъекция сеттера с использованием вложенного элемента ref --> <property name="beanOne"> <ref bean="anotherExampleBean"/> </property> <!-- инъекция сеттера с использованием атрибута точный ref --> <property name="beanTwo" ref="yetAnotherBean"/> <property name="integerProperty" value="1"/> </bean> <bean id="anotherExampleBean" class="examples.AnotherBean"/> <bean id="yetAnotherBean" class="examples.YetAnotherBean"/> В следующем примере показан соответствующий класс ExampleBean: Java public ...

Контейнер выполняет разрешение зависимостей бина следующим образом: ApplicationContext создается и инициализируется с метаданными конфигурации, которые описывают все компоненты. Метаданные конфигурации могут быть указаны с помощью XML, кода Java или аннотаций. Для каждого компонента его зависимости выражаются в форме свойств, аргументов конструктора или аргументов метода статичной фабрики (если вы используете его вместо обычного конструктора). Эти зависимости предоставляются компоненту, когда компонент фактически создается. Каждый аргумент свойства или конструктора является фактическим определением значения, которое нужно установить, или ссылкой на другой компонент в контейнере. Каждый аргумент свойства или конструктора, являющийся значением, преобразуется из указанного формата в фактический тип аргумента этого свойства или конструктора. По умолчанию Spring может преобразовать значение, предоставленное в строковом формате, во все встроенные типы, такие как int, long, String, bool...

Поскольку вы можете смешивать DI на основе конструктора и сеттера, рекомендуется использовать конструкторы для обязательных зависимостей, а также методы сеттеры или методы настройки для необязательных зависимостей. Обратите внимание, что использование аннотации @Required в методе сеттере может быть использовано для того, чтобы сделать свойство обязательной зависимостью; однако внедрение в конструктор с программной проверкой аргументов предпочтительнее. Команда Spring, как правило, выступает за внедрение конструктора, поскольку она позволяет реализовывать компоненты приложения как неизменяемые объекты и гарантирует, что требуемые зависимости не равны null. Более того, внедренные конструктором компоненты всегда возвращаются клиентскому (вызывающему) коду в полностью инициализированном состоянии. В качестве примечания следует отметить, что большое количество аргументов конструктора является нежелательным кодом, подразумевая, что класс, вероятно, имеет слишком много обязанностей и должен ...

DI на основе сеттера выполняется контейнером, вызывающим методы setter для ваших bean-компонентов после вызова конструктора без аргументов или статического метода фабрики без аргументов для создания экземпляра вашего bean-компонента. В следующем примере показан класс, который может быть внедрен зависимостью только при использовании setter внедрения. Этот класс является обычным Java классом. Это POJO, который не зависит от конкретных интерфейсов контейнера, базовых классов или аннотаций. Java public class SimpleMovieLister { // SimpleMovieLister зависит от MovieFinder private MovieFinder movieFinder; // метод сеттер, чтобы контейнер Spring мог внедрить MovieFinder public void setMovieFinder(MovieFinder movieFinder) { this.movieFinder = movieFinder; } // бизнес-логика, которая фактически использует внедренный MovieFinder, опущена... } Kotlin class SimpleMovieLister { // свойство с поздней инициализацией, чтобы контейнер Spring мог внед...

Соответствие разрешения аргумента конструктора происходит с использованием типа аргумента. Если в аргументах конструктора определения компонента не существует потенциальной неоднозначности, порядок, в котором аргументы конструктора определяются в определении компонента, является порядком, в котором эти аргументы передаются соответствующему конструктору при создании экземпляра компонента. Рассмотрим следующий класс: Java package x.y; public class ThingOne { public ThingOne(ThingTwo thingTwo, ThingThree thingThree) { // ... } } Kotlin package x.y class ThingOne(thingTwo: ThingTwo, thingThree: ThingThree) Предполагая, что классы ThingTwo и ThingThree не связаны наследованием, потенциальной двусмысленности не существует. Таким образом, следующая конфигурация работает нормально, и вам не нужно явно указывать индексы или типы аргументов конструктора в элементе <constructor-arg/>. <beans> <bean id="beanOne" class="x.y.Thi...

DI на основе конструктора выполняется контейнером, вызывающим конструктор с несколькими аргументами, каждый из которых представляет зависимость. Вызов статического метода фабрики со специфическими аргументами для создания компонента почти эквивалентен, и в этом обсуждении аргументы конструктора и статического метода фабрики аналогичны. В следующем примере показан класс, который может быть внедрен только в зависимости с помощью конструктора: Java public class SimpleMovieLister { // SimpleMovieLister имеет зависимость от MovieFinder private MovieFinder movieFinder; // конструктор, чтобы контейнер Spring мог внедрить MovieFinder public SimpleMovieLister(MovieFinder movieFinder) { this.movieFinder = movieFinder; } // бизнес-логика, которая фактически использует внедренный MovieFinder, опущена ... } Kotlin // конструктор, чтобы контейнер Spring мог внедрить MovieFinder class SimpleMovieLister(private val movieFinder: MovieFinder) { // бизне...

Типичное корпоративное приложение не состоит из одного объекта (или bean-компонента в Spring). Даже в самом простом приложении есть несколько объектов, которые работают вместе, чтобы представить то, что конечный пользователь видит как связное приложение. В следующих постах объясняется, как перейти от определения отдельных определений bean-компонентов к полностью реализованному приложению, в котором объекты взаимодействуют для достижения цели. Внедрение зависимостей Внедрение зависимостей (DI, Dependency injection) - это процесс, при котором объекты определяют свои зависимости (то есть другие объекты, с которыми они работают) только через аргументы конструктора, аргументы метода фабрики или свойства, которые устанавливаются в экземпляре объекта после его создания или возвращения из фабричного метода. Затем контейнер внедряет эти зависимости при создании компонента. Этот процесс по своей сути является инверсией (отсюда и название, инверсия контроля) самого компонента, самостоятельно к...