Dziś rozmawiałem z kolegami, czy użyć kombinacji @Configuration i @Bean do tworzenia ziaren w Spring Boot, czy użyć @Service i innych adnotacji bezpośrednio na zajęciach. Autor zwykle używa pierwszego, czyli połączenia @Configuration i @Bean.
Przyjrzyjmy się najpierw przykładowi, celem jest stworzenie fasolki dla SearchService.
Używaj @Service bezpośrednio:
Uruchom aplikację, dostęp do przeglądarki: http://localhost:8081/search?q=koly, wyświetlanie strony: ["hello", "koly"]
Sposoby korzystania z @Configuration i @Bean:
W porównaniu do bezpośredniego użycia @Service kodu, istnieje klasa AppConfig, która usuwa @Service adnotacji umieszczonych na ElasticSearchServiceImpl. Na pierwszy rzut oka jest więcej kodu i klas. Jakie są więc korzyści z używania tego drugiego?
Autor uważa, że korzyści to:
Rozdzielenie interesów
Stosując metody @Configuration i @Bean, tworzenie ziaren odbywa się w jednym miejscu, a interfejs i jego implementacja nie mają nic wspólnego z tworzeniem ziaren.
Jeśli trzeba zmienić sposób tworzenia ziarna, wystarczy zobaczyć i zmodyfikować odpowiednią klasę Konfiguracji, a nie trzeba wchodzić do odpowiedniego ziarna Java, aby wprowadzać zmiany. Na przykład czasem tworzenie fasoli wymaga współpracy z @Scope lub @Profile, a jedynie modyfikacja klasy Konfiguracja.
Służba jednoosobowa
@service samo adnotowanie obejmuje dwie funkcje:
Jedną z nich jest tworzenie fasoli;
Drugim jest zidentyfikowanie klasy jako usługi.
Wskazuje, że klasa adnotowana jest "Usługą", pierwotnie zdefiniowaną przez Domain-Driven
Projekt (Evans, 2003) jako "operacja oferowana jako interfejs, który stoi samodzielnie w modelu, bez stanu zamkniętego."
Powyżej znajduje się wyjaśnienie @Service adnotacji Springa. Ten is@Service faktycznie reprezentuje bezstanową, niezależną operację interfejsu w DDD.
W ramach współpracy @Bean i @Configuration, tworzenie fasoli przekazywane jest osobnej klasie, a tożsamość usługi przekazywana jest interfejsowi i nazwie klasy w Javie. Odzwierciedla to również Spring Data, na przykład Repository, który jest identyfikowany nazwą, na przykład CrudRepository. Dlatego Służba również odzwierciedla nazwę. Specyficzne definicje hierarchii mogą być używane do udostępniania większej liczby warstw według nazwy projektu, bez polegania na adnotacjach dostarczanych przez Spring, takich jak warstwa Mapper, warstwa Validator itp.
Ponadto fasola i usługa to pojęcia dwuwymiarowe. Jeden dotyczy konkretnej implementacji, a drugi koncepcji w DDD.
Bardziej elastyczna
Korzystając z @Bean metod, możesz tworzyć instancje klas w bibliotece. Jeśli użyjesz metody @Service, nie będziesz mógł dodawać @Service komentarzy do odpowiednich klas w bibliotece.
Najmniejsza wiedza
Zasada minimalnej wiedzy oznacza:
Im mniej technologii lub wiedzy potrzebnej do wykonania zadania, tym lepiej, aby zapewnić prostotę projektu i zmniejszyć trudność w nauce projektu.
Ponieważ nie jest możliwe tworzenie instancji klas w bibliotece klas za pomocą @Service, trzeba używać formy @Configuration i @Bean, gdy napotykamy podobne potrzeby. W tym momencie w całym projekcie pojawiają się adnotacje takie jak @Service, @Configuration i @Bean, które robią to samo, czyli tworzą fasolę.
Przy @Service istnieje duże prawdopodobieństwo jednoczesnego @Service, @Component, @Configuration i @Bean.
natomiast stosowanie @Configuration i @Bean może całkowicie wyeliminować użycie @Service i @Component, co jest zgodne z zasadą minimalnej wiedzy.
Na koniec, przy okazji, Spring Beans zostały stworzone w xml, a później użyto Java do konfiguracji. Głównym powodem braku użycia XML jest brak wystarczająco zwięzłego formatu i brak funkcji takich jak kontrola w czasie kompilacji, a nie konieczność rozłożenia tworzenia ziaren między klasami.
Podsumowując, autor woli stosować metody @Configuration i @Bean. |
Opublikowano 30.08.2018 13:29:41
|
|
|
