Vår for late mennesker Grunnlag, grunnleggende konsepter og eksempler med kode. Del 1 - 1I denne artikkelen skal jeg ikke fortelle deg hvordan du får et fungerende Spring-prosjekt i gang på 5 minutter ved å bruke koden min. Jeg skal bare skrive det grunnleggende - ting du kan være uvitende om og fortsatt lage et prosjekt. Men i denne artikkelen vil du fortsatt ikke forstå hva som skjer og, enda viktigere, hvorfor.

Hva er Spring Framework?

Spring Framework, eller ganske enkelt Spring, er et av de mest populære rammeverkene for å lage webapplikasjoner i Java. Et rammeverk er som et bibliotek (kanskje du er mer kjent med dette begrepet), men det er noe å vurdere. Grovt sett, når du bruker et bibliotek, lager du ganske enkelt forekomster av klassene som det inneholder, kaller metodene du trenger, og får dermed resultatet du trenger. Med andre ord, dette er en mer imperativ tilnærming: i programmet ditt angir du eksplisitt det spesifikke øyeblikket når du trenger å lage hvilket objekt, når du skal kalle hvilken spesifikk metode, osv. Med rammeverk er ting litt annerledes. Du skriver ganske enkelt noen egne klasser og skriver litt logikk i dem, men så lager selve rammeverket forekomster av klassene dine og kaller metodene deres. Klassene dine implementerer vanligvis noen grensesnitt fra rammeverket eller arver noen av klassene, og gir deg dermed funksjonalitet som allerede er skrevet for deg. Men dette er ikke alltid tilfelle. For eksempel prøver Spring så mye som mulig å unngå en så tett kobling (der klassene dine er direkte avhengige av klasser/grensesnitt i rammeverket). Den bruker merknader for å oppnå dette. Vi kommer tilbake til dette senere. Men det er viktig å forstå at Spring bare er en samling av klasser og grensesnitt som er tilgjengelige for deg å bruke :) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag. gir deg dermed funksjonalitet som allerede er skrevet for deg. Men dette er ikke alltid tilfelle. For eksempel prøver Spring så mye som mulig å unngå en så tett kobling (der klassene dine er direkte avhengige av klasser/grensesnitt i rammeverket). Den bruker merknader for å oppnå dette. Vi kommer tilbake til dette senere. Men det er viktig å forstå at Spring bare er en samling av klasser og grensesnitt som er tilgjengelige for deg å bruke :) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag. gir deg dermed funksjonalitet som allerede er skrevet for deg. Men dette er ikke alltid tilfelle. For eksempel prøver Spring så mye som mulig å unngå en så tett kobling (der klassene dine er direkte avhengige av klasser/grensesnitt i rammeverket). Den bruker merknader for å oppnå dette. Vi kommer tilbake til dette senere. Men det er viktig å forstå at Spring bare er en samling av klasser og grensesnitt som er tilgjengelige for deg å bruke :) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag. Spring prøver i størst mulig grad å unngå en så tett kobling (der klassene dine er direkte avhengige av klasser/grensesnitt i rammeverket). Den bruker merknader for å oppnå dette. Vi kommer tilbake til dette senere. Men det er viktig å forstå at Spring bare er en samling av klasser og grensesnitt som er tilgjengelige for deg å bruke :) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag. Spring prøver i størst mulig grad å unngå en så tett kobling (der klassene dine er direkte avhengige av klasser/grensesnitt i rammeverket). Den bruker merknader for å oppnå dette. Vi kommer tilbake til dette senere. Men det er viktig å forstå at Spring bare er en samling av klasser og grensesnitt som er tilgjengelige for deg å bruke :) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag. ) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag. ) Jeg vil også merke med en gang at Spring kan brukes ikke bare til webapplikasjoner, men også til de vanligste konsollprogrammene som er så kjent for oss alle. Og vi skal til og med skrive en av dem i dag.

Struktur

Men våren er ikke bare én bestemt ramme. Snarere er det et vanlig navn som brukes til å referere til flere små rammer, som hver gjør sin egen type arbeid. Vår for late mennesker Grunnlag, grunnleggende konsepter og eksempler med kode. Del 1 - 2

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
Figur 2.1. Oversikt over vårens rammeverk

Som du kan se, er Spring modulær. Dette lar oss bare koble til modulene vi trenger for applikasjonen vår og ikke koble til de som vi åpenbart ikke vil bruke. Så vidt jeg vet, var det denne tilnærmingen som lot Spring overgå sin daværende konkurrent (EJB) og ta ledelsen. Applikasjoner som brukte EJB dro mange avhengigheter bak seg, og som et resultat viste de seg å være trege og trege. Bildet viser at Spring Framework består av flere moduler:
  • Datatilgang
  • Web
  • Kjerne
  • og mer
I dag skal vi bli kjent med noen konsepter som finnes i hovedmodulen: bønner, kontekst og andre. Som du kanskje har gjettet, inneholder Data Access-modulen verktøy for å arbeide med data (hovedsakelig databaser), og webmodulen er for arbeid på et nettverk (inkludert å lage webapplikasjoner, som vil bli diskutert senere). I tillegg er det en omfattende infrastruktur som støtter Spring: mange andre prosjekter som ikke offisielt er inkludert i selve rammeverket, men er sømløst integrert i Spring-prosjektet ditt (for eksempel Spring Security, som jeg også håper å berøre, er for autentisering av en bruker på et nettsted).

Hvorfor har Java Spring Framework?

Vel, foruten det faktum at det er moteriktig, glatt og friskt, kan jeg si akkurat nå at så snart du får en liten mengde ferdigheter ved å bruke Spring, vil du forstå hvordan det er all slags arbeid du ikke lenger har å gjøre, og hvor mye arbeid våren tar på seg. Du kan skrive et par dusin linjer med konfigurasjonsinnstillinger og skrive et par klasser, og du ender opp med et fungerende prosjekt. Men så snart du begynner å lure på hvor mye ting som er under panseret, hvor mye arbeid som gjøres, og hvor mye kode du må skrive hvis du skulle implementere det samme prosjektet basert på vanlige servlets eller sockets og ren Java, håret ditt vil reise seg :) Våren beskrives til og med som en slags magi. Du opplever dette når du ser at alt fungerer, men du har også en grov ide om hvordan og hvor mye arbeid som skjer bak kulissene — så det ser ut til at det virkelig er en slags magi i aksjon :) Det er lettere å kalle det magi enn å prøve å forklare hvordan det hele henger sammen. :) Det andre argumentet for å studere Spring er at omtrent 90 % av ledige stillinger for juniorutviklere (basert på mine personlige observasjoner) krever enten kunnskap om eller i det minste en generell idé om hva Spring erData, Web MVC, og Securitymoduler tilbyr sofistikerte utviklere :) Men i dag handler det bare om det grunnleggende.

DI/IoC

Hvis du noen gang har prøvd å lese om våren, så var det første du møtte sannsynligvis disse akroynymene: DI/IoC. Nå anbefaler jeg på det sterkeste at du tar en pause fra denne artikkelen og leser denne DZone-artikkelen ! IoC står for inversjon av kontroll. Jeg har allerede nevnt dette i forbifarten da jeg skrev at bruk av et bibliotek innebærer at du selv angir i koden din hvilken metode du skal kalle på hvilket objekt, men at bruk av et rammeverk betyr generelt at rammeverket vil kalle opp koden din til rett tid. Med andre ord, i dette siste tilfellet administrerer du ikke lenger prosessen med å utføre koden/programmet – rammeverket gjør dette for deg. Du ga kontrollen til rammeverket (inversjon av kontroll). DI står for avhengighetsinjeksjon. Med avhengighetsinjeksjon lager du ikke katteobjekter i hovedmetoden og sender dem deretter til metodene dine. I stedet lager Spring Framework dem for deg. Du sier ganske enkelt noe sånt som "Jeg vil få en katt her" og rammeverket gir deg en i metoden din. Vi vil se denne forkortelsen i fremtidige artikler.

Bønner og kontekst

Et av nøkkelbegrepene i våren er en bønne. Faktisk er dette bare et objekt av en eller annen klasse. Anta at vi har et program som krever 3 objekter: en katt, en hund og en papegøye. Og vi har en haug med klasser med en haug med metoder. Noen ganger trenger vi en katt for en metode, noen ganger trenger vi en hund for en annen metode, og noen ganger trenger metodene våre både en katt og en papegøye (for eksempel metoden for å mate katten, ha-ha). For enda andre metoder trengs alle tre objektene. Ja, vi kunne først opprette disse tre objektene i hovedmetoden, og deretter sende dem til klassene våre, og deretter innen disse klassene sende dem til de relevante metodene... Og så videre gjennom hele programmet. Men hvis vi også antar at vi av og til ønsker å endre listen over inngangsparametere for metodene våre (f.eks. vi bestemmer oss for å omskrive noe eller legge til ny funksjonalitet), så må vi gjøre ganske mange endringer i koden. Og se for deg at vi ikke har 3, men 300 slike objekter. Et alternativ ville være å samle alle objektene våre i én liste (List<Object>), send den til hver metode, og hent deretter det nødvendige objektet mens du er inne i metodene. Men når programmet kjører, hva om et objekt legges til denne listen, eller enda verre, hva om et blir slettet? Dette har potensial til å bryte hver metode der vi bruker en indeks for å hente objekter fra listen. For å unngå dette problemet, bestemmer vi oss for å lagre objektene våre ikke i en liste, men i et kart, der nøkkelen er objektets navn og verdien er selve objektet. Dette lar oss hente objektene vi trenger ganske enkelt ved å bruke navnet deres, f.eks. get("parrot"), og som svar får vi papegøyeobjektet. Eller nøkkelen kan være objektets klasse, og verdien kan være selve objektet. I dette tilfellet, i stedet for å spesifisere navnet på objektet, men kan bare spesifisere klassen til objektet vi trenger. Det er også praktisk. Eller vi kan til og med skrive en slags wrapper for kartet, der noen metoder får objekter etter navnet, og andre metoder får objekter etter klassen. Det vi har kommet frem til her kalles ensøknadskontekst i Spring Framework. En kontekst er en samling bønner (objekter). Vi får tilgang til en kontekst for å få bønnen (objektet) vi trenger ved navn, type eller på annen måte. I tillegg kan vi be Spring selv om å se i sin egen kontekst etter bønnen vi trenger og gi den videre til metoden vår. Anta for eksempel at vi hadde en metode som denne: 

public void doSomething(Cat cat) {
    ...
}
Da Spring kalte denne metoden, tok den katteobjektet vårt fra konteksten og ga det videre til metoden. Men nå har vi bestemt oss for at metoden vår trenger en papegøye i tillegg til en katt. Med våren kan ingenting være enklere! Vi skriver bare: 

public void doSomething(Cat cat, Parrot parrot) {
    ...
}
Nå når Spring kaller metoden vår, forstår den behovet for å passere en katt og en papegøye, så den går til sin kontekst, henter disse to objektene og sender dem til metoden vår. Ved å overføre kontrollen til Spring, overfører vi også ansvaret for å lage objekter og overføre dem til våre metoder, som Spring vil kalle. Dette reiser spørsmålet: hvordan vet Spring hvilke gjenstander (bønner) som skal lages?

Måter å konfigurere en applikasjon på

Det er tre hovedmåter å konfigurere en applikasjon på , det vil si måter å fortelle Spring nøyaktig hvilke objekter vi trenger:
  1. XML-konfigurasjonsfiler
  2. Java-basert konfigurasjon
  3. automatisk konfigurasjon
Vårens skapere prioriterer dem i denne rekkefølgen:
  • metoden med toppprioritet, som bør foretrekkes, er automatisk konfigurasjon
  • hvis automatisk konfigurasjon ikke kan brukes til å konfigurere alle mulige bønner riktig, bruk Java-basert konfigurasjon (som innebærer å lage objekter ved hjelp av Java-kode)
  • og den laveste prioriterte metoden er den gammeldagse måten - ved å bruke XML-konfigurasjonsfiler.
Våren lar oss også kombinere disse metodene. La for eksempel Spring konfigurere alt som kan konfigureres automatisk, bruk Java-basert konfigurasjon der du trenger spesielle parametere, og bruk XML for eventuelle eldre konfigurasjoner. Alt dette viser seg å være ganske fleksibelt. Likevel, hvis alt kan konfigureres automatisk, velg det alternativet. Jeg vil kun vurdere automatisk konfigurasjon og Java-basert konfigurasjon. XML-konfigurasjoner brukes i nesten alle eksempler på Spring på Internett. Når du først forstår hvordan Java-basert konfigurasjon fungerer, bør du ikke ha noe problem med å lese en XML-fil som gjør det samme. Automatisk konfigurasjon brukes når vi trenger å jobbe med objekter i klassene vi skrev. Hvis det krever en veldig spesifikk logikk å lage et av objektene våre, eller hvis vi ikke klarer å lage en klasse med merknaden som er nødvendig for automatisk konfigurasjon, kan vi bruke Java-basert konfigurasjon for å gjøre det som må gjøres. Ineste del vil vi lage et Maven-prosjekt, koble til et par av hovedmodulene til våren og lage våre første bønner.