Vår för lata människor Foundation, grundläggande begrepp och exempel med kod. Del 1

I den här artikeln kommer jag inte att berätta hur du får igång ett fungerande vårprojekt på 5 minuter med min kod. Jag kommer bara att skriva grunderna - saker som du kan vara okunnig om och ändå skapa ett projekt. Men i den här artikeln kommer du fortfarande inte att förstå vad som händer och, ännu viktigare, varför.

Vad är vårens ramverk?

Spring Framework, eller helt enkelt Spring, är ett av de mest populära ramverken för att skapa webbapplikationer i Java. Ett ramverk är som ett bibliotek (du kanske är mer bekant med denna term), men det finns något att tänka på. Grovt sett, när du använder ett bibliotek skapar du helt enkelt instanser av klasserna som det innehåller, anropar de metoder du behöver och får på så sätt det resultat du behöver. Med andra ord, detta är mer imperativt tillvägagångssätt: i ditt program anger du uttryckligen det specifika ögonblicket när du behöver skapa vilket objekt, när du ska anropa vilken specifik metod, etc. Med ramverk är saker och ting annorlunda. Du skriver helt enkelt några egna klasser och skriver lite logik i dem, men sedan skapar själva ramverket instanser av dina klasser och anropar deras metoder. Dina klasser implementerar vanligtvis vissa gränssnitt från ramverket eller ärver några av dess klasser, vilket ger dig en del funktionalitet som redan har skrivits åt dig. Men detta är inte alltid fallet. Spring försöker till exempel så mycket som möjligt undvika en sådan tät koppling (där dina klasser är direkt beroende av klasser/gränssnitt i ramverket). Den använder anteckningar för att uppnå detta. Vi återkommer till detta senare. Men det är viktigt att förstå att Spring bara är en samling klasser och gränssnitt som är tillgängliga för dig att använda :) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan även för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag. vilket ger dig en del funktioner som redan har skrivits åt dig. Men detta är inte alltid fallet. Spring försöker till exempel så mycket som möjligt undvika en sådan tät koppling (där dina klasser är direkt beroende av klasser/gränssnitt i ramverket). Den använder anteckningar för att uppnå detta. Vi återkommer till detta senare. Men det är viktigt att förstå att Spring bara är en samling klasser och gränssnitt som är tillgängliga för dig att använda :) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan även för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag. vilket ger dig en del funktioner som redan har skrivits åt dig. Men detta är inte alltid fallet. Spring försöker till exempel så mycket som möjligt undvika en sådan tät koppling (där dina klasser är direkt beroende av klasser/gränssnitt i ramverket). Den använder anteckningar för att uppnå detta. Vi återkommer till detta senare. Men det är viktigt att förstå att Spring bara är en samling klasser och gränssnitt som är tillgängliga för dig att använda :) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan även för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag. Spring försöker så gott det går att undvika en sådan tät koppling (där dina klasser är direkt beroende av klasser/gränssnitt i ramverket). Den använder anteckningar för att uppnå detta. Vi återkommer till detta senare. Men det är viktigt att förstå att Spring bara är en samling klasser och gränssnitt som är tillgängliga för dig att använda :) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan även för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag. Spring försöker så gott det går att undvika en sådan tät koppling (där dina klasser är direkt beroende av klasser/gränssnitt i ramverket). Den använder anteckningar för att uppnå detta. Vi återkommer till detta senare. Men det är viktigt att förstå att Spring bara är en samling klasser och gränssnitt som är tillgängliga för dig att använda :) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan även för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag. ) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan också för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag. ) Jag vill också genast notera att Spring kan användas inte bara för webbapplikationer, utan också för de vanligaste konsolprogrammen som är så bekanta för oss alla. Och vi kommer till och med att skriva en av dem idag.

Strukturera

Men våren är inte bara en speciell ram. Snarare är det ett vanligt namn som används för att hänvisa till flera små ramverk, som var och en gör sin egen typ av arbete.

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
Figur 2.1. Översikt över vårens ramverk

Som du kan se är Spring modulär. Detta låter oss bara ansluta de moduler vi behöver för vår applikation och inte ansluta de som vi uppenbarligen inte kommer att använda. Så vitt jag vet var det detta tillvägagångssätt som lät Spring överträffa sin dåvarande konkurrent (EJB) och ta ledningen. Applikationer som använder EJB drog efter sig många beroenden, och som ett resultat visade de sig vara tröga och långsamma. Bilden visar att Spring Framework består av flera moduler:

• Datatillgång
• webb
• Kärna
• och mer

Idag ska vi bekanta oss med några begrepp som finns i huvudmodulen: bönor, sammanhang och andra. Som du kanske har gissat innehåller Data Access-modulen verktyg för att arbeta med data (främst databaser), och webbmodulen är till för att arbeta i ett nätverk (inklusive att skapa webbapplikationer, vilket kommer att diskuteras senare). Dessutom finns det en omfattande infrastruktur som stöder Spring: många andra projekt som inte officiellt ingår i själva ramverket, men som är sömlöst integrerade i ditt Spring-projekt (till exempel Spring Security, som jag också hoppas kunna beröra, är till för autentisera en användare på en webbplats).

Varför har Java Spring Framework?

Tja, förutom det faktum att det är modernt, snyggt och fräscht, kan jag säga just nu att så fort du får ens en liten del av skicklighet med våren, kommer du att förstå hur det finns alla typer av arbete som du inte längre har att göra, och hur mycket arbete våren tar på sig. Du kan skriva ett par dussin rader med konfigurationsinställningar och skriva ett par klasser, och du slutar med ett fungerande projekt. Men så fort du börjar undra hur mycket grejer som finns under huven, hur mycket arbete som görs och hur mycket kod du skulle behöva skriva om du skulle implementera samma projekt baserat på vanliga servlets eller sockets och ren Java, ditt hår kommer att resa sig :) Våren beskrivs till och med som en sorts magi. Du upplever detta när du ser att allt fungerar, men du har också en grov uppfattning om hur och hur mycket arbete som händer bakom kulisserna — så det verkar som att det verkligen finns någon form av magi i aktion :) Det är lättare att kalla det magi än att försöka förklara hur allt hänger ihop. :) Det andra argumentet för att studera Spring är att ungefär 90 % av lediga jobb för juniorutvecklare (baserat på mina personliga observationer) kräver antingen kunskap om eller åtminstone en allmän uppfattning om vad Spring ärData, Web MVC, och Securitymoduler erbjuder sofistikerade utvecklare :) Men idag handlar det bara om grunderna.

DI/IoC

Om du någonsin har försökt läsa om våren, så var det första du stötte på förmodligen dessa akroynymer: DI/IoC. Nu rekommenderar jag starkt att du tar en paus från den här artikeln och läser den här DZone-artikeln ! IoC står för inversion of control. Jag har redan nämnt detta i förbifarten när jag skrev att att använda ett bibliotek innebär att du själv anger i din kod vilken metod du ska anropa vilket objekt, men att användning av ett ramverk generellt innebär att ramverket anropar din kod vid rätt tidpunkt. Med andra ord, i det senare fallet hanterar du inte längre processen för att exekvera koden/programmet – ramverket gör detta åt dig. Du skickade kontrollen till ramverket (inversion av kontrollen). DI står för beroendeinjektion. Med beroendeinjektion skapar du inte kattobjekt i huvudmetoden och skickar dem sedan till dina metoder. Istället skapar Spring Framework dem åt dig. Du säger helt enkelt något i stil med "Jag vill skaffa en katt här" och ramverket skickar en till dig i din metod. Vi kommer att se denna förkortning i framtida artiklar.

Bönor och sammanhang

Ett av nyckelbegreppen i våren är en böna. I själva verket är detta bara ett objekt av någon klass. Anta att vi har ett program som kräver 3 objekt: en katt, en hund och en papegoja. Och vi har ett gäng klasser med en massa metoder. Ibland behöver vi en katt för en metod, ibland behöver vi en hund för en annan metod, och ibland behöver våra metoder både en katt och en papegoja (till exempel metoden för att mata katten, ha-ha). För ytterligare andra metoder behövs alla tre objekten. Ja, vi kunde först skapa dessa tre objekt i huvudmetoden och sedan skicka dem till våra klasser, och sedan inom dessa klasser skicka dem till relevanta metoder... Och så vidare genom hela programmet. Men om vi också antar att vi ibland vill ändra listan med indataparametrar för våra metoder (t.ex. vi bestämmer oss för att skriva om något eller lägga till ny funktionalitet), då måste vi göra en hel del ändringar i koden. Och föreställ dig nu att vi inte har 3, utan 300 sådana föremål. Ett alternativ skulle vara att samla alla våra objekt i en lista (List<Object>), skicka det till varje metod och hämta sedan det nödvändiga objektet medan du är inne i metoderna. Men när programmet körs, vad händer om något objekt läggs till i den här listan, eller ännu värre, vad händer om ett tas bort? Detta har potential att bryta varje metod där vi använder ett index för att hämta objekt från listan. För att undvika detta problem bestämmer vi oss för att lagra våra objekt inte i en lista, utan i en karta, där nyckeln är objektets namn och värdet är själva objektet. Detta gör att vi kan hämta de objekt vi behöver helt enkelt genom att använda deras namn, t.ex. get("parrot"), och som svar får vi papegojobjektet. Eller nyckeln kan vara objektets klass, och värdet kan vara själva objektet. I det här fallet, snarare än att ange namnet på objektet, men kan bara specificera klassen för objektet vi behöver. Det är också bekvämt. Eller så kan vi till och med skriva någon form av omslag för kartan, där vissa metoder får objekt med sitt namn och andra metoder får objekt efter sin klass. Det vi har kommit fram till här kallas entillämpningssammanhang i Spring Framework. Ett sammanhang är en samling bönor (objekt). Vi kommer åt ett sammanhang för att få bönan (objektet) vi behöver genom dess namn, genom dess typ eller på något annat sätt. Dessutom kan vi be Spring själv gå och leta i sitt eget sammanhang efter bönan vi behöver och skicka den till vår metod. Anta till exempel att vi hade en metod som denna:

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

När Spring kallade den här metoden tog den vårt kattobjekt från sitt sammanhang och skickade det till metoden. Men nu har vi bestämt oss för att vår metod förutom en katt också behöver en papegoja. Med våren kan inget vara enklare! Vi skriver helt enkelt:

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

Nu när Spring kallar vår metod, förstår den behovet av att passera en katt och en papegoja, så den går till sitt sammanhang, hämtar dessa två föremål och skickar dem till vår metod. Genom att överföra kontrollen till Spring överför vi också ansvaret för att skapa objekt och föra över dem till våra metoder, som Spring kommer att kalla. Detta väcker frågan: hur vet Spring vilka föremål (bönor) som ska skapas?

Sätt att konfigurera en applikation

Det finns tre huvudsakliga sätt att konfigurera en applikation, det vill säga sätt att berätta för Spring exakt vilka objekt vi behöver:

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

Vårens skapare prioriterar dem i denna ordning:

• metoden med högsta prioritet, som bör föredras, är automatisk konfiguration
• om automatisk konfiguration inte kan användas för att korrekt konfigurera alla möjliga bönor, använd Java-baserad konfiguration (som innebär att objekt skapas med Java-kod)
• och den lägsta prioriterade metoden är det gammalmodiga sättet - med hjälp av XML-konfigurationsfiler.

Våren låter oss också kombinera dessa metoder. Låt till exempel Spring konfigurera allt som kan konfigureras automatiskt, använd Java-baserad konfiguration där du behöver speciella parametrar och använd XML för alla äldre konfigurationer. Det hela verkar vara ganska flexibelt. Fortfarande, om allt kan konfigureras automatiskt, välj det alternativet. Jag kommer bara att överväga automatisk konfiguration och Java-baserad konfiguration. XML-konfigurationer används i nästan alla exempel på Spring på Internet. Vad mer, när du väl förstår hur Java-baserad konfiguration fungerar, bör du inte ha några problem att läsa en XML-fil som gör samma sak. Automatisk konfiguration används när vi behöver arbeta med objekt av klasser som vi skrev. Om att skapa ett av våra objekt kräver mycket specifik logik, eller om vi inte kan göra någon klass med den anteckning som krävs för automatisk konfiguration, då kan vi använda Java-baserad konfiguration för att göra det som behöver göras. I dennästa del kommer vi att skapa ett Maven-projekt, ansluta ett par av de viktigaste Spring-modulerna och skapa våra första bönor.