Deel 2. Laten we het even hebben over software-architectuur

Dit materiaal maakt deel uit van de serie "Inleiding tot Enterprise Development" . Het eerste deel, over netwerken, is hier . Software-architectuur verwijst naar de structuur die binnen een applicatie is gecreëerd, dwz de modules en componenten van het volledige programma en hoe ze op elkaar inwerken. Programmeurs werken al heel lang aan goede architecturen, dus het is niet verwonderlijk dat we veel van architecturale patronen hebben gehoord. Je moet ze begrijpen: bij het schrijven van een webapplicatie is het cruciaal om met een goede architectuur te komen, want een webapplicatie heeft meer componenten en modules dan een reguliere applicatie. Een architectonisch patroonis een slimme manier om een ​​softwareontwerpprobleem op te lossen. U bent waarschijnlijk ontwerppatronen tegengekomen zoals fabrieksmethode, abstracte fabriek, bouwer, prototype, singleton en mogelijk andere. We gebruiken ze bij het schrijven van code, het maken van klassen en het plannen van de interactie tussen klassen. Architectuurpatronen worden op een hoger abstractieniveau gebruikt bij het plannen van de interactie van de gebruiker met servers, gegevens en andere componenten. Laten we even kijken naar enkele patronen en hoe ze te gebruiken.

Client-server-architectuur

De naam wekt de indruk dat alles aan dit patroon eenvoudig en duidelijk is. Maar laten we enkele punten verduidelijken, zodat u, wanneer u Spring begint te bestuderen, begrijpt waar we het over hebben. Stel dat u een chat-app hebt geschreven en dat u en een vriend deze gaan gebruiken. Je zou een heel eenvoudige aanpak kunnen volgen door rechtstreeks berichten naar elkaar te sturen via internet met behulp van bekende IP-adressen: In eerste instantie lijkt alles goed te werken totdat een andere van je vrienden vraagt ​​om deel te nemen aan de chat. Dus als je besluit om je wederzijdse vriend aan de chat toe te voegen, sta je voor een architectonisch probleem: voor elke chatdeelnemer moet je actuele informatie verstrekken over het aantal gebruikers en het IP-adres van nieuwe gebruikers. En wanneer een bericht wordt verzonden, moet het bij alle deelnemers worden bezorgd. Dit zijn de meest voor de hand liggende problemen die zich kunnen voordoen. Een andere reeks problemen zal in de code zelf verborgen zijn. Om ze te vermijden, moet u een server gebruiken, waarin alle informatie over gebruikers wordt opgeslagen, inclusief hun adressen. Berichten hoeven alleen naar de server te worden gestuurd. Het stuurt op zijn beurt berichten naar elk van de ontvangers. Wanneer je besluit om een ​​serveronderdeel aan je chat-app toe te voegen, begin je met het bouwen van een client-server-architectuur.

Componenten van de client-serverarchitectuur

Laten we eens kijken waar het allemaal om draait. Een client-serverarchitectuur is een ontwerppatroon dat wordt gebruikt om webapplicaties te maken. Deze architectuur bestaat uit drie componenten:

1. Client — Aan de naam kunnen we zien dat dit onderdeel een bepaalde service gebruikt (de webtoepassing), waarbij het contact opneemt met een server om wat informatie op te vragen.

2. Server — Dit is waar uw webapplicatie of het servergedeelte ervan zich bevindt. Het slaat de benodigde gebruikersinformatie op of kan deze opvragen. Bovendien, wanneer een client een verzoek verzendt, is het de server die de gevraagde informatie retourneert.

3. Netwerk - Dit deel is eenvoudig. Het vergemakkelijkt de uitwisseling van informatie tussen de client en de server.

De server kan een groot aantal verzoeken van verschillende gebruikers aan. Dit betekent dat er veel klanten kunnen zijn. Als ze onderling informatie moeten uitwisselen, moet dat via de server gebeuren. Zo heeft de server nog een andere functie: verkeerscontrole. Wat betreft ons chatprogramma voor meerdere gebruikers, zal de hele applicatie uit twee modules bestaan:

• een clientmodule — bevat een grafische interface voor het aanmelden en het verzenden/ontvangen van berichten

• een servermodule — een webtoepassing die op een server wordt gehost en berichten van gebruikers ontvangt, verwerkt en vervolgens naar ontvangers stuurt

Als we nuttige (of niet erg bruikbare) informatie op internet willen bekijken, openen we een browser, voeren een zoekopdracht in de zoekbalk in en krijgen als antwoord informatie van de zoekmachine. In deze keten is de browser de opdrachtgever. Het stuurt een verzoek met informatie over wat we zoeken naar de server. De server verwerkt het verzoek, vindt de meest relevante resultaten, verpakt ze in een formaat dat de browser (client) kan begrijpen en stuurt ze terug. Complexe services zoals zoekmachines kunnen veel servers hebben. Bijvoorbeeld een autorisatieserver, een server voor het vinden van informatie, een server voor het genereren van het antwoord, enz. Maar de klant is zich hier niet van bewust en maakt zich er geen zorgen over: voor de klant is de server een uniforme entiteit. De klant kent alleen het ingangspunt, dat wil zeggen het adres van de server waarnaar verzoeken moeten worden verzonden. Denk aan de toepassing waarin we hebben onderzochthet vorige deel van deze serie . Het was bedoeld om de gemiddelde luchttemperatuur in alle landen in realtime te bewaken. De architectuur ziet er ongeveer zo uit: Onze applicatie bevindt zich op de server. Laten we zeggen dat het elke vijf seconden verzoeken verzendt naar servers die worden beheerd door lokale meteorologische stations, temperatuurinformatie ontvangt voor een bepaald land van de servers en deze informatie opslaat. Wanneer de klant ons vraagt ​​"de huidige luchttemperatuur van de wereld te bekijken", geven we de meest recent opgeslagen informatie terug, gesorteerd op land. Onze applicatie fungeert dus zowel als server (wanneer het verzoeken van gebruikers verwerkt) als als client (wanneer het informatie van andere servers ontvangt). Een eenvoudige client-serverarchitectuur wordt zeer zelden gebruikt en alleen voor zeer eenvoudige toepassingen. Voor echt grote en complexe projecten gebruiken we verschillende architecturen, die je in de toekomst zult tegenkomen. Laten we nu eens kijken naar een model dat sterk lijkt op de client-serverarchitectuur.

Architectuur op drie niveaus

Dit is een architectonisch patroon dat een derde module introduceert: gegevensopslag . In dit patroon worden de drie niveaus gewoonlijk lagen of lagen genoemd:

1. De clientlaag is de gebruikersinterface, ook wel de presentatielaag genoemd. Het kan een webbrowser zijn die HTML-pagina's ontvangt, of een grafische gebruikersinterface geschreven met JavaFX. Het belangrijkste is dat deze laag de gebruiker in staat stelt verzoeken naar de server te sturen en de antwoorden te verwerken.

2. De logische laag is de server die verzoeken/antwoorden verwerkt. Vaak wordt het ook wel de serverlaag genoemd. Hier vinden ook alle logische bewerkingen plaats: wiskundige berekeningen, gegevensbewerkingen, oproepen naar andere diensten of gegevensopslagplaatsen, enz.

3. De gegevenslaag is de databaseserver: onze server communiceert ermee. Deze laag slaat alle informatie op die nodig is om de applicatie te laten werken.

Onze server neemt dus alle verantwoordelijkheid op zich voor toegang tot de gegevens en staat de gebruiker niet toe om er rechtstreeks toegang toe te krijgen.

Voordelen van een architectuur met drie lagen

Een architectuur als deze geeft ons veel voordelen, waaronder:

1. De mogelijkheid om te beschermen tegen SQL-injectie (dit is een aanval op een server; het gaat om het verzenden van SQL-code die, wanneer uitgevoerd, een aanvaller in staat stelt onze database te beïnvloeden).

2. Scheiding van de gegevens waartoe we de gebruikerstoegang willen controleren.

3. De mogelijkheid om gegevens te wijzigen voordat deze naar de klant worden verzonden.

4. Schaalbaarheid (de mogelijkheid om onze applicatie uit te breiden naar meerdere servers die dezelfde database zullen gebruiken.

5. Minder strenge eisen aan de kwaliteit van gebruikersaansluitingen. Bij het genereren van een reactie op de server halen we vaak veel verschillende informatie uit een database en formatteren we deze, zodat alleen overblijft wat de gebruiker nodig heeft. Door dit te doen, verminderen we de hoeveelheid informatie die we in ons antwoord naar de klant sturen.

Hoe vaak moeten architecturale patronen worden gebruikt?

Als u bijvoorbeeld bekend bent met het ontwerppatroon van de fabrieksmethode , heeft u zich waarschijnlijk afgevraagd wanneer u het moet gebruiken. Soms is het moeilijk om te beslissen wat te doen: maak een object met de nieuwe operator of met een fabrieksmethode. Maar na verloop van tijd komt het begrip. Dingen zijn weinig anders als het gaat om architecturale patronen. Enterprise-frameworks zijn ontworpen om een ​​programmeur in staat te stellen een project te maken op basis van een algemeen geaccepteerd patroon. Daarom moet u, voordat u het Spring Framework leert kennen, zeker de client-serverarchitectuur, de drielaagse architectuur en de MVC-architectuur begrijpen. Maak je geen zorgen: we zullen het nog hebben over de MVC-architectuur. Deel 3. HTTP/HTTPS Deel 4. De basisprincipes van Maven Deel 5. Servlets en de Java Servlet API. Een eenvoudige webapplicatie schrijven Deel 6. Servlet-containers Deel 7. Introductie van het MVC-patroon (Model-View-Controller)