|
|
Publisert på 30.08.2018 13:29:41
|
|
|
I dag diskuterte jeg med kollegene mine om jeg skulle bruke en kombinasjon av @Configuration og @Bean for å lage bønner i Spring Boot, eller om jeg skulle bruke @Service og andre notater direkte på kurset. Forfatteren pleier å bruke den første, altså en kombinasjon av @Configuration og @Bean.
La oss se på et eksempel først, målet er å lage en bønne for SearchService.
Bruk @Service direkte:
Start applikasjonen, nettlesertilgang: http://localhost:8081/search?q=koly, sidevisning: ["hello", "koly"]
Måter å bruke @Configuration og @Bean på:
Sammenlignet med å bruke @Service kode direkte, finnes det en AppConfig-klasse som fjerner de @Service annotasjonene som er plassert oppå ElasticSearchServiceImpl. Ved første øyekast er det mer kode og klasser. Så hva er fordelene med å bruke sistnevnte?
Forfatteren mener at fordelene er:
Separasjon av bekymringer
Ved å bruke @Configuration og @Bean metoder foregår produksjonen av bønner samlet på ett sted, og grensesnittet og implementeringen har ingenting med produksjonen av bønnen å gjøre.
Hvis opprettelsen av bønnen må endres, trenger du bare å se og endre den tilsvarende konfigurasjonsklassen, og du trenger ikke gå til den tilsvarende Java-bønnen for å gjøre endringer. For eksempel må bønneproduksjon noen ganger samarbeides med @Scope eller @Profile, og man trenger bare å endre Configuration-klassen.
Enkeltoppgave
@service annotasjonen har i seg selv to ansvarsområder:
Den ene er produksjon av bønner;
Den andre er å identifisere en klasse som en tjeneste.
Indikerer at en annotert klasse er en "Service", opprinnelig definert av Domain-Driven
Design (Evans, 2003) som "en operasjon tilbudt som et grensesnitt som står alene i modellen, uten innkapslet tilstand."
Ovenfor er Springs forklaring av @Service annotasjoner. Den is@Service representerer faktisk en tilstandsløs, uavhengig grensesnittoperasjon i DDD.
Som @Bean og @Configuration samarbeid overføres produksjonen av bønner til en egen klasse, og identiteten til Service overføres til grensesnittet og klassenavnet i Java. Dette gjenspeiles også i Spring Data, som Repository, som er identifisert med navn, for eksempel CrudRepository. Derfor gjenspeiles også tjeneste i navnet. Spesifikke hierarkidefinisjoner kan brukes for å tilby flere lag i henhold til prosjektet etter navn uten å være avhengig av annotasjonene fra Spring, som Mapper-laget, Validator-laget, osv.
I tillegg er bønne og tjeneste todimensjonale konsepter. Den ene om den konkrete implementeringen og den andre om konseptene i DDD.
Mer fleksibel
Ved å bruke @Bean metodene kan du lage instanser av klasser i biblioteket. Hvis du bruker @Service-metoden, vil du ikke kunne legge til @Service kommentarer til de tilsvarende klassene i biblioteket.
Minst kunnskap
Prinsippet om minimumskunnskap betyr:
Jo mindre teknologi eller kunnskap som kreves for å fullføre funksjonen, desto bedre, for å sikre prosjektets enkelhet og redusere vanskeligheten med å lære det.
Siden det ikke er mulig å lage instanser av klasser i klassebiblioteket med @Service, må du bruke formen @Configuration og @Bean når du møter lignende behov. På dette tidspunktet finnes det merknader som @Service, @Configuration og @Bean i hele prosjektet, og disse annotasjonene gjør det samme, altså skaper bønnen.
Med @Service er det stor sannsynlighet for @Service, @Component, @Configuration og @Bean samtidig.
mens bruk av @Configuration og @Bean fullstendig kan eliminere bruken av @Service og @Component, noe som er i tråd med prinsippet om minimumskunnskap.
Til slutt, forresten, ble Spring beans laget i xml og brukte senere Java for konfigurasjon. Hovedgrunnen til at XML ikke brukes er at det ikke er konsist nok og ikke har funksjoner som kompilasjonstidskontroll, i stedet for behovet for å spre opprettelsen av bønner på tvers av klasser.
For å oppsummere foretrekker forfatteren å bruke @Configuration og @Bean metoder. |
Foregående:En enkel måte å tømme skjermen på fra Python-kommandolinjenNeste:Flere måter å bruke distribuerte låser på (redis, zookeeper, database)
|
