что такое autowired в spring
Руководство по весне @Autowired
Руководство по наиболее распространенному использованию аннотаций и квалификаторов Spring @Autowired
1. Обзор
Дальнейшее чтение:
Сканирование пружинных Компонентов
Введение в инверсию управления и внедрение зависимостей с помощью пружины
В этом уроке мы сначала рассмотрим, как включить автоматическое подключение и различные | способы автоматического подключения компонентов. Позже мы поговорим о разрешении конфликтов компонентов с использованием @квалификатора аннотации, , а также о возможных сценариях исключений.
2. Включение аннотаций @Autowired
Чтобы использовать конфигурацию на основе Java в нашем приложении, давайте включим инъекцию на основе аннотаций для загрузки нашей конфигурации Spring:
В качестве альтернативы, аннотация в основном используется для активации аннотаций внедрения зависимостей в XML-файлах Spring.
Давайте использовать эту аннотацию в основном классе приложения:
3. Использование @Autowired
3.1. @Автоматически подключается к свойствам
Во-первых, давайте определим FooFormatter bean:
Затем мы введем эту фасоль в Службу питания фасоль, используя @Autowired об определении поля:
3.2. @Автоматическое подключение к сеттерам
Теперь давайте попробуем добавить @Autowired аннотация метода настройки.
В следующем примере метод setter вызывается с экземпляром FooFormatter при создании Службы питания :
3.3. @Автоматически подключается к конструкторам
Наконец, давайте используем @Autowired в конструкторе.
Мы увидим, что экземпляр FooFormatter вводится Spring в качестве аргумента конструктора Foodservice :
4. @Автоматические и необязательные зависимости
Следовательно, это предотвращает успешный запуск контейнера Spring, за исключением формы:
Чтобы исправить это, нам нужно объявить компонент требуемого типа:
5. Автоматическое Устранение неоднозначности
Чтобы разрешить этот конфликт, нам нужно явно указать Spring, какой компонент мы хотим ввести.
5.1. Автоматическое подключение с помощью @квалификатора
Например, давайте посмотрим, как мы можем использовать аннотацию @Qualifier для указания требуемого компонента.
Сначала мы определим 2 компонента типа Форматер :
Теперь давайте попробуем внедрить компонент Форматирования в класс FooService :
Мы можем избежать этого, сузив реализацию с помощью @Квалификатор аннотация:
Когда существует несколько компонентов одного и того же типа, рекомендуется использовать @Квалификатор , чтобы избежать двусмысленности.
Пожалуйста, обратите внимание, что значение @Квалификатора аннотации совпадает с именем, объявленным в @Компоненте аннотации нашей FooFormatter реализации.
5.2. Автоматическое подключение с помощью Пользовательского классификатора
Затем мы можем использовать тип форматирования в различных реализациях для указания пользовательского значения:
Наконец, наша пользовательская аннотация квалификатора готова к использованию для автоматической проводки:
Значение, указанное в @Target мета-аннотации, ограничивает применение квалификатора, которым в нашем примере являются поля, методы, типы и параметры.
5.3. Автоматическое подключение по имени
Spring использует имя компонента в качестве значения квалификатора по умолчанию. Он проверит контейнер и будет искать компонент с точным именем в качестве свойства для его автоматического подключения.
6. Заключение
В этой статье мы обсудили автопроводку и различные способы ее использования. Мы также рассмотрели способы решения двух распространенных исключений автоматической проводки, вызванных либо отсутствующим компонентом, либо неоднозначной инъекцией компонента.
Русские Блоги
Spring @Autowired и три способа запустить автоматическое сканирование
Предисловие:
@Autowired определение кода аннотации
Этот метод реализуется с использованием метода set соответствующего класса. Прежде чем использовать аннотацию @Autowired, сначала убедитесь, что вы можете использовать здесь аннотацию @Autowired.
1. Введение в сценарии использования аннотаций @Autowired
Во-вторых, основная часть аннотации @Autowired
Фактически, когда запускается Spring IoC, контейнер автоматически загружает постпроцессор AutowiredAnnotationBeanPostProcessor. Когда контейнер сканирует @Autowied, @Resource или @Inject, он автоматически находит требуемый bean-компонент в контейнере IoC и объединяет его со свойствами объекта.
При использовании @Autowired сначала запросите соответствующий тип bean-компонента в контейнере,
Вышеупомянутый процесс показывает, что аннотация @Autowired вводится в соответствии с типом сборки по умолчанию. По умолчанию она требует, чтобы зависимый объект существовал. Если ему разрешено иметь значение null, вы можете установить для его обязательного атрибута значение false. Если вы хотите передать инъекцию в соответствии с именем, вам необходимо объединить @ Квалификатор используется вместе;
3. Устраните неоднозначность автоматической сборки с помощью аннотации @Autowired.
Если в процессе использования аннотаций @Autowired возникает исключение NoUniqueBeanDefinitionException, это в основном связано с неоднозначностью, вызванной автоматической сборкой или другими методами сборки. То есть существует более двух классов реализации для интерфейса. То есть во время автоматической сборки может возникнуть тяжелая ситуация. NoUniqueBeanDefinitionException вызвано проблемой имени.
@Autowired собирается по типу, поэтому у меня есть интерфейс UserInterface с несколькими классами реализации
И так далее, эти классы реализации добавляются в контейнер Spring, когда в классе используется следующий оператор:
Ниже перечислены вышеупомянутые проблемы и аналогичные решения неоднозначности сборки.
Поскольку существует более двух классов реализации для интерфейса, проблема неоднозначности также может быть решена путем определения предпочтительного bean-компонента. Например:
В настоящее время, если имеется ссылка на внедрение класса реализации интерфейса IUserService, сначала внедряется класс аннотации @Promary, но на данный момент существует проблема. В классе реализации того же интерфейса вы можете использовать @Primary только один раз. Если для AImpl Используются как @primary, так и BImpl, и неоднозначность сборки по-прежнему будет возникать.В настоящее время рекомендуется использовать метод (1) для решения проблемы неоднозначности.
Метод третий
В последнем случае вы можете использовать специальные аннотации квалификаторов, но такая ситуация возникает редко, поэтому я не буду вводить ее снова, и вы можете использовать Baidu самостоятельно.
В-четвертых, какие функции Spring обеспечивает автоматическая сборка?
Spring реализует автоматизированную сборку с двух точек зрения:
Комбинация сканирования компонентов и автоматической сборки может быть мощной, и они могут свести к минимуму конфигурацию вашего дисплея.
В-пятых, разница между @Autowired и @Resource
В этой статье перечислены только общие поверхностные различия между @Autowired и @Resource.Что касается причины различия, вам необходимо проверить реализацию аннотации @Autowired в официальной документации Spring и реализацию аннотации @Resource в Java.
(1) @Autowired внедряется в соответствии со сборкой типа по умолчанию. По умолчанию для этого требуется, чтобы зависимый объект существовал. Если ему разрешено иметь значение null, вы можете установить для его обязательного атрибута значение false. Если вы хотите передать инъекцию в соответствии с именем, вам необходимо объединить @Qualifier использовать вместе;
(2) @Resource по умолчанию собирает инъекцию в соответствии с именем.Только когда не удается найти bean-компонент, соответствующий имени, инъекция собирается в соответствии с типом;
(3) аннотация @Resource предоставляется J2EE, а @Autowired предоставляется Spring, поэтому для уменьшения зависимости системы от Spring рекомендуется использовать @Resource;
(4) И @Resource, и @Autowired могут быть записаны и отмечены в поле или в методе установки поля.
(5) @Resource собирается в соответствии с именем по умолчанию. Когда bean-компонент, соответствующий имени, не найден, он будет собран в соответствии с типом, который можно указать с помощью атрибута name. Если атрибут имени не указан, когда аннотация отмечена в поле, поле берется по умолчанию Имя используется в качестве имени компонента для поиска зависимого объекта.Когда аннотация помечена в методе установки атрибута, имя атрибута используется в качестве имени компонента для поиска зависимого объекта по умолчанию. Примечание: если атрибут имени не указан, и зависимый объект не может быть найден в соответствии с именем по умолчанию В это время он вернется к сборке по типу, но как только атрибут name будет указан, его можно будет собрать только по имени.
В-шестых, как Spring запускает автоматическое сканирование
Вот три способа запустить автоматическое сканирование.
метод первый:В этом случае, для более особой ситуации, то есть в проекте используется SpringBoot, вы можете использовать аннотацию @SpringBootApplication для запуска функции автоматического сканирования.
Путь второй: В режиме конфигурации XML запустите функцию автоматического сканирования. Режим конфигурации XML.
Тег будет включать автоматическое сканирование Spring Beans и может установить атрибут base-package, что означает, что Spring будет сканировать все классы, оформленные @Component в этом каталоге и подкаталогах, и собирать их.
Путь третий: С помощью метода настройки Java запустите функцию автоматического сканирования.
Вот конкретный пример:
(2) @ComponentScan означает открытие сканирования Spring Beans, аналогично конфигурации XML, здесь вы также можете установить атрибут basePackages. Чтобы
Если аннотация @ComponentScan не показывает, чтобы присвоить значения другим атрибутам, например, присвоить значения базовым пакетам здесь, если нет, аннотация @ComponentScan будет сканировать пакеты с тем же классом конфигурации.
Что касается использования четырех аннотаций @Repository, @Service, @Controller и @Component
На уровне сохраняемости, бизнес-уровне и уровне управления @Repository, @Service и @Controller используются для аннотирования классов на уровне, а @Component используется для аннотирования более нейтральных классов. Это означает, что этот класс передан Spring для управления, а имя переименовано в userManager.Поскольку трудно сказать, к какому уровню принадлежит этот класс, используется @Component.
Семь, сколько методов сборки существует в Spring?
В настоящее время в Spring есть три метода сборки:
8. Использование @Autowired в @Configuration для аннотирования ошибок IDE.
заглавие
Java Blog
Spring IoC контейнер: конфигурация на основе аннотаций, использование @Autowired
Вы можете применить аннотацию @Autowired к конструкторам, как показано в следующем примере:
Начиная с Spring Framework 4.3, аннотация @Autowired для такого конструктора больше не требуется, если целевой бин для начала определяет только один конструктор. Однако, если доступно несколько конструкторов и нет основного/стандартного конструктора, по крайней мере один из конструкторов должен быть аннотирован @Autowired, чтобы указать контейнеру, какой из них использовать.
Вы также можете применить аннотацию @Autowired к традиционным методам установки, как показано в следующем примере:
Вы также можете применить аннотацию к методам с произвольными именами и несколькими аргументами, как показано в следующем примере:
Вы также можете применять @Autowired к полям и даже смешивать их с конструкторами, как показано в следующем примере:
Убедитесь, что ваши целевые компоненты (например, MovieCatalog или CustomerPreferenceDao) последовательно объявляются в соответствии с типом, который вы используете для точек внедрения, помеченных @Autowired. В противном случае внедрение может завершиться неудачей из-за ошибки «no type match found» («не найдено совпадение типов») во время выполнения.
Для определенных в XML компонентов или классов компонентов, найденных с помощью сканирования путей к классам, контейнер обычно заранее знает конкретный тип. Однако для фабричных методов @Bean необходимо убедиться, что объявленный тип возвращаемого значения достаточно выразителен. Для компонентов, которые реализуют несколько интерфейсов, или для компонентов, на которые потенциально может ссылаться их тип реализации, рассмотрите возможность объявления наиболее определенного типа возврата в фабричном методе (по крайней мере, настолько специфичном, как того требуют точки внедрения, ссылающиеся на ваш компонент).
Вы также можете указать Spring предоставить все компоненты определенного типа из ApplicationContext, добавив аннотацию @Autowired в поле или метод, который ожидает массив этого типа, как показано в следующем примере:
То же самое относится к типизированным коллекциям, как показано в следующем примере:
Ваши целевые bean-компоненты могут реализовать интерфейс org.springframework.core.Ordered или использовать аннотацию @Order или стандартную @Priority, если вы хотите, чтобы элементы в массиве или списке сортировались в определенном порядке. В противном случае их порядок следует порядку регистрации соответствующих определений целевого компонента в контейнере.
Вы можете объявить аннотацию @Order на уровне целевого класса и в методах @Bean, потенциально для отдельных определений бинов (в случае нескольких определений, использующих один и тот же класс бинов). Значения @Order могут влиять на приоритеты в точках внедрения, но имейте в виду, что они не влияют на порядок запуска синглтона, что является ортогональной проблемой, определяемой отношениями зависимостей и объявлениями @DependsOn.
Обратите внимание, что стандартная аннотация javax.annotation.Priority недоступна на уровне @Bean, поскольку она не может быть объявлена в методах. Ее семантика может быть смоделирована с помощью значений @Order в сочетании с @Primary для одного компонента для каждого типа.
По умолчанию автоматическое подключение завершается ошибкой, когда для данной точки внедрения отсутствуют подходящие подходящие компоненты. В случае объявленного массива, коллекции или карты ожидается, по крайней мере, один соответствующий элемент.
Поведение по умолчанию состоит в том, чтобы рассматривать аннотированные методы и поля как указывающие на необходимые зависимости. Вы можете изменить это поведение, как показано в следующем примере, позволяя платформе пропускать недопустимую точку внедрения, помечая ее как необязательную (т. е. устанавливая обязательный атрибут в @Autowired равным false):
Необязательный метод вообще не будет вызываться, если его зависимость (или одна из его зависимостей в случае нескольких аргументов) недоступна. В таких случаях необязательное поле не заполняется вообще, а его значение по умолчанию остается на месте.
Только один конструктор из любого заданного класса bean-компонента может объявить @Autowired с обязательным атрибутом, установленным в true, что указывает на конструктор для автоматической передачи при использовании в качестве Spring-компонента. Как следствие, если для обязательного атрибута оставлено значение по умолчанию true, только один конструктор может быть аннотирован @Autowired. Если несколько конструкторов объявляют аннотацию, все они должны будут объявить required=false, чтобы их можно было рассматривать в качестве кандидатов на автопривязку (аналог autowire=constructor в XML). Будет выбран конструктор с наибольшим количеством зависимостей, который может быть удовлетворен путем сопоставления bean-компонентов в контейнере Spring. Если ни один из кандидатов не может быть удовлетворен, то будет использоваться основной/заданный по умолчанию конструктор (если имеется). Точно так же, если класс объявляет несколько конструкторов, но ни один из них не аннотирован @Autowired, то будет использоваться основной/заданный по умолчанию конструктор (если имеется). Если класс для начала объявляет только один конструктор, он всегда будет использоваться, даже если он не аннотирован. Обратите внимание, что аннотированный конструктор не должен быть публичным.
Обязательный атрибут @Autowired рекомендуется использовать вместо устаревшей аннотации @Required в методах установки (сеттеры). Установка для обязательного атрибута значения false указывает, что свойство не требуется для целей автоматической привязки, и свойство игнорируется, если оно не может быть автоподключено. @Required, с другой стороны, сильнее в том смысле, что заставляет свойство устанавливать любые средства, поддерживаемые контейнером, и, если значение не определено, возникает соответствующее исключение.
Кроме того, вы можете выразить необязательный характер конкретной зависимости через java.util.Optional Java 8, как показано в следующем примере:
Вы также можете использовать @Autowired для интерфейсов, которые являются хорошо известными разрешаемыми зависимостями: BeanFactory, ApplicationContext, Environment, ResourceLoader, ApplicationEventPublisher и MessageSource. Эти интерфейсы и их расширенные интерфейсы, такие как ConfigurableApplicationContext или ResourcePatternResolver, автоматически разрешаются без специальной настройки. Следующий пример автоматически связывает объект ApplicationContext:
Аннотации @Autowired, @Inject, @Value и @Resource обрабатываются реализациями Spring BeanPostProcessor. Это означает, что вы не можете применять эти аннотации в ваших собственных типах BeanPostProcessor или BeanFactoryPostProcessor (если есть). Эти типы должны быть явно подключены с использованием XML или метода Spring @Bean.
Аннотация @Autowired: что к чему?
Решил рассказать немного про аннотацию @Autowired. Принцип её работы очень прост.
Допустим у нас есть bean-зависимости:
И есть класс сервиса:
И при создании контекста Spring автоматически определит, что для создания MyService требуется bean типа ServiceDependency (или наследник), найдёт его у себя, в рамках подставит зависимость ServiceDependencyImpl в bean MyService.
На самом деле, начиная со Spring 4.0 аннотацию @Autowired можно не ставить на конструктор, если он единственный в классе.
Другие варианты использования аннотации
@Autowired можно ставить непосредственно на поле. Да-да, это будет работать и с private-полями:
Также аннотацию можно ставить на сеттеры:
Но можно так же ставить и на отдельные методы, например:
Что ещё?
Предположим, что бинов типа ServiceDependency несколько (допустим dependency1 и dependency2). Тогда, чтобы задать конкретный bean, необходимо использовать аннотацию @Qualifier:
А если мы захотим использовать все бины?
Сделать это можно простым способом:
И Spring вставит (удивительно) все бины, реализующие интерфейс ServiceDependency. То же самое верно и для типизированных коллекций. Как ни странно, но порядком следования в этой коллекции можно управлять с помощью аннотации @Order.
Но самое замечательное, вот это:
Spring автоматически подставит не только сами бины, но и имена бинов в качестве ключей. Это может быть эффективно использовано, например, в паттерне «стратегия».
Есть вопрос? Напишите в комментариях!
Урок 2: Введение в Spring IoC контейнер
Этот урок освещает работу с Spring Framework IoC контейнером и основан на оригинальной документации §5. The IoC container.
Что вы создадите
Вы создадите некоторое количество классов, в которых будет рассмотрена функциональность Spring Framework IoC контейнера.
Что вам потребуется
Настройка проекта
Введение
Inversion of Control (IoC), также известное как Dependency Injection (DI), является процессом, согласно которому объекты определяют свои зависимости, т.е. объекты, с которыми они работают, через аргументы конструктора/фабричного метода или свойства, которые были установлены или возвращены фабричным методом. Затем контейнер inject(далее «внедряет») эти зависимости при создании бина. Этот процесс принципиально противоположен, поэтому и назван Inversion of Control, т.к. бин сам контролирует реализацию и расположение своих зависимостей, используя прямое создание классов или такой механизм, как шаблон Service Locator.
Описание работы IoC контейнера
ApplicationContext представляет собой Spring IoC контейнер и необходим для инициализации, настройки и сборки бинов для построения приложения.
В метаданных конфигурации разработчик описывает как инициализировать, настроить IoC контейнер и собрать объекты в вашем приложении. В данном и других уроках этого цикла везде, где возможно, будет использоваться подход на основе аннотаций и Java-конфигурации. Если вы сторонник XML-конфигурации, либо хотите посмотреть как делать тоже самое через XML, обратитесь к оригинальной документации по Spring Framework или соответствующего модуля/проекта.
Настройка IoC контейнера
Как вариант, можно инициализировать контекст(ы) таким образом:
Использование @Bean аннотации
Теперь, для того, чтобы объект с типом GreetingService был доступен для использования, необходимо описать его в конфигурации следующим образом:
А для того, чтобы использовать его, достаточно выполнить следующее:
Метод getBean() может принимать в качестве аргумента как класс(как показано выше), так и названия бина(подробнее будет рассмотрено ниже), либо другие варианты, с которыми вы можете ознакомится в документации. Однако такой подход не рекомендуется использовать в production-конфигурациях, т.к. для подобных целей существует механизм Dependency Injection (DI), собственно говоря, для чего и предназначен Spring IoC контейнер. Использование DI будет рассмотрено ниже в отдельной главе.
Иногда полезно предоставить более подробное описание бина, например, в целях мониторинга. Для этого существует аннотация @Description :
Жизненный цикл бина
При совместном использовании методов, интерфейсов и аннотаций, описанных выше, учитывайте их порядок вызовов. Для методов инициализации порядок будет следующий:
Для методов разрушения порядок будет следующий:
Если вам необходимо реализовать свою собственную модель жизненного цикла бина, то в таком случае бин должен реализовывать один из интерфейсов, приведенных ниже:
После этого у вас появятся результаты работы методов при разрушении бина. Однако стоит заметить ещё раз, что это относится к обычным приложения, не относящимся к web-приложения(поскольку для них применяется отдельный тип контекста и подобный метод в них уже есть).
Области видимости(scopes) бинов
Когда вы создаете определение бинов, вы вы создаете рецепт для создания экземпляров класса, который определяет бин. Важно понять, что определение бинов является рецептом, потому что он означает, какого класса вы можете создать множество экземпляров по этому рецепту.
Использование @Configuration аннотации
Кода бин имеет зависимость от другого бина, то зависимость выражается просто как вызов метода:
В большинстве случаев, имеются такие случаи, когда бин в одной конфигурации имеет зависимость от бина в другой конфигурации. Поскольку конфигурация является источником определения бинов, то разрешить такую зависимость не является проблемой, достаточно объявить поле класса конфигурации с аннотацией @Autowired (более подробно оисано в отдельной главе):
При этом LessonsConfiguration остается без изменений:
Процесс разрешения зависимостей
IoC контейнер выполняет разрешение зависимостей бинов в следующем порядке:
Spring контейнер может разрешать зависимости между бинами через autowiring(далее, автоматическое связывание). Данный механизм основан на просмотре содержимого в ApplicationContext и имеет следующие преимущества:
Соответственно, у одной из реализации GreetingService должна быть установлена соответствующая аннотация @Qualifier :
Spring также поддерживает использование JSR-250 @Resource аннотации автоматического связывания для полей класса или параметров setter-методов:
Использование стандартных JSR-330 аннотаций
Spring Framework поддерживает JSR-330 аннотации. Эти аннотации работают таким же способом, как и Spring аннотации. Для того, чтобы работать с ними, необходимо добавить в pom.xml следующую зависимость:
Ниже приведена таблица сравнения JSR-330 и Spring аннотаций для DI: