Šiandien su kolegomis aptariau, ar naudoti @Configuration ir @Bean derinį, kad sukurtumėte pupeles "Spring Boot", ar naudoti @Service ir kitas anotacijas tiesiogiai klasėje. Autorius linkęs naudoti pirmąjį, tai yra @Configuration ir @Bean derinį.
Pirmiausia pažvelkime į pavyzdį, tikslas yra sukurti "SearchService" pupelę.
Naudokite @Service tiesiogiai:
Paleiskite programą, naršyklės prieiga: http://localhost:8081/search?q=koly, puslapio rodymas: ["hello", "koly"]
@Configuration ir @Bean naudojimo būdai:
Palyginti su tiesioginiu @Service kodo naudojimu, yra "AppConfig" klasė, kuri pašalina @Service komentarus, esančius ant "ElasticSearchServiceImpl". Iš pirmo žvilgsnio yra daugiau kodo ir klasių. Taigi, kokie yra pastarojo naudojimo pranašumai?
Autorius mano, kad nauda yra:
Susirūpinimą keliančių klausimų atskyrimas
Naudojant @Configuration ir @Bean metodus, pupelės kuriamos vienoje vietoje, o sąsaja ir jos įgyvendinimas neturi nieko bendra su pupelių kūrimu.
Jei pupelės kūrimą reikia pakeisti, jums tereikia peržiūrėti ir modifikuoti atitinkamą konfigūracijos klasę, o norint atlikti pakeitimus, nereikia eiti į atitinkamą "Java" pupelę. Pavyzdžiui, kartais pupelių kūrimą reikia bendradarbiauti su @Scope ar @Profile ir tik modifikuoti konfigūracijos klasę.
Vienkartinis muitas
@service pati anotacija prisiima dvi pareigas:
Vienas iš jų yra pupelių kūrimas;
Antrasis – identifikuoti klasę kaip paslaugą.
Nurodo, kad anotuota klasė yra "Paslauga", iš pradžių apibrėžta "Domain-Driven"
Dizainas (Evans, 2003) kaip "operacija, siūloma kaip sąsaja, kuri stovi atskirai modelyje, be kapsuliuotos būsenos".
Aukščiau yra pavasario paaiškinimas @Service anotacijas. Ši is@Service iš tikrųjų reiškia nepriklausomą DDD sąsajos operaciją be būsenos.
@Bean ir @Configuration bendradarbiavimo būdu pupelių kūrimas perduodamas atskirai klasei, o paslaugos tapatybė perduodama sąsajai ir klasės pavadinimui Java. Tai taip pat atsispindi pavasario duomenyse, pvz., saugykloje, kuri identifikuojama pagal pavadinimą, pvz., CrudRepository. Todėl paslauga taip pat atsispindi pavadinime. Konkretūs hierarchijos apibrėžimai gali būti naudojami norint pateikti daugiau sluoksnių pagal projekto pavadinimą, nepasikliaujant pavasario pateiktais komentarais, tokiais kaip Mapper sluoksnis, Validatoriaus sluoksnis ir kt.
Be to, pupelės ir paslauga yra dvimatės sąvokos. Vienas apie konkretų įgyvendinimą, o kitas apie DDD koncepcijas.
Lankstesnis
Naudodami @Bean metodus, bibliotekoje galite sukurti klasių egzempliorius. Jei naudosite @Service metodą, negalėsite pridėti @Service komentarų prie atitinkamų bibliotekos klasių.
Mažiausiai žinių
Minimalių žinių principas reiškia:
Kuo mažiau technologijų ar žinių reikia funkcijai atlikti, tuo geriau, kad būtų užtikrintas projekto paprastumas ir sumažėtų projekto mokymosi sunkumai.
Kadangi klasių bibliotekoje neįmanoma sukurti klasių egzempliorių naudojant @Service, susidūrę su panašiais poreikiais turite naudoti @Configuration ir @Bean formą. Šiuo metu visame projekte yra anotacijų, tokių kaip @Service, @Configuration ir @Bean, ir šios anotacijos daro tą patį, t. y. sukuria pupelę.
Su @Service yra didelė tikimybė @Service, @Component, @Configuration ir @Bean vienu metu.
Naudojant @Configuration ir @Bean galima visiškai pašalinti @Service ir @Component naudojimą, o tai atitinka minimalių žinių principą.
Galiausiai, beje, pavasario pupelės buvo sukurtos xml formatu, o vėliau konfigūravimui buvo naudojama Java. Pagrindinė priežastis, kodėl nenaudojamas XML, yra ta, kad jis nėra pakankamai glaustas ir neturi tokių funkcijų kaip kompiliavimo laiko tikrinimas, o ne poreikis paskirstyti pupelių kūrimą tarp klasių.
Apibendrinant galima pasakyti, kad autorius nori naudoti @Configuration ir @Bean metodus. |
Paskelbta 2018-08-30 13:29:41
|
|
|
