Danes sem se s kolegi pogovarjal, ali naj uporabim kombinacijo @Configuration in @Bean za ustvarjanje fižol v Spring Boot ali pa uporabim @Service in druge opombe neposredno na tečaju. Avtor običajno uporablja prvo, torej kombinacijo @Configuration in @Bean.
Poglejmo si najprej primer, cilj je ustvariti zrno za SearchService.
Uporabite @Service neposredno:
Zaženi aplikacijo, dostop do brskalnika: http://localhost:8081/search?q=koly, prikaz strani: ["hello", "koly"]
Načini uporabe @Configuration in @Bean:
V primerjavi z neposredno uporabo @Service kode obstaja razred AppConfig, ki odstrani @Service opomb, nameščenih nad ElasticSearchServiceImpl. Na prvi pogled je več kode in razredov. Kakšne so torej prednosti uporabe slednjega?
Avtor meni, da so prednosti:
Ločitev skrbi
Z uporabo metod @Configuration in @Bean je ustvarjanje zrn vse na enem mestu, vmesnik in njegova izvedba pa nimata nobene zveze z ustvarjanjem zrna.
Če je treba spremeniti ustvarjanje zrna, potem morate le pogledati in spremeniti ustrezni razred Configuration in ni treba iti v ustrezni Java bean, da bi naredili spremembe. Na primer, včasih je treba ustvarjanje fižola sodelovati s @Scope ali @Profile, in je treba spremeniti le razred Configuration.
Posamezna naloga
@service samo označevanje prevzema dve odgovornosti:
Ena je ustvarjanje fižola;
Druga je identifikacija razreda kot storitve.
Označuje, da je anotirani razred "storitev", prvotno definirana z domensko vodeno metodo
Oblikovanje (Evans, 2003) kot "operacija, ponujena kot vmesnik, ki stoji samostojno v modelu, brez kapsuliranega stanja."
Zgoraj je Springova razlaga @Service opomb. Ta is@Service dejansko predstavlja brezstanjsko, neodvisno vmesniško operacijo v DDD.
Na način sodelovanja @Bean in @Configuration se ustvarjanje fižolov prenese na ločen razred, identiteta storitve pa na vmesnik in ime razreda v Javi. To se odraža tudi v Spring Data, kot je Repository, ki je označen po imenu, na primer CrudRepository. Zato se storitev odraža tudi v imenu. Specifične definicije hierarhije se lahko uporabijo za zagotavljanje več plasti glede na ime projekta brez zanašanja na oznake, ki jih zagotavlja Spring, kot so plast Mapper, plast Validator itd.
Poleg tega sta fižol in storitev dvodimenzionalna pojma. Ena o konkretni implementaciji, druga pa o konceptih v DDD.
Bolj prilagodljiva
Z uporabo @Bean metod lahko ustvarite instance razredov v knjižnici. Če uporabite metodo @Service, ne boste mogli dodajati @Service komentarjev ustreznim razredom v knjižnici.
Najmanjše znanje
Načelo minimalnega znanja pomeni:
Manj tehnologije ali znanja kot je potrebnih za izvedbo funkcije, bolje je, da se zagotovi preprostost projekta in zmanjša težavnost učenja projekta.
Ker ni mogoče ustvariti primerkov razredov v knjižnici razredov z uporabo @Service, morate pri podobnih potrebah uporabiti obliko @Configuration in @Bean. V tem trenutku so v celotnem projektu prisotne opombe, kot so @Service, @Configuration in @Bean, ki počnejo isto, torej ustvarijo zrno.
Pri @Service obstaja velika verjetnost, da se hkrati @Service, @Component, @Configuration in @Bean.
medtem ko uporaba @Configuration in @Bean popolnoma odpravi uporabo @Service in @Component, kar je v skladu z načelom minimalnega znanja.
Mimogrede, Spring Beans so bili ustvarjeni v xml formatu in kasneje uporabljeni v Javi za konfiguracijo. Glavni razlog za neuporabo XML je, da ni dovolj jedrnat in nima funkcij, kot je preverjanje med prevajanjem, namesto potrebe po razdelitvi ustvarjanja fižol med razrede.
Za povzetek, avtor raje uporablja @Configuration in @Bean metode. |
Objavljeno na 30. 08. 2018 13:29:41
|
|
|
