streamalism.org

1. Oversikt

I denne veiledningen ser vi på våren ApplicationConext grensesnitt i detalj.

2. Den ApplicationContext Grensesnitt

En av hovedtrekkene i Spring framework er IoC (Inversion of Control) container. Spring IoC-containeren er ansvarlig for å administrere objektene til en applikasjon. Den bruker avhengighetsinjeksjon for å oppnå inversjon av kontroll.

Grensesnittene BeanFactory og ApplicationContext representerer Spring IoC-containeren. Her, BeanFactory er rotgrensesnittet for tilgang til Spring container. Det gir grunnleggende funksjoner for håndtering av bønner.

På den annen side, den ApplicationContext er et undergrensesnitt av BeanFactory. Derfor tilbyr den alle funksjonene til BeanFactory.

Videre, det girmer bedriftsspesifikke funksjoner. De viktige funksjonene i ApplicationContext er løse meldinger, støtte internasjonalisering, publisere arrangementer og applikasjonslagsspesifikke sammenhenger. Dette er grunnen til at vi bruker den som standard Spring container.

3. Hva er en vårbønne?

Før vi dykker dypere inn i ApplicationContext container, er det viktig å vite om vårbønner. På våren er det en bønne et objekt som vårcontaineren instantierer, monterer og administrerer.

Så skal vi konfigurere alle objektene i applikasjonen vår som vårbønner? Vel, som en best praksis, bør vi ikke.

I henhold til vårdokumentasjonen, bør vi generelt definere bønner for tjenestelaggjenstander, datatilgangsobjekter (DAO), presentasjonsobjekter, infrastrukturobjekter som Hibernate Sesjonsfabrikker, JMS køer og så videre.

Vi bør også vanligvis ikke konfigurere finkornede domeneobjekter i containeren. Det er vanligvis ansvaret for DAO og forretningslogikk å opprette og laste domeneobjekter.

Så la oss definere en enkel Java-klasse som vi vil bruke som en vårbønne i denne opplæringen:

offentlig klasse AccountService {@Autowired private AccountRepository accountRepository; // getters og setters}

4. Konfigurere bønner i beholderen

Som vi vet, er den primære jobben til ApplicationContext er å administrere bønner.

Så, et program må gi bønnekonfigurasjonen til ApplicationContext container. Derfor består en fjærbønnekonfigurasjon av en eller flere bønnedefinisjoner. Spring støtter også forskjellige måter å konfigurere bønner på.

4.1. Java-basert konfigurasjon

Først starter vi med Java-basert konfigurasjon, da det er den nyeste og mest foretrukne måten å konfigurere bønner på. Den er tilgjengelig fra og med våren 3.0.

Java-konfigurasjon bruker vanligvis @Bønne-anmerkede metoder innen a @Konfigurasjon klasse. De @Bønne kommentar på en metode indikerer at metoden skaper en vårbønne. Videre en klasse kommentert med @Konfigurasjon indikerer at den inneholder fjærbønnekonfigurasjoner.

Så la oss nå opprette en konfigurasjonsklasse for å definere vår AccountService klasse som en vårbønne:

@Configuration public class AccountConfig {@Bean public AccountService accountService () {return new AccountService (accountRepository ()); } @Bean public AccountRepository accountRepository () {returner nytt AccountRepository (); }}

4.2. Kommentarbasert konfigurasjon

Spring 2.5 introduserte merknadsbasert konfigurasjon som det første trinnet for å aktivere bønnekonfigurasjoner i Java.

I denne tilnærmingen aktiverer vi først kommentarbasert konfigurasjon via XML-konfigurasjon. Deretter bruker vi et sett med merknader på Java-klasser, metoder, konstruktører eller felt for å konfigurere bønner. Noen eksempler på disse merknadene er @Komponent, @Kontrollør, @Service, @Oppbevaringssted, @Autowired, og @Kvalifiserende.

Spesielt bruker vi også disse kommentarene med Java-basert konfigurasjon. Også Spring fortsetter å legge til flere funksjoner til disse kommentarene med hver utgivelse.

Så, la oss nå se et enkelt eksempel på denne konfigurasjonen.

Først oppretter vi XML-konfigurasjonen, user-bean-config.xml, for å aktivere merknader:

Her, de kommentar-konfigurasjon tag muliggjør annoteringsbaserte kartlegginger. Også, den komponent-skanning tag forteller Spring hvor du skal se etter merkede klasser.

For det andre lager vi UserService klasse og definere det som en vårbønne ved hjelp av @Komponent kommentar:

@Component public class UserService {// brukertjenestekode}

Og så skriver vi en enkel testtilfelle for å teste denne konfigurasjonen:

ApplicationContext context = new ClassPathXmlApplicationContext ("applicationcontext / user-bean-config.xml"); UserService userService = context.getBean (UserService.class); assertNotNull (userService);

4.3. XML-basert konfigurasjon

Til slutt, la oss ta en titt på XML-basert konfigurasjon. Det er den tradisjonelle måten å konfigurere bønner på våren.

Åpenbart gjør vi alt i denne tilnærmingen bønnetilknytninger i en XML-konfigurasjonsfil.

Så la oss lage en XML-konfigurasjonsfil, konto-bønne-config.xml, og definer bønner for vår AccountService klasse:

5. Typer av ApplicationContext

Våren gir forskjellige typer ApplicationContext containere som passer til forskjellige krav. Dette er implementeringer av ApplicationContext grensesnitt. Så, la oss ta en titt på noen av de vanligste typene ApplicationContext.

5.1. AnnotationConfigApplicationContext

La oss først se AnnotationConfigApplicationContext klasse, som ble introdusert våren 3.0. Det kan ta klasser kommentert med @Konfigurasjon, @Komponent, og JSR-330 metadata som input.

Så la oss se et enkelt eksempel på bruk av AnnotationConfigApplicationContext container med vår Java-baserte konfigurasjon:

ApplicationContext context = new AnnotationConfigApplicationContext (AccountConfig.class); AccountService accountService = context.getBean (AccountService.class);

5.2. AnnotationConfigWebApplicationContext

AnnotationConfigWebApplicationContexter en nettbasert variant av AnnotationConfigApplicationContext.

Vi kan bruke denne klassen når vi konfigurerer vårens ContextLoaderListener servlet lytter eller en Spring MVC DispatcherServlet, i en web.xml fil.

Fra og med våren 3.0 kan vi dessuten konfigurere denne applikasjonskontekstbeholderen programmatisk. Alt vi trenger å gjøre er å implementere WebApplicationInitializer grensesnitt:

public class MyWebApplicationInitializer implementerer WebApplicationInitializer {public void onStartup (ServletContext container) kaster ServletException {AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext (); context.register (AccountConfig.class); context.setServletContext (container); // konfigurasjon av servlet}}

5.3. XmlWebApplicationContext

Hvis vi bruker XML-basert konfigurasjon i et webapplikasjon, kan vi bruke XmlWebApplicationContext klasse.

Faktisk er det å konfigurere denne beholderen som AnnotationConfigWebApplicationContext bare klasse, noe som betyr at vi kan konfigurere den i web.xml eller implementere WebApplicationInitializer grensesnitt:

offentlig klasse MyXmlWebApplicationInitializer implementerer WebApplicationInitializer {public void onStartup (ServletContext container) kaster ServletException {XmlWebApplicationContext context = new XmlWebApplicationContext (); context.setConfigLocation ("/ WEB-INF / spring / applicationContext.xml"); context.setServletContext (container); // Servlet-konfigurasjon}}

5.4. FileSystemXMLApplicationContext

Vi bruker FileSystemXMLApplicationContext klasse til laste en XML-basert Spring-konfigurasjonsfil fra filsystemet eller fra nettadresser. Denne klassen er nyttig når vi trenger å laste inn ApplicationContext programmatisk. Generelt er testseler og frittstående applikasjoner noen av de mulige brukssakene for dette.

La oss for eksempel se hvordan vi kan lage denne Spring-beholderen og laste bønnene for vår XML-baserte konfigurasjon:

Strengsti = "C: /myProject/src/main/resources/applicationcontext/account-bean-config.xml"; ApplicationContext context = ny FileSystemXmlApplicationContext (sti); AccountService accountService = context.getBean ("accountService", AccountService.class);

5.5. ClassPathXmlApplicationContext

I tilfelle vi vil laste inn en XML-konfigurasjonsfil fra klassestien, kan vi bruke ClassPathXmlApplicationContext klasse. Lik FileSystemXMLApplicationContext, det er nyttig for test seler så vel som for applikasjonskontekster innebygd i JAR.

Så, la oss se et eksempel på bruk av denne klassen:

ApplicationContext context = new ClassPathXmlApplicationContext ("applicationcontext / account-bean-config.xml"); AccountService accountService = context.getBean ("accountService", AccountService.class);

6. Ytterligere funksjoner i ApplicationContext

6.1. Meldingsoppløsning

De ApplicationContext grensesnitt støtter meldingsoppløsning og internasjonalisering ved å utvide MessageSource grensesnitt. Videre gir Spring to MessageSource implementeringer, ResourceBundleMessageSource og StaticMessageSource.

Vi kan bruke StaticMessageSource for å programmatisk legge til meldinger til kilden. Imidlertid støtter den grunnleggende internasjonalisering og er mer egnet for tester enn produksjonsbruk.

På den andre siden, ResourceBundleMessageSource er den vanligste implementeringen av MessageSource. Den er avhengig av de underliggende JDK-ene ResouceBundle gjennomføring. Den bruker også JDKs standard meldingsparsing levert av MessageFormat.

La oss nå se hvordan vi kan bruke MessageSource for å lese meldingene fra en eiendomsfil.

Først skal vi lage meldinger. eiendommer fil på klassestien:

account.name = TestAccount

For det andre vil vi legge til en bønnedefinisjon i vår AccountConfig klasse:

@Bean offentlig MessageSource messageSource () {ResourceBundleMessageSource messageSource = ny ResourceBundleMessageSource (); messageSource.setBasename ("config / meldinger"); returmeldingKilde; }

For det tredje skal vi injisere MessageSource i AccountService:

@Autowired private MessageSource messageSource;

Til slutt kan vi bruke getMessage metoden hvor som helst i AccountService for å lese meldingen:

messageSource.getMessage ("account.name", null, Locale.ENGLISH);

Våren gir også ReloadableResourceBundleMessageSource klasse, som gjør det mulig å lese filer fra en hvilken som helst Spring-ressurslokasjon og støtter varm omlasting av filer med pakkeegenskaper.

6.2. Håndtering av hendelser

ApplicationContext støtter håndtering av hendelser ved hjelp av ApplicationEvent klasse og ApplicationListener grensesnitt. Den støtter innebygde hendelser som ContextStartedEvent, ContextStoppedEvent, ContextClosedEvent, og RequestHandledEvent. Videre støtter den også tilpassede hendelser for forretningsbruk.

7. Konklusjon

I denne opplæringen har vi diskutert forskjellige aspekter av ApplicationContext container om våren. Vi har sett forskjellige eksempler på hvordan du konfigurerer vårbønner i en AppicationContext. Vi har også sett hvordan du lager og bruker forskjellige typer ApplicationContext.

Som alltid er den komplette koden tilgjengelig på GitHub.