Сьогодні я обговорював із колегами, чи варто використовувати комбінацію @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-біна для внесення змін. Наприклад, іноді створення бобів потрібно співпрацювати з @Scope або @Profile, і лише змінювати клас конфігурації.
Одиночне завдання
@service сама анотація передбачає дві відповідальності:
Одна з них — створення квасолі;
Друга — ідентифікувати клас як послугу.
Вказує, що анотований клас є «Сервісом», спочатку визначеним як Domain-Driven
Design (Evans, 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
|
|
|
