Днес обсъдих с колегите си дали да използвам комбинация от @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 методи, създаването на зърна е на едно място, а интерфейсът и неговата реализация нямат нищо общо със създаването на зърна.
Ако създаването на bean трябва да се промени, тогава трябва само да прегледате и промените съответния клас на конфигурация, и не е нужно да отивате в съответния Java bean, за да правите промени. Например, понякога създаването на зърна трябва да се сътрудничи с @Scope или @Profile и трябва само да се модифицира класът Конфигурация.
Еднократна служба
@service самата анотация поема две отговорности:
Едната е създаването на боб;
Вторият е да се идентифицира класът като услуга.
Показва, че анотиран клас е "Услуга", първоначално дефинирана чрез Domain-Driven
Design (Evans, 2003) като "операция, предлагана като интерфейс, която стои самостоятелно в модела, без капсулирано състояние."
По-горе е обяснението на Спринг за @Service анотации. Тази is@Service всъщност представлява безсъстояние, независима интерфейсна операция в DDD.
В рамките на @Bean и @Configuration сътрудничество, създаването на beans се предава на отделен клас, а идентичността на Service се предава на интерфейса и името на класа в 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 ч.
|
|
|
