Java >> Java tutorial >  >> Tag >> Spring

Hvor mange måder er der til at konfigurere Spring-rammen? Hvad er forskellene mellem dem rent teknisk? (Ikke fordele eller ulemper..)

For at undgå forvirring bør vi forstå den konfigurationsdefinition og bønnedefinition er to forskellige ting . Der er tre måder at definere konfiguration på, som er tilgængelige i Spring 4 som standard:

  • xml-baseret konfiguration, når du beskriver konfiguration i xml-fil;
  • java-baseret konfiguration, når konfigurationen er Java-klasse, markeret med specifikke anmærkninger;
  • groovy-baseret konfiguration, når konfigurationen er fil med Groovy-kode;

Og der er to måder at tilføje bønnedefinitioner til anvendelse:

  • konfiguration inde bønnedefinition, når du tilføjer bønner manuelt ved at angive ret i konfigurationen.

    I dette tilfælde vil definitionen være baseret på konfigurationstypen. For xml-config vil det være <bean/> tag, for java-baseret config - metode med @Bean annotation og beans {...} konstruktion til Groovy.

  • annotationsbaseret bønnedefinition, når du markerer bønneklasser med specifikke annoteringer (såsom @Component , @Service , @Controller etc). Denne type konfiguration bruger klassestiscanning.

I dette tilfælde skal du angive direktiv for scanning af klassesti. For xml-config vil det være <context:component-scan base-package="..."/> , for java-config - @ComponentScan annotation, for Groovy ctx.'component-scan'(...) påkaldelse.

Som du kan se, kan du bruge konfigurationer og bønnedefinitioner i forskellige kombinationer.

Bemærk, at hvis du bruger xml-baseret konfiguration, kan du vælge tilgang til drevafhængighedsinjektion:manuelt i xml eller ved at bruge annoteringer (@Autowire , @Required etc). I senere tilfælde skal du definere <context:annotation-config/> . Men du må ikke forveksle bønnedefinition og afhængighedsindsprøjtningskontrol.

Lad os nu, baseret på dette synspunkt, prøve at besvare dine spørgsmål:

Hvorfor bruger den (såkaldte) annotationsbaserede konfiguration faktisk ClassPathXmlApplicationContext, men ikke AnnotationConfigApplicationContext ovenfor?

Bogens forfatter blandede begreber. Faktisk er dette en xml-baseret konfiguration med annotationsbaseret bønnedefinition.

Den Java-baserede konfiguration, der er forklaret i bogen, virker som det, der skal kaldes annotationsbaseret konfiguration.?

Du har ret - Java-baseret konfiguration bruger virkelig aktivt annoteringer og kunne kaldes annotationsbaseret. Men annotering er en del af Java. Derudover er dette et traditionelt udtryk, specificeret i dokumentationen.

Hvor mange måder er der til at konfigurere Spring framework?

Så som standard har vi tre måder at beskrive konfiguration på, og to måder at definere bønner på. Det viser seks måder at konfigurere Spring framework på (som standard). Men selvfølgelig kan alle disse måder bruges i kombination med hinanden.


Den nemmeste måde at forstå dette på er at se ind i rammens lange historie, hvordan dette blev udviklet.

  • XML-baseret konfiguration - dette var der fra begyndelsen - version 1 - se javadoc for ClassPathXmlApplicationContext. Dette var omkring marts 2004, tidspunktet for J2EE 1.4, som havde KÆMPE xml-konfiguration og Spring var stor forenkling (også XML, men enklere). Dette bruger XML til alt, inklusive specificering af autowiring, eller hvilke afhængigheder der går direkte (dit ref="accoundDao" eksempel).

  • Annotationsbaseret konfiguration - i foråret 2.5 - dette kom som en reaktion på Java EE 5, nye annotationer som @Autowired blev introduceret, der var stadig en vis kontekstkonfiguration i XML-filer - normalt ville du definere hvilke pakker der skulle scannes og resten af ​​det blev gjort automatisk baseret på annoteringer - deraf navnet.

  • Java-baseret konfiguration kom med Spring 3, blev forbedret i senere versioner. Det var her, AnnotationConfigApplicationContext og Configuration annotation blev introduceret - du kunne potentielt droppe XML helt -> java baseret konfiguration. Selvom dette først blev praktisk senere med version 4+, på grund af et stort antal xml-hjælpetags til aop, jdbc osv.

Udover disse 3 (2 faktisk som 1 og 2 bruger den samme ApplicationContext-klasse), er der andre måder at skabe en kontekst på:

  • se alle implementeringsklasser af ApplicationContext-grænsefladen
  • SpringJUnit4ClassRunner til junittest
  • Jeg vil vædde på, at der er andre måder, jeg ikke er klar over

Først vil jeg gerne takke Ken Bekov for hans mere opfindsomme svar. Jeg har forsøgt at improvisere hans svar, så alle kan lære mere om dette område.

Konfigurationsdefinition:

Spring 4 indeholder 3 måder at definere sin konfiguration på. Det er de

Fordele ved annoteringen:

  1. Alle information is in a single file (ingen grund til at åbne to filer for at konfigurere en given adfærd)

  2. Når klassen ændres, no need to modify the xml file

  3. Annoteringer siges ofte at være mere intuitive og robuste, når applikationskoden omfaktorerer. De drager også fordel af en bedre IDE-vejledning, som skikkelse giver. Men de blander ansøgningskode med DI-bekymringer. En applikation bliver afhængig af en ramme. Klar adskillelse er næsten umulig. Annotations are also limited when describing different injection behaviour at the same place (constructor, field) dependent on other circumstances (e.g. robot legs problem). Desuden tillader de ikke at behandle eksterne klasser (bibliotekskode) som din egen kilde. Derfor anses de for at køre hurtigere end XML.

Fordele ved xml-fil:

  1. Klar adskillelse mellem POJO'en og dens adfærd

  2. Når du ikke ved, hvilken POJO der er ansvarlig for adfærden, er det nemmere at finde den POJO (søger i en undergruppe af filer i stedet for al kildekoden)

  3. XML har den eneste fordel ved en deklarativ stil, der er defineret klart adskilt fra selve applikationskoden. Det forbliver uafhængigt af DIs bekymringer. Ulemperne er verbosity , poor re-factoring robustness og a general runtime failure opførsel. Der er blot en generel (XML) værktøjsunderstøttelse med ringe fordel i forhold til IDE-understøttelse til f.eks. Java. Udover denne XML kommer der en ydeevneoverhead, så den er normalt slower than code solutions .

XML- og annotationsbaseret link:

  1. http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#beans-annotation-config
  2. Annoteringer vs. XML, fordele og ulemper
  3. Injektion af Java-afhængighed:XML eller annoteringer
  4. Forårsannotationsbaseret DI vs xml-konfiguration?
  5. Xml-konfiguration versus annotationsbaseret konfiguration

Groovy-baseret link:

  1. https://objectpartners.com/2016/01/12/using-groovy-based-spring-configuration/
  2. http://blog.andresteingress.com/2014/02/14/grails-java-based-spring-config/

Bean Definition:

Der er 2 måder at bean Definition på:

Scanning af klassesti:

Til xml-config det bliver <context:component-scan base-package="..."/> , til java-config - @ComponentScan annotation, for Groovy ctx.'component-scan'(...) påkaldelse.

Afhængighedsindsprøjtning:

I xml-baseret konfiguration, dependency injection kan gøres manuelt i xml , eller ved at bruge annotations (@Autowire, @Required osv.). I det tilfælde er det nødvendigt at definere <context:annotation-config/>

Spørgsmål og svar:

Spørgsmål 1:Hvorfor bruger den (såkaldte) annotationsbaserede konfiguration faktisk ClassPathXmlApplicationContext, men ikkeAnnotationConfigApplicationContext ovenfor?

Svar: Det er en xml-baseret konfiguration med annotationsbaseret bønnedefinition.

Ansøgningskontekst:

  1. http://docs.spring.io/spring/docs/4.2.0.RELEASE/javadoc-api/org/springframework/context/ApplicationContext.html

AnnotationConfigApplicationContext:

1.AnnotationConfigApplicationContext og overordnet kontekst

ClassPathXmlApplicationContext:

  1. http://www.tutorialspoint.com/spring/spring_applicationcontext_container.htm
  2. http://www.mkyong.com/spring3/spring-3-hello-world-example/

Spørgsmål 2:Den Java-baserede konfiguration, der er forklaret i bogen, virker som det, der skal kaldes annotationsbaseret konfiguration.?

Svar: Du har ret i den sag. Java-baseret konfiguration bruger anmærkninger og kaldes annotationsbaseret konfiguration. Men annotering er en enkelt del af Java, intet andet.

Men vi er nødt til at forstå hvordan dette hierarki kommer fra xml- til annotationsbaseret og til sidst groovy-baseret?

Et alternativ til XML-opsætninger er tilvejebragt af annotationsbaseret konfiguration, som er afhængig af bytekode-metadataene til at forbinde komponenter i stedet for vinkelbeslagserklæringer. I stedet for at bruge XML til at beskrive en bean-ledning, flytter udvikleren konfigurationen ind i selve komponentklassen ved at bruge anmærkninger på den relevante klasse, metode eller felterklæring. Som nævnt i afsnittet kaldet "Eksempel:The RequiredAnnotationBeanPostProcessor", er brug af en BeanPostProcessor sammen med annoteringer en almindelig måde at udvide Spring IoC-beholderen på. For eksempelSpring 2.0 introducerede muligheden for at håndhæve nødvendige egenskaber med @Required anmærkning.

Forår 2.5 gjort det muligt at følge den samme generelle tilgang til at drive Springs afhængighedsindsprøjtning. Grundlæggende er @Autowired annotering giver de samme muligheder som beskrevet i afsnit 6.4.5, "Autowiring-samarbejdspartnere", men med mere finkornet kontrol og bredere anvendelighed.

Forår 2.5 også tilføjet understøttelse af JSR-250-annoteringer såsom @PostConstruct og @PreDestroy .

Forår 3.0 tilføjet understøttelse af JSR-330 (Dependency Injection for Java) annoteringer indeholdt i javax.inject-pakken såsom @Inject og @Named . Detaljer om disse annoteringer kan findes i det relevante afsnit.

Spørgsmål 3:Hvor mange måder er der til at konfigurere Spring framework?

Svar:

Theoretically, 3 måder at beskrive konfiguration på, og 2 måder at definere bønner på. Det bliver 3*2 =6 måder at konfigurere Spring framework på (som standard). Alle disse måder kan bruges i kombination med hinanden.

But Actually, i et enkelt ord kan vi konfigurere spring framework ved at bruge XML eller annotations .


Java tag