|
|
Postitatud 30.08.2018 13:29:41
|
|
|
Täna arutasin kolleegidega, kas kasutada @Configuration ja @Bean kombinatsiooni ubade loomiseks Spring Bootis või kasutada @Service ja muid annotatsioone otse klassis. Autor kasutab tavaliselt esimest, st @Configuration ja @Bean kombinatsiooni.
Vaatame esmalt näidet: eesmärk on luua SearchService'i jaoks uba.
Kasuta @Service otse:
Käivita rakendus, brauseri ligipääs: http://localhost:8081/search?q=koly, lehe kuvamine: ["hello", "koly"]
Viisid @Configuration ja @Bean kasutamiseks:
Võrreldes @Service koodi otsekasutamisega on olemas AppConfig klass, mis eemaldab @Service annotatsioonid, mis on paigutatud ElasticSearchServiceImpl peale. Esmapilgul on rohkem koodi ja klasse. Millised on siis viimase kasutamise eelised?
Autor usub, et eelised on:
Ettevõtete eraldamine
@Configuration ja @Bean meetoditega toimub ubade tootmine ühes kohas ning liides ja selle teostus ei ole ubade loomisega mingit pistmist.
Kui ubade loomist tuleb muuta, siis tuleb vaadata ja muuta ainult vastavat konfiguratsiooniklassi, ning muudatuste tegemiseks ei pea minema vastavasse Java uba. Näiteks mõnikord tuleb ubade loomist teha koostööd @Scope või @Profile-ga ning muuta ainult konfiguratsiooni klassi.
Üksikteenistus
@service annotatsioon ise kannab kahte vastutust:
Üks neist on ubade valmistamine;
Teine on klassi tuvastamine teenusena.
Näitab, et annoteeritud klass on "teenus", algselt määratletud Domain-Driven poolt
Disain (Evans, 2003) kui "operatsioon, mida pakutakse liidesena, mis seisab mudelis iseseisvalt, ilma kapseldatud olekuta."
Ülal on Springi selgitus @Service annotatsioonide kohta. See is@Service esindab tegelikult olekuta, sõltumatut liidese operatsiooni DDD-s.
@Bean ja @Configuration koostöös antakse ubade loomine üle eraldi klassile ning teenuse identiteet antakse Java keeles liidesele ja klassinimele. See kajastub ka Spring Datas, näiteks Repository, mida nimetatakse nime järgi, näiteks CrudRepository. Seetõttu kajastub ka nimi teenindust. Spetsiifilisi hierarhia definitsioone saab kasutada projekti nime järgi uute kihte pakkumiseks, ilma et peaks tuginema Springi annotatsioonidele, nagu Mapper kiht, Validator kiht jne.
Lisaks on uba ja teenindus kahemõõtmelised mõisted. Üks konkreetse rakenduse kohta ja teine DDD kontseptsioonide kohta.
Paindlikum
@Bean meetoditega saad luua klasside eksemplare teegis. Kui kasutad @Service meetodit, ei saa sa lisada @Service kommentaare vastavatele klassidele raamatukogus.
Vähim teadmine
Minimaalse teadmise põhimõte tähendab:
Mida vähem on vaja tehnoloogiat või teadmisi funktsiooni täitmiseks, seda parem, et tagada projekti lihtsus ja vähendada õppimise raskusi.
Kuna klassiraamatukogus ei saa @Service abil klasside instantse luua, tuleb sarnaste vajaduste korral kasutada @Configuration ja @Bean vormi. Selles etapis on kogu projektis annotatsioonid nagu @Service, @Configuration ja @Bean ning need annotatsioonid teevad sama asja, st loovad uba.
@Service puhul on suur tõenäosus, et samaaegselt @Service, @Component, @Configuration ja @Bean.
@Configuration ja @Bean kasutamine võib täielikult kõrvaldada @Service ja @Component kasutamise, mis on kooskõlas minimaalse teadmise põhimõttega.
Lõpuks, muide, kevadoad loodi xml-is ja hiljem kasutati konfiguratsiooniks Java't. Peamine põhjus, miks XML-i ei kasutata, on see, et see ei ole piisavalt lühike ja puuduvad funktsioonid nagu kompileerimisaja kontroll, pigem vajadus jagada ubade loomist klasside vahel.
Kokkuvõtteks eelistab autor kasutada @Configuration ja @Bean meetodeid. |
Eelmine:Lihtne viis ekraani puhastamiseks Python'i käsurealtJärgmine:Mitmed viisid hajutatud lukkude kasutamiseks (redis, zookeeper, andmebaas)
|
