Сегодня я обсуждал с моими коллегами, использовать ли комбинацию @Configuration и @Bean для создания боба или непосредственно использовать @Service и другие аннотации для размещения его в классе. Автор имеет тенденцию использовать первый тип, а именно комбинацию @configuration и @bean.
Давайте сначала посмотрим на пример, цель состоит в том, чтобы создать бобы поискового сервиса.
Напрямую используйте @Service:
// searchservice.javapackage li.koly.search; import java.util.list; public interface searchservice {list <object> search (string q);} // elasticsearchserviceimpl.javapackage li.koly.search; импорт org.spramework.sertioty.service; java.util.list; @ServiceComponentPublic Class ElasticSearchServiceImpl реализует SearchService {@Override Public List <object> Search (String Q) {return Arrays.aslist ("hello", q); }} // application.javapackage li.koly.search; import org.springframework.beans.factory.annotation.autowired; импорт org.springframework.boot.springapplication; импорт org.springframework.boot.autoconfigure.springbplication; org.springframework.web.bind.annotation.getMaping; импорт org.springframework.web.bindtation.restcontroller; import java.util.list;@Springbootapplication@RestControllerPublic Class Application {@autowired Private SearchService SearchService; @Getmapping ("/search") public list <object> hello (string q) {return searchservice.search (q); } public static void main (string [] args) {springApplication.run (application.class, args); }}Приложение для начала, доступ к браузеру: http: // localhost: 8081/search? Q = Koly, дисплей страницы: ["Привет", "Коли"]
Как использовать @configuration и @bean:
// elasticsearchserviceimpl.javapackage li.koly.search; import java.util.arrays; import java.util.list; открытый класс ElasticSearchServiceImpl реализует searchService {@Override public list <object> search (string q) {returns.asslist ("quell", Q); }}// AppConfig.javapackage li.koly.search;import org.springframework.context.annotation.Bean;import org.springframework.context.annotation.Configuration;@Configurationpublic class AppConfig { @Bean public SearchService searchService() { return new ElasticSearchServiceImpl(); }}По сравнению с кодом, который непосредственно использует @Service, есть класс AppConfig, и аннотация @Service, размещенная на ElasticSearchServiceImpl, удаляется. На первый взгляд, есть больше кодов и классов. Так каковы преимущества использования последнего?
Автор считает, что преимущества:
Разделение проблем
Используя @Configuration и @Bean, создание бобов помещено в одном месте, а интерфейс и его реализация не имеют ничего общего с созданием бобов.
Если необходимо изменить создание бобов, то вам нужно только просмотреть и изменить соответствующий класс конфигурации, и вам не нужно перейти в соответствующий боб Java для изменений. Например, иногда создание бобов требует сотрудничества с @scope или @profile, и вам нужно только изменить класс конфигурации в настоящее время.
Единственная ответственность
Сама аннотация @Service принимает на себя две обязанности:
Одним из них является создание бобов;
Второе - идентифицировать класс как услугу.
Указывает, что аннотированный класс-это «сервис», первоначально определяемый доменным управлением
Дизайн (Evans, 2003) как «операция, предлагаемая как интерфейс, который стоит в одиночестве в модели, без инкапсулированного состояния».
Вышеупомянутое объяснение аннотации @Service. То есть @Service фактически представляет собой бессмысленную, независимую операцию, представленную в DDD.
Используя метод @Bean и @Configuration, создание бобов передается отдельному классу, а личность сервиса передается интерфейсу и названию класса в Java. Это также отражается в данных Spring. Например, репозиторий идентифицируется по имени, таким как Crudrepository. Следовательно, обслуживание также отражается на его названии. Конкретное определение иерархии через имя, не полагаясь на аннотации, предоставленные весной, удобно для обеспечения большего количества иерархий в соответствии с проектом, таких как слой Mapper, слой валидатора и т. Д.
Кроме того, бобы и обслуживание - два измерения. Один рассказывает о конкретной реализации, а другой о концепциях в DDD.
Более гибкий
Используя @Bean, вы можете создавать экземпляры классов в библиотеке. Если вы используете @Service, вы не можете добавить аннотацию @Service в соответствующий класс в библиотеке.
наименьшие знания (минимальный принцип знания)
Минимальный принцип знания означает:
Чем меньше технологии или знания необходимы для выполнения функции, тем лучше, чтобы гарантировать, что проект будет прост и уменьшил сложность изучения проекта.
Поскольку использование @Service не может создать экземпляр класса в библиотеке классов, при столкновении с аналогичными требованиями вы должны использовать форму @Configuration и @Bean. В настоящее время, такие аннотации, как @Service, @Configuration и @Bean, существуют во всем проекте одновременно, и то, что делают эти аннотации, одинаковы, то есть создание бобов.
С @Service очень вероятно, что @Service, @Component, @Configuration и @Bean будут существовать одновременно.
При использовании @Configuration и @Bean вы можете полностью игнорировать @Service и @Component, что соответствует принципу минимальных знаний.
Наконец, кстати, Spring's Bean был создан в XML раньше, и Java использовалась для конфигурации позже. Основная причина не использования XML заключается в том, что XML не является достаточно кратким и не имеет никаких функций, таких как проверка времени компиляции, а не разбросание создания бобов в различные классы.
Таким образом, автор предпочитает использовать @configuration и @bean.
Выше всего содержание этой статьи. Я надеюсь, что это будет полезно для каждого обучения, и я надеюсь, что все будут поддерживать Wulin.com больше.