Сегодня я обсудил с коллегами, стоит ли использовать комбинацию @Configuration и @Bean для создания бобов в Spring Boot или использовать @Service и другие аннотации непосредственно на занятии. Автор обычно использует первый вариант, то есть сочетание @Configuration и @Bean.
Давайте сначала рассмотрим пример: цель — создать «боб» для SearchService.
Используйте @Service напрямую:
Запусти приложение, доступ к браузеру: http://localhost:8081/search?q=koly, отображение страницы: ["hello", "koly"]
Способы использования @Configuration и @Bean:
По сравнению с прямым использованием @Service кода, существует класс AppConfig, который удаляет @Service аннотаций, размещённых поверх ElasticSearchServiceImpl. На первый взгляд, там больше кода и классов. Так в чём же преимущества использования второго?
Автор считает, что преимущества таковы:
Разделение вопросов
Используя методы @Configuration и @Bean, создание зёрен происходит в одном месте, и интерфейс и его реализация никак не связаны с созданием зерна.
Если нужно изменить создание зерна, то достаточно просто просмотреть и изменить соответствующий класс конфигурации, и не нужно обращаться к соответствующему Java-bean для внесения изменений. Например, иногда создание бобов требует сотрудничества с @Scope или @Profile, и нужно изменить только класс конфигурации.
Одноразовая служба
@service сама аннотация подразумевает две функции:
Одна из них — создание фасоли;
Вторая — определить класс как услугу.
Указывает, что аннотированный класс — это «Сервис», изначально определённый как доменно-управляемый
Дизайн (Эванс, 2003) как «операция, предлагаемая как интерфейс, который стоит самостоятельно в модели, без инкапсулированного состояния».
Выше приведено объяснение Спринга @Service аннотации. Этот is@Service на самом деле представляет собой бессостоятельную, независимую операцию интерфейса в DDD.
В рамках сотрудничества @Bean и @Configuration создание бобов передаётся отдельному классу, а идентичность сервиса — интерфейсу и имя класса на Java. Это также отражено в Spring Data, таких как Repository, который идентифицируется по названию, например, CrudRepository. Таким образом, Сервис также отражается в названии. Специфические иерархические определения могут использоваться для предоставления дополнительных слоёв в зависимости от названия проекта без использования аннотаций, предоставленных Spring, таких как слой Mapper, слой Validator и др.
Кроме того, боб и сервис — это двумерные понятия. Один — о конкретной реализации, другой — о концепциях в DDD.
Более гибко
Используя @Bean методы, вы можете создавать экземпляры классов в библиотеке. Если вы используете метод @Service, вы не сможете добавить @Service комментариев к соответствующим классам в библиотеке.
Наименьшее знание
Принцип минимальных знаний означает:
Чем меньше технологий или знаний требуется для выполнения функции, тем лучше, чтобы обеспечить простоту проекта и снизить сложность освоения проекта.
Поскольку нельзя создавать экземпляры классов в библиотеке классов с помощью @Service, при возникновении аналогичных потребностей нужно использовать форму @Configuration и @Bean. На этом этапе в проекте есть аннотации, такие как @Service, @Configuration и @Bean, и эти аннотации делают то же самое — то есть создают зерно.
С @Service существует высокая вероятность одновременного @Service, @Component, @Configuration и @Bean.
при этом использование @Configuration и @Bean может полностью исключить использование @Service и @Component, что соответствует принципу минимальных знаний.
Наконец, кстати, Spring Beans были созданы в xml и позже использовали Java для конфигурации. Основная причина отказа от использования XML заключается в том, что он недостаточно лаконичен и не содержит таких функций, как проверка времени компиляции, а не необходимость распределения создания зерен между классами.
В итоге автор предпочитает использовать @Configuration и @Bean методы. |
Опубликовано 30.08.2018 13:29:41
|
|
|
