|
|
Julkaistu 30.8.2018 13.29.41
|
|
|
Tänään keskustelin kollegoideni kanssa siitä, pitäisikö Spring Bootissa käyttää @Configuration:n ja @Bean:n yhdistelmää papujen luomiseen vai käyttää @Service ja muita merkintöjä suoraan kurssilla. Kirjoittaja käyttää yleensä ensimmäistä, eli yhdistelmää @Configuration ja @Bean.
Katsotaanpa ensin esimerkkiä, tavoitteena on luoda SearchServicelle papu.
Käytä @Service suoraan:
Käynnistä sovellus, selaimen käyttö: http://localhost:8081/search?q=koly, sivun näyttö: ["hello", "koly"]
Tapoja käyttää @Configuration ja @Bean:
Verrattuna suoraan @Service koodin käyttöön, on olemassa AppConfig-luokka, joka poistaa @Service merkinnät, jotka on asetettu ElasticSearchServiceImplin päälle. Yhdellä vilkaisulla siinä on enemmän koodia ja kursseja. Mitkä ovat jälkimmäisen käytön hyödyt?
Kirjoittajan mukaan hyödyt ovat:
Yritysten erottelu
@Configuration ja @Bean menetelmillä papujen valmistus tapahtuu yhdessä paikassa, eikä käyttöliittymällä ja sen toteutuksella ole mitään tekemistä pavun valmistuksen kanssa.
Jos pavun luomista täytyy muuttaa, sinun tarvitsee vain katsoa ja muokata vastaavaa Konfiguraatioluokkaa, eikä sinun tarvitse mennä vastaavaan Java-papuun tehdäksesi muutoksia. Esimerkiksi joskus papujen luomisessa täytyy tehdä yhteistyötä @Scope:n tai @Profile:n kanssa, ja muuta vain konfiguraatioluokkaa.
Yksittäinen tehtävä
@service annotaatio itsessään ottaa kaksi vastuuta:
Yksi on papujen valmistus;
Toinen on tunnistaa luokka palveluksi.
Tarkoittaa, että annotoitu luokka on "palvelu", joka alun perin määriteltiin Domain-Driven avulla
Design (Evans, 2003) "operaationa, joka tarjotaan mallissa itsenäisenä rajapintana, ilman kapseloitua tilaa."
Yllä on Springin selitys @Service annotaatioista. Tuo is@Service edustaa itse asiassa tilatonta, itsenäistä rajapintatoimintoa DDD:ssä.
@Bean ja @Configuration yhteistyössä papujen luominen siirtyy erilliselle luokalle, ja palvelun identiteetti siirtyy rajapinnalle ja luokan nimelle Javalla. Tämä näkyy myös Spring Datassa, kuten Repositoryssa, joka tunnistetaan nimellä, kuten CrudRepository. Siksi myös nimi heijastaa Palvelua. Erityisiä hierarkiamääritelmiä voidaan käyttää lisäämään lisää kerroksia projektin nimen mukaan ilman, että tarvitsee luottaa Springin annotaatioihin, kuten Mapper-kerros, Validator-kerros jne.
Lisäksi pavu ja palvelu ovat kaksiulotteisia käsitteitä. Toinen konkreettisesta toteutuksesta ja toinen DDD:n käsitteistä.
Joustavampi
@Bean metodeilla voit luoda luokkien instansseja kirjastoon. Jos käytät @Service-menetelmää, et voi lisätä @Service kommentteja vastaaviin luokkiin kirjastossa.
Vähiten tietoa
Minimitiedon periaate tarkoittaa:
Mitä vähemmän teknologiaa tai tietoa tehtävän suorittamiseen tarvitaan, sitä parempi, jotta projektin yksinkertaisuus varmistetaan ja oppimisen vaikeus vähenee.
Koska luokkakirjastoon ei voi luoda luokkien instansseja @Service:n avulla, sinun täytyy käyttää @Configuration- ja @Bean-muotoja, kun kohtaat samanlaisia tarpeita. Tässä vaiheessa koko projektissa on merkintöjä kuten @Service, @Configuration ja @Bean, ja nämä annotaatiot tekevät samaa, eli luovat pavun.
@Service:n kanssa on suuri todennäköisyys, että @Service, @Component, @Configuration ja @Bean samanaikaisesti.
@Configuration ja @Bean voi täysin poistaa @Service ja @Component käytön, mikä on linjassa minimitiedon periaatteen kanssa.
Lopuksi, muuten, kevätpavut luotiin xml:llä ja myöhemmin käytettiin Javaa konfigurointiin. Pääsyy siihen, ettei XML:ää käytetä, on se, ettei se ole tarpeeksi tiivis eikä sisällä ominaisuuksia kuten käännösajan tarkistus, vaan tarve jakaa papujen luomista luokkien välillä.
Yhteenvetona kirjoittaja suosii @Configuration ja @Bean menetelmiä. |
Edellinen:Yksinkertainen tapa tyhjentää näyttö Python-komentoriviltäSeuraava:Useita tapoja käyttää hajautettuja lukkoja (redis, eläintarhanhoitaja, tietokanta)
|
