|
|
Opslået på 30/08/2018 13.29.41
|
|
|
I dag diskuterede jeg med mine kolleger, om jeg skulle bruge en kombination af @Configuration og @Bean til at skabe bønner i Spring Boot, eller om vi skulle bruge @Service og andre kommentarer direkte på klassen. Forfatteren bruger typisk den første, altså en kombination af @Configuration og @Bean.
Lad os først se på et eksempel, målet er at oprette en bønne til SearchService.
Brug @Service direkte:
Start applikationen, browseradgang: http://localhost:8081/search?q=koly, sidevisning: ["hello", "koly"]
Måder at bruge @Configuration og @Bean på:
Sammenlignet med at bruge @Service kode direkte findes der en AppConfig-klasse, der fjerner de @Service annoteringer, der er placeret oven på ElasticSearchServiceImpl. Ved første øjekast er der mere kode og flere klasser. Så hvad er fordelene ved at bruge sidstnævnte?
Forfatteren mener, at fordelene er:
Adskillelse af bekymringer
Ved at bruge @Configuration og @Bean metoder foregår skabelsen af bønner ét sted, og grænsefladen og dens implementering har intet at gøre med skabelsen af bønnen.
Hvis oprettelsen af bønnen skal ændres, behøver du kun at se og ændre den tilsvarende konfigurationsklasse, og du behøver ikke gå til den tilsvarende Java-bønne for at foretage ændringer. For eksempel skal bønneskabelse nogle gange samarbejdes med @Scope eller @Profile, og man behøver kun at ændre Configuration-klassen.
Enkeltopgave
@service annotering påtager sig to ansvarsområder:
Den ene er skabelsen af bønner;
Den anden er at identificere en klasse som en service.
Angiver, at en annoteret klasse er en "Service", oprindeligt defineret af Domain-Driven
Design (Evans, 2003) som "en operation tilbudt som et interface, der står alene i modellen, uden indkapslet tilstand."
Ovenfor er Springs forklaring af @Service annotationer. Den is@Service repræsenterer faktisk en stateless, uafhængig grænsefladeoperation i DDD.
Som en måde at @Bean og @Configuration samarbejde på en måde, overdrages skabelsen af bønner til en separat klasse, og Service-identiteten overdrages til interfacet og klassenavnet i Java. Dette afspejles også i Spring Data, såsom Repository, som identificeres ved navn, såsom CrudRepository. Derfor afspejles Service også i navnet. Specifikke hierarkidefinitioner kan bruges til at levere flere lag efter projekt efter navn uden at være afhængig af de annotationer, der leveres af Spring, såsom Mapper-laget, Validator-laget osv.
Derudover er bønne og service todimensionelle begreber. Den ene handler om den konkrete implementering og den anden handler om koncepterne i DDD.
Mere fleksibel
Ved at bruge @Bean metoder kan du oprette instanser af klasser i biblioteket. Hvis du bruger @Service-metoden, vil du ikke kunne tilføje @Service kommentarer til de tilsvarende klasser i biblioteket.
Mindst viden
Princippet om minimal viden betyder:
Jo mindre teknologi eller viden der kræves for at fuldføre funktionen, desto bedre, for at sikre projektets enkelhed og reducere vanskelighederne ved at lære det.
Da det ikke er muligt at oprette instanser af klasser i klassebiblioteket med @Service, skal du bruge formen @Configuration og @Bean, når du møder lignende behov. På dette tidspunkt er der annotationer som @Service, @Configuration og @Bean i hele projektet, og disse annotationer gør det samme, dvs. skaber bønnen.
Med @Service er der stor sandsynlighed for @Service, @Component, @Configuration og @Bean på samme tid.
Samtidig kan brugen af @Configuration og @Bean fuldstændigt eliminere brugen af @Service og @Component, hvilket er i overensstemmelse med princippet om minimum viden.
Endelig blev Spring beans for resten lavet i xml og brugte senere Java til konfiguration. Hovedårsagen til ikke at bruge XML er, at det ikke er kortfattet nok og ikke har funktioner som kompileringstidskontrol, snarere end behovet for at sprede oprettelsen af bønner på tværs af klasser.
For at opsummere foretrækker forfatteren at bruge @Configuration og @Bean metoder. |
Tidligere:En simpel måde at rydde skærmen på fra Python-kommandolinjenNæste:Flere måder at bruge distribuerede låse på (redis, zookeeper, database)
|
