Forår for dovne mennesker Fundament, grundlæggende begreber og eksempler med kode. Del 1

I denne artikel vil jeg ikke fortælle dig, hvordan du får et fungerende forårsprojekt op at køre på 5 minutter ved hjælp af min kode. Jeg vil kun skrive det grundlæggende - ting, som du kan være uvidende om og stadig skabe et projekt. Men i denne artikel vil du stadig ikke forstå, hvad der sker, og endnu vigtigere, hvorfor.

Hvad er forårsrammen?

Spring Framework, eller blot Spring, er en af ​​de mest populære rammer til at skabe webapplikationer i Java. En ramme er ligesom et bibliotek (måske du er mere bekendt med dette udtryk), men der er noget at overveje. Groft sagt, når du bruger et bibliotek, opretter du blot forekomster af de klasser, som det indeholder, kalder de metoder, du skal bruge, og får dermed det resultat, du har brug for. Med andre ord er dette en mere tvingende tilgang: I dit program angiver du eksplicit det specifikke tidspunkt, hvor du skal oprette hvilket objekt, hvornår du skal kalde hvilken specifik metode osv. Med rammer er tingene lidt anderledes. Du skriver simpelthen nogle egne klasser og skriver noget logik i dem, men så opretter selve frameworket forekomster af dine klasser og kalder deres metoder. Dine klasser implementerer normalt nogle grænseflader fra rammeværket eller arver nogle af dets klasser, hvilket giver dig noget funktionalitet, som allerede er skrevet til dig. Men dette er ikke altid tilfældet. For eksempel forsøger Spring så vidt muligt at undgå en sådan tæt kobling (hvor dine klasser direkte afhænger af klasser/grænseflader i rammen). Den bruger anmærkninger for at opnå dette. Vi vender tilbage til dette senere. Men det er vigtigt at forstå, at Spring kun er en samling af klasser og grænseflader, der er tilgængelige for dig at bruge :) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer som er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag. dermed give dig noget funktionalitet, som allerede er skrevet til dig. Men dette er ikke altid tilfældet. For eksempel forsøger Spring så vidt muligt at undgå en sådan tæt kobling (hvor dine klasser direkte afhænger af klasser/grænseflader i rammen). Den bruger anmærkninger for at opnå dette. Vi vender tilbage til dette senere. Men det er vigtigt at forstå, at Spring kun er en samling af klasser og grænseflader, der er tilgængelige for dig at bruge :) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer som er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag. dermed give dig noget funktionalitet, som allerede er skrevet til dig. Men dette er ikke altid tilfældet. For eksempel forsøger Spring så vidt muligt at undgå en sådan tæt kobling (hvor dine klasser direkte afhænger af klasser/grænseflader i rammen). Den bruger anmærkninger for at opnå dette. Vi vender tilbage til dette senere. Men det er vigtigt at forstå, at Spring kun er en samling af klasser og grænseflader, der er tilgængelige for dig at bruge :) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer som er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag. Spring forsøger så vidt muligt at undgå en sådan tæt kobling (hvor dine klasser er direkte afhængige af klasser/grænseflader i rammen). Den bruger anmærkninger for at opnå dette. Vi vender tilbage til dette senere. Men det er vigtigt at forstå, at Spring kun er en samling af klasser og grænseflader, der er tilgængelige for dig at bruge :) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer som er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag. Spring forsøger så vidt muligt at undgå en sådan tæt kobling (hvor dine klasser er direkte afhængige af klasser/grænseflader i rammen). Den bruger anmærkninger for at opnå dette. Vi vender tilbage til dette senere. Men det er vigtigt at forstå, at Spring kun er en samling af klasser og grænseflader, der er tilgængelige for dig at bruge :) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer som er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag. ) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer, der er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag. ) Jeg vil også med det samme bemærke, at Spring ikke kun kan bruges til webapplikationer, men også til de mest almindelige konsolprogrammer, der er så velkendte for os alle. Og vi skriver endda en af ​​dem i dag.

Struktur

Men foråret er ikke kun én bestemt ramme. Det er snarere et almindeligt navn, der bruges til at henvise til flere små rammer, som hver især udfører sin egen slags arbejde.

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
Figur 2.1. Oversigt over forårsrammerne

Som du kan se, er Spring modulopbygget. Dette lader os kun forbinde de moduler, vi har brug for til vores applikation, og ikke forbinde dem, som vi åbenbart ikke vil bruge. Så vidt jeg ved, var det denne tilgang, der lod Spring overgå sin daværende konkurrent (EJB) og tage føringen. Applikationer, der bruger EJB, trak en masse afhængigheder bag sig, og som et resultat viste de sig at være træge og langsomme. Billedet viser, at Spring Framework består af flere moduler:

• Dataadgang
• Web
• Kerne
• og mere

I dag vil vi stifte bekendtskab med nogle begreber, der findes i hovedmodulet: bønner, kontekst og andre. Som du måske har gættet, indeholder Data Access-modulet værktøjer til at arbejde med data (hovedsageligt databaser), og webmodulet er til at arbejde på et netværk (inklusive oprettelse af webapplikationer, som vil blive diskuteret senere). Derudover er der en omfattende infrastruktur, der understøtter Spring: mange andre projekter, der ikke officielt er inkluderet i selve rammeværket, men er problemfrit integreret i dit Spring-projekt (f.eks. Spring Security, som jeg også håber at komme ind på, er for autentificering af en bruger på et websted).

Hvorfor har Java Spring Framework?

Nå, udover det faktum, at det er moderigtigt, glat og friskt, kan jeg sige lige nu, at så snart du får en lille smule færdighed ved at bruge Spring, vil du forstå, hvordan der er alle slags arbejde, du ikke længere har at lave, og hvor meget arbejde foråret tager på sig. Du kan skrive et par dusin linjer med konfigurationsindstillinger og skrive et par klasser, og du ender med et fungerende projekt. Men så snart du begynder at spekulere på, hvor mange ting der er under motorhjelmen, hvor meget arbejde der bliver gjort, og hvor meget kode du skulle skrive, hvis du skulle implementere det samme projekt baseret på almindelige servlets eller sockets og ren Java, dit hår vil rejse sig :) Foråret beskrives endda som en slags magi. Det oplever man, når man ser, at alt fungerer, men du har også en nogenlunde idé om, hvordan og hvor meget arbejde der sker bag kulisserne — så det ser ud til, at der virkelig er en form for magi i aktion :) Det er lettere at kalde det magi end at prøve at forklare, hvordan det hele hænger sammen. :) Det andet argument for at studere Spring er, at cirka 90 % af jobåbningerne for juniorudviklere (baseret på mine personlige observationer) kræver enten viden om eller i det mindste en generel idé om hvad Spring erData, Web MVC, og Securitymoduler tilbyder sofistikerede udviklere :) Men i dag handler det kun om det grundlæggende.

DI/IoC

Hvis du nogensinde har prøvet at læse om foråret, så var det første, du stødte på, sandsynligvis disse akroynymer: DI/IoC. Nu anbefaler jeg stærkt, at du tager en pause fra denne artikel og læser denne DZone-artikel ! IoC står for inversion of control. Jeg nævnte det allerede i forbifarten, da jeg skrev, at brug af et bibliotek involverer, at du selv angiver i din kode, hvilken metode du skal kalde på hvilket objekt, men at brug af et framework generelt betyder, at frameworket vil kalde din kode på det rigtige tidspunkt. Med andre ord, i sidstnævnte tilfælde administrerer du ikke længere processen med at udføre koden/programmet - rammen gør dette for dig. Du sendte kontrollen til rammen (inversion af kontrol). DI står for afhængighedsindsprøjtning. Med afhængighedsinjektion opretter du ikke katteobjekter i hovedmetoden og videregiver dem derefter til dine metoder. I stedet skaber Spring Framework dem til dig. Du siger blot noget i stil med "jeg vil have en kat her", og rammerne giver dig en i din metode. Vi vil se denne forkortelse i fremtidige artikler.

Bønner og kontekst

Et af nøglebegreberne i foråret er en bønne. Faktisk er dette kun et objekt af en eller anden klasse. Antag, at vi har et program, der kræver 3 objekter: en kat, en hund og en papegøje. Og vi har en masse klasser med en masse metoder. Nogle gange har vi brug for en kat til en metode, nogle gange har vi brug for en hund til en anden metode, og nogle gange har vores metoder brug for både en kat og en papegøje (for eksempel metoden til at fodre katten, ha-ha). Til endnu andre metoder er alle tre objekter nødvendige. Ja, vi kunne først oprette disse tre objekter i hovedmetoden og derefter videregive dem til vores klasser, og derefter inden for disse klasser videregive dem til de relevante metoder... Og så videre gennem hele programmet. Men hvis vi også antager, at vi en gang imellem ønsker at ændre listen over inputparametre for vores metoder (f.eks. vi beslutter os for at omskrive noget eller tilføje ny funktionalitet), så bliver vi nødt til at lave en del ændringer i koden. Og forestil dig nu, at vi ikke har 3, men 300 sådanne genstande. Et alternativ ville være at samle alle vores objekter på én liste (List<Object>), send det til hver metode, og få derefter det nødvendige objekt, mens du er inde i metoderne. Men når programmet kører, hvad nu hvis et objekt bliver tilføjet til denne liste, eller endnu værre, hvad hvis et bliver slettet? Dette har potentialet til at bryde enhver metode, hvor vi bruger et indeks til at hente objekter fra listen. For at undgå dette problem beslutter vi at gemme vores objekter ikke på en liste, men på et kort, hvor nøglen er objektets navn og værdien er selve objektet. Dette giver os mulighed for at hente de objekter, vi har brug for, blot ved at bruge deres navn, f.eks. get("parrot"), og som svar får vi papegøjeobjektet. Eller nøglen kunne være objektets klasse, og værdien kunne være selve objektet. I dette tilfælde, snarere end at angive navnet på objektet, men kan bare specificere klassen af ​​det objekt, vi har brug for. Det er også praktisk. Eller vi kunne endda skrive en form for wrapper til kortet, hvor nogle metoder får objekter ved deres navn, og andre metoder får objekter efter deres klasse. Det, vi er nået frem til her, kaldes enansøgningskontekst i forårsrammen. En kontekst er en samling af bønner (objekter). Vi får adgang til en kontekst for at få den bønne (objekt), vi har brug for, ved navn, type eller på anden måde. Derudover kan vi bede Spring selv om at gå og kigge i sin egen sammenhæng efter den bønne, vi har brug for, og videregive den til vores metode. Antag for eksempel, at vi havde en metode som denne:

public void doSomething(Cat cat) {
    ...
}

Da Spring kaldte denne metode, tog den vores katteobjekt fra sin kontekst og videregav den til metoden. Men nu har vi besluttet, at vores metode foruden en kat også har brug for en papegøje. Med foråret kunne intet være nemmere! Vi skriver blot:

public void doSomething(Cat cat, Parrot parrot) {
    ...
}

Når Spring nu kalder vores metode, forstår det behovet for at passere en kat og en papegøje, så det går til sin kontekst, får disse to objekter og videregiver dem til vores metode. Ved at overføre styringen til Spring, overfører vi også ansvaret for at skabe genstande og videregive dem til vores metoder, som Spring vil kalde. Dette rejser spørgsmålet: hvordan ved Spring, hvilke objekter (bønner) der skal skabes?

Måder at konfigurere en applikation på

Der er tre hovedmåder at konfigurere en applikation på , det vil sige måder at fortælle Spring præcis, hvilke objekter vi har brug for:

1. XML-konfigurationsfiler
2. Java-baseret konfiguration
3. automatisk konfiguration

Forårets skabere prioriterer dem i denne rækkefølge:

• metoden med topprioritet, som bør foretrækkes, er automatisk konfiguration
• hvis automatisk konfiguration ikke kan bruges til at konfigurere alle mulige bønner korrekt, skal du bruge Java-baseret konfiguration (som involverer oprettelse af objekter ved hjælp af Java-kode)
• og den laveste prioritetsmetode er den gammeldags måde - ved at bruge XML-konfigurationsfiler.

Foråret lader os også kombinere disse metoder. Lad for eksempel Spring konfigurere alt, der kan konfigureres automatisk, brug Java-baseret konfiguration, hvor du har brug for specielle parametre, og brug XML til eventuelle ældre konfigurationer. Det hele viser sig at være ret fleksibelt. Alligevel, hvis alt kan konfigureres automatisk, skal du vælge denne mulighed. Jeg vil kun overveje automatisk konfiguration og Java-baseret konfiguration. XML-konfigurationer bruges i næsten alle eksempler på Spring på internettet. Hvad mere er, når du først forstår, hvordan Java-baseret konfiguration fungerer, bør du ikke have noget problem med at læse en XML-fil, der gør det samme. Automatisk konfiguration bruges, når vi skal arbejde med objekter i klasser, som vi har skrevet. Hvis det kræver en meget specifik logik at skabe et af vores objekter, eller hvis vi ikke er i stand til at lave en klasse med den annotering, der er nødvendig for automatisk konfiguration, så kan vi bruge Java-baseret konfiguration til at gøre det, der skal gøres. I dennæste del vil vi oprette et Maven-projekt, forbinde et par af de vigtigste Spring-moduler og skabe vores første bønner.