Lente voor luie mensen Foundation, basisconcepten en voorbeelden met code. Deel 1

In dit artikel ga ik je niet vertellen hoe je met mijn code in 5 minuten een werkend Spring-project aan de gang kunt krijgen. Ik ga alleen de basis schrijven - dingen die je misschien niet weet en toch een project maakt. Maar in dit artikel zul je nog steeds niet begrijpen wat er gebeurt en, nog belangrijker, waarom.

Wat is het lentekader?

Het Spring Framework, of kortweg Spring, is een van de meest populaire frameworks voor het maken van webapplicaties in Java. Een raamwerk is als een bibliotheek (misschien ben je meer bekend met deze term), maar er is iets om over na te denken. Grof gezegd, als u een bibliotheek gebruikt, maakt u eenvoudig instanties van de klassen die deze bevat, roept u de methoden aan die u nodig hebt en krijgt u zo het resultaat dat u nodig hebt. Met andere woorden, dit is een meer dwingende benadering: in je programma geef je expliciet aan op welk moment je welk object moet maken, wanneer je welke specifieke methode moet aanroepen, enz. Met frameworks ligt het iets anders. Je schrijft gewoon een paar eigen klassen en schrijft er wat logica in, maar dan maakt het raamwerk zelf instanties van je klassen en roept hun methoden aan. Je klassen implementeren meestal een aantal interfaces van het framework of erven een aantal van zijn klassen, waardoor je functionaliteit krijgt die al voor je is geschreven. Maar dit is niet altijd het geval. Spring probeert bijvoorbeeld zoveel mogelijk dergelijke strakke koppeling te vermijden (waarbij je klassen direct afhankelijk zijn van klassen/interfaces in het framework). Het gebruikt annotaties om dit te bereiken. We komen hier later op terug. Maar het is belangrijk om te begrijpen dat Spring slechts een verzameling klassen en interfaces is die u kunt gebruiken :) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo bekend voorkomen. En we zullen er vandaag zelfs een schrijven. waardoor u enige functionaliteit krijgt die al voor u is geschreven. Maar dit is niet altijd het geval. Spring probeert bijvoorbeeld zoveel mogelijk dergelijke strakke koppeling te vermijden (waarbij je klassen direct afhankelijk zijn van klassen/interfaces in het framework). Het gebruikt annotaties om dit te bereiken. We komen hier later op terug. Maar het is belangrijk om te begrijpen dat Spring slechts een verzameling klassen en interfaces is die u kunt gebruiken :) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo bekend voorkomen. En we zullen er vandaag zelfs een schrijven. waardoor u enige functionaliteit krijgt die al voor u is geschreven. Maar dit is niet altijd het geval. Spring probeert bijvoorbeeld zoveel mogelijk dergelijke strakke koppeling te vermijden (waarbij je klassen direct afhankelijk zijn van klassen/interfaces in het framework). Het gebruikt annotaties om dit te bereiken. We komen hier later op terug. Maar het is belangrijk om te begrijpen dat Spring slechts een verzameling klassen en interfaces is die u kunt gebruiken :) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo bekend voorkomen. En we zullen er vandaag zelfs een schrijven. Spring probeert dergelijke strakke koppeling zoveel mogelijk te vermijden (waarbij uw klassen direct afhankelijk zijn van klassen/interfaces in het raamwerk). Het gebruikt annotaties om dit te bereiken. We komen hier later op terug. Maar het is belangrijk om te begrijpen dat Spring slechts een verzameling klassen en interfaces is die u kunt gebruiken :) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo bekend voorkomen. En we zullen er vandaag zelfs een schrijven. Spring probeert dergelijke strakke koppeling zoveel mogelijk te vermijden (waarbij uw klassen direct afhankelijk zijn van klassen/interfaces in het raamwerk). Het gebruikt annotaties om dit te bereiken. We komen hier later op terug. Maar het is belangrijk om te begrijpen dat Spring slechts een verzameling klassen en interfaces is die u kunt gebruiken :) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo bekend voorkomen. En we zullen er vandaag zelfs een schrijven. ) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo vertrouwd zijn. En we zullen er vandaag zelfs een schrijven. ) Ik wil ook meteen opmerken dat Spring niet alleen voor webapplicaties kan worden gebruikt, maar ook voor de meest voorkomende consoleprogramma's die ons allemaal zo vertrouwd zijn. En we zullen er vandaag zelfs een schrijven.

Structuur

Maar de lente is niet slechts één bepaald kader. Het is eerder een algemene naam die wordt gebruikt om te verwijzen naar verschillende kleine frameworks, die elk hun eigen soort werk doen.

https://docs.spring.io/spring/docs/4.3.26.RELEASE/spring-framework-reference/htmlsingle/
Figuur 2.1. Overzicht van het lentekader

Zoals je kunt zien, is Spring modulair. Hierdoor kunnen we alleen de modules aansluiten die we nodig hebben voor onze toepassing en niet de modules die we duidelijk niet zullen gebruiken. Voor zover ik weet, was het deze aanpak die ervoor zorgde dat Spring beter presteerde dan zijn toenmalige concurrent (EJB) en de leiding nam. Applicaties die EJB gebruiken , sleepten veel afhankelijkheden met zich mee, met als resultaat dat ze traag en traag bleken te zijn. Op de afbeelding is te zien dat het Spring Framework uit meerdere modules bestaat:

• Toegang tot data
• Web
• Kern
• en meer

Vandaag maken we kennis met enkele concepten uit de hoofdmodule: bonen, context en andere. Zoals je misschien al geraden hebt, bevat de Data Access-module tools voor het werken met gegevens (voornamelijk databases), en de Web-module is voor het werken op een netwerk (inclusief het maken van webapplicaties, die later zullen worden besproken). Daarnaast is er een uitgebreide infrastructuur die Spring ondersteunt: veel andere projecten die officieel niet in het framework zelf zijn opgenomen, maar naadloos in je Spring-project worden geïntegreerd (Spring Security, dat ik ook hoop aan te stippen, is voor authentificatie van een gebruiker op een website).

Waarom heeft Java het Spring Framework?

Afgezien van het feit dat het modieus, gelikt en fris is, kan ik nu zeggen dat zodra je ook maar een klein beetje vaardigheid hebt in het gebruik van Spring, je zult begrijpen dat er allerlei soorten werk zijn die je niet meer hebt te doen, en hoeveel werk Spring op zich neemt. Je kunt een paar dozijn regels configuratie-instellingen schrijven en een paar klassen schrijven, en je krijgt een werkend project. Maar zodra je je begint af te vragen hoeveel dingen er onder de motorkap zitten, hoeveel werk er wordt verzet en hoeveel code je zou moeten schrijven als je hetzelfde project zou implementeren op basis van gewone servlets of sockets en pure Java, je haren gaan overeind staan ​​:) De lente wordt zelfs omschreven als een soort magie. Dit ervaar je als je ziet dat alles werkt, maar je hebt ook een ruw idee van hoe en hoeveel werk er achter de schermen gebeurt - dus het lijkt erop dat er echt een soort magie in actie is :) Het is gemakkelijker om het magie te noemen dan om te proberen uit te leggen hoe het allemaal met elkaar verbonden is. :) Het tweede argument om Spring te bestuderen is dat ongeveer 90% van de vacatures voor junior ontwikkelaars (gebaseerd op mijn persoonlijke observaties) kennis vereist van, of op zijn minst een algemeen idee van wat Spring'sData, Web MVC, en Securitymodules bieden geavanceerde ontwikkelaars :) Maar vandaag gaat het alleen om de basis.

DI/IoC

Als je ooit hebt geprobeerd over Spring te lezen, dan was het eerste dat je tegenkwam waarschijnlijk deze afkortingen: DI/IoC. Nu raad ik je ten zeerste aan om een ​​pauze te nemen van dit artikel en dit DZone-artikel te lezen ! IoC staat voor inversion of control. Ik vermeldde dit al terloops toen ik schreef dat het gebruik van een bibliotheek inhoudt dat je zelf in je code aangeeft welke methode je welk object aanroept, maar dat het gebruik van een framework over het algemeen betekent dat het framework je code op het juiste moment zal aanroepen. Met andere woorden, in dit laatste geval beheert u niet langer het proces van het uitvoeren van de code/het programma - het framework doet dit voor u. Je hebt de controle doorgegeven aan het raamwerk (inversie van controle). DI staat voor afhankelijkheidsinjectie. Met afhankelijkheidsinjectie maakt u geen cat-objecten in de hoofdmethode en geeft u ze vervolgens door aan uw methoden. In plaats daarvan maakt het Spring Framework ze voor u. U zegt gewoon iets als "Ik wil hier een kat hebben" en het raamwerk geeft er een aan u door in uw methode. We zullen deze afkorting in toekomstige artikelen tegenkomen.

Bonen en context

Een van de sleutelbegrippen in het voorjaar is een boon. In feite is dit slechts een object van een bepaalde klasse. Stel dat we een programma hebben waarvoor 3 objecten nodig zijn: een kat, een hond en een papegaai. En we hebben een aantal klassen met een aantal methoden. Soms hebben we een kat nodig voor een methode, soms hebben we een hond nodig voor een andere methode, en soms hebben onze methoden zowel een kat als een papegaai nodig (bijvoorbeeld de methode om de kat te voeren, haha). Voor nog andere methoden zijn alle drie de objecten nodig. Ja, we zouden deze drie objecten eerst in de hoofdmethode kunnen maken en ze dan doorgeven aan onze klassen, en ze vervolgens binnen deze klassen doorgeven aan de relevante methoden... En zo verder door het hele programma. Maar als we ook veronderstellen dat we af en toe de lijst met invoerparameters voor onze methoden willen wijzigen (bijvoorbeeld besluiten we iets te herschrijven of nieuwe functionaliteit toe te voegen), dan zullen we nogal wat wijzigingen in de code moeten aanbrengen. En stel je nu voor dat we niet 3, maar 300 van dergelijke objecten hebben. Een alternatief zou zijn om al onze objecten in één lijst te verzamelen (List<Object>), geef het door aan elke methode en verkrijg vervolgens het benodigde object binnen de methoden. Maar als het programma wordt uitgevoerd, wat als er een object aan deze lijst wordt toegevoegd, of erger nog, wat als er een wordt verwijderd? Dit heeft het potentieel om elke methode te doorbreken waarbij we een index gebruiken om objecten uit de lijst te halen. Om dit probleem te voorkomen, besluiten we onze objecten niet op te slaan in een lijst, maar in een kaart, waarbij de sleutel de naam van het object is en de waarde het object zelf. Dit stelt ons in staat om de objecten die we nodig hebben eenvoudig op te halen door hun naam te gebruiken, bijv. get("papegaai"), en als reactie krijgen we het papegaai-object. Of de sleutel kan de klasse van het object zijn en de waarde kan het object zelf zijn. In dit geval, in plaats van de naam van het object op te geven, kunnen we gewoon de klasse specificeren van het object dat we nodig hebben. Dat is ook handig. Of we kunnen zelfs een soort omhulsel voor de kaart schrijven, waarbij sommige methoden objecten op naam krijgen en andere methoden objecten op klasse. Waar we hier zijn aangekomen, wordt een genoemdtoepassingscontext in het Spring Framework. Een context is een verzameling bonen (objecten). We openen een context om de bean (object) die we nodig hebben op naam, op type of op een andere manier te krijgen. Daarnaast kunnen we Spring zelf vragen om in zijn eigen context op zoek te gaan naar de boon die we nodig hebben en deze doorgeven aan onze methode. Stel dat we een methode als deze hadden:

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

Toen Spring deze methode aanriep, haalde het ons cat-object uit zijn context en gaf het door aan de methode. Maar nu hebben we besloten dat onze methode naast een kat ook een papegaai nodig heeft. Met de lente is niets eenvoudiger! Wij schrijven gewoon:

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

Wanneer Spring onze methode aanroept, begrijpt het de noodzaak om een ​​kat en een papegaai door te geven, dus gaat het naar zijn context, pakt deze twee objecten en geeft ze door aan onze methode. Door de teugels van controle over te dragen aan Spring, dragen we ook de verantwoordelijkheid voor het maken van objecten en het doorgeven ervan over aan onze methoden, die Spring zal noemen. Dit roept de vraag op: hoe weet Spring welke objecten (bonen) ze moet maken?

Manieren om een ​​applicatie te configureren

Er zijn drie belangrijke manieren om een ​​applicatie te configureren , dat wil zeggen manieren om Spring precies te vertellen welke objecten we nodig hebben:

1. XML-configuratiebestanden
2. Op Java gebaseerde configuratie
3. automatische configuratie

De makers van Spring prioriteren ze in deze volgorde:

• de methode met de hoogste prioriteit, die de voorkeur verdient, is automatische configuratie
• als automatische configuratie niet kan worden gebruikt om alle mogelijke bonen correct te configureren, gebruik dan op Java gebaseerde configuratie (waarbij objecten worden gemaakt met behulp van Java-code)
• en de methode met de laagste prioriteit is de ouderwetse manier - met behulp van XML-configuratiebestanden.

De lente laat ons ook deze methodes combineren. Laat Spring bijvoorbeeld alles configureren wat automatisch kan worden geconfigureerd, gebruik Java-gebaseerde configuratie waar u speciale parameters nodig heeft en gebruik XML voor eventuele legacy-configuraties. Dit blijkt allemaal behoorlijk flexibel te zijn. Toch, als alles automatisch kan worden geconfigureerd, kies dan die optie. Ik zal alleen automatische configuratie en op Java gebaseerde configuratie overwegen. XML-configuraties worden in bijna elk voorbeeld van Spring op internet gebruikt. Bovendien, als je eenmaal begrijpt hoe op Java gebaseerde configuratie werkt, zou je geen probleem moeten hebben om een ​​XML-bestand te lezen dat hetzelfde doet. Automatische configuratie wordt gebruikt wanneer we moeten werken met objecten van klassen die we hebben geschreven. Als het maken van een van onze objecten een zeer specifieke logica vereist, of als we een klasse niet kunnen maken met de annotatie die nodig is voor automatische configuratie, dan kunnen we op Java gebaseerde configuratie gebruiken om te doen wat er moet gebeuren. In devolgende deel zullen we een Maven-project maken, een paar van de belangrijkste Spring-modules verbinden en onze eerste bonen maken.