Del 2. Lad os tale lidt om softwarearkitektur

Dette materiale er en del af serien "Introduktion til virksomhedsudvikling" . Den første del, om netværk, er her . Softwarearkitektur refererer til den struktur, der skabes i en applikation, dvs. hele programmets moduler og komponenter, og hvordan de interagerer. Programmører har arbejdet på gode arkitekturer i meget lang tid, så det er ikke overraskende, at vi har hørt om mange arkitektoniske mønstre. Du skal forstå dem: Når du skriver en webapplikation, er det afgørende at komme med en god arkitektur, fordi en webapplikation har flere komponenter og moduler end en almindelig applikation. Et arkitektonisk mønsterer en smart måde at løse nogle softwaredesignproblemer på. Du er sikkert stødt på designmønstre som fabriksmetode, abstrakt fabrik, builder, prototype, singleton og muligvis andre. Vi bruger dem til, når vi skriver kode, opretter klasser og planlægger, hvordan klasserne skal interagere. Arkitektoniske mønstre bruges på et højere abstraktionsniveau, når man planlægger brugerens interaktion med servere, data og andre komponenter. Lad os tage et hurtigt kig på nogle mønstre, og hvordan man bruger dem.

Klient-server arkitektur

Navnet skaber indtryk af, at alt ved dette mønster er enkelt og klart. Men lad os præcisere nogle punkter, så når du begynder at studere forår, vil du forstå, hvad vi taler om. Lad os sige, at du har skrevet en chat-app, og du og en ven begynder at bruge den. Du kan bruge en meget enkel tilgang, og sende beskeder til hinanden direkte via internettet ved hjælp af kendte IP-adresser: I starten virker alt tilsyneladende fint, indtil en anden af ​​dine venner beder om at deltage i chatten. Så når du beslutter dig for at tilføje din fælles ven til chatten, står du over for et arkitektonisk problem: For hver chat-deltager skal du give aktuelle oplysninger om antallet af brugere og IP-adressen på nye brugere. Og når en besked sendes, skal den leveres til alle deltagere. Det er de mest åbenlyse problemer, der vil opstå. En anden masse problemer vil være skjult i selve koden. For at undgå dem skal du bruge en server, som vil gemme alle oplysninger om brugere, inklusive deres adresser. Beskeder skal kun sendes til serveren. Det sender til gengæld beskeder til hver af modtagerne. Når du beslutter dig for at tilføje en serverdel til din chat-app, begynder du at bygge en klient-server-arkitektur.

Komponenter i klient-server-arkitekturen

Lad os se, hvad det handler om. En klient-server-arkitektur er et designmønster, der bruges til at skabe webapplikationer. Denne arkitektur består af tre komponenter:

1. Klient — Fra dens navn kan vi fortælle, at denne komponent bruger en eller anden tjeneste (webapplikationen), og kontakter en server for at anmode om nogle oplysninger.

2. Server — Det er her din webapplikation eller serverdelen af ​​den er placeret. Det gemmer de nødvendige brugeroplysninger eller kan anmode om det. Derudover, når en klient sender en anmodning, er det serveren, der returnerer de anmodede oplysninger.

3. Netværk — Denne del er enkel. Det letter udvekslingen af ​​information mellem klienten og serveren.

Serveren kan håndtere et stort antal anmodninger fra forskellige brugere. Det betyder, at der kan være mange kunder. Hvis de har brug for at udveksle information indbyrdes, skal dette ske via serveren. Serveren har således en anden funktion: trafikkontrol. Hvad angår vores multi-user chat program, vil hele applikationen bestå af to moduler:

• et klientmodul — indeholder en grafisk grænseflade til at logge på og sende/modtage beskeder

• et servermodul — en webapplikation, der er hostet på en server og modtager beskeder fra brugere, behandler dem og derefter sender dem til modtagere

Når vi vil se på nyttig (eller ikke særlig nyttig) information på internettet, åbner vi en browser, indtaster en forespørgsel i søgefeltet og får information fra søgemaskinen som svar. I denne kæde er browseren klienten. Den sender en anmodning med information om, hvad vi leder efter, til serveren. Serveren behandler anmodningen, finder de mest relevante resultater, pakker dem i et format, som browseren (klienten) kan forstå og sender dem tilbage. Komplekse tjenester som søgemaskiner kan have mange servere. For eksempel en autorisationsserver, en server til at finde information, en server til at generere svaret osv. Men klienten er uvidende om og ligeglad med noget af dette: for klienten er serveren en samlet enhed. Klienten kender kun indgangspunktet, dvs. adressen på den server, som anmodninger skal sendes til. Husk den ansøgning, vi undersøgte iden forrige del af denne serie . Det var til overvågning af den gennemsnitlige lufttemperatur i alle lande i realtid. Dens arkitektur ser nogenlunde sådan ud: Vores applikation er placeret på serveren. Lad os sige, at den hvert femte sekund sender anmodninger til servere, der drives af lokale meteorologiske stationer, modtager temperaturoplysninger for et bestemt land fra serverne og gemmer disse oplysninger. Når klienten beder os om at "se verdens aktuelle lufttemperatur", returnerer vi den senest gemte information, sorteret efter land. Vores applikation fungerer således både som en server (når den behandler brugeranmodninger) og en klient (når den modtager information fra andre servere). En simpel klient-server-arkitektur bruges meget sjældent og kun til meget simple applikationer. Til rigtig store og komplekse projekter bruger vi forskellige arkitekturer, som du vil møde i fremtiden. Lad os nu se på en model, der minder meget om klient-server-arkitekturen.

Tre-lags arkitektur

Dette er et arkitektonisk mønster, der introducerer et tredje modul - datalagring . I dette mønster kaldes de tre niveauer normalt lag eller lag:

1. Klientlaget er brugergrænsefladen, også kaldet præsentationsniveauet. Det kan være en webbrowser, der modtager HTML-sider, eller en grafisk brugergrænseflade skrevet ved hjælp af JavaFX. Det vigtigste er, at dette lag lader brugeren sende anmodninger til serveren og behandle dens svar.

2. Det logiske lag er den server, der behandler anmodninger/svar. Ofte kaldes det også serverlaget. Det er også her alle logiske operationer finder sted: matematiske beregninger, dataoperationer, opkald til andre tjenester eller datalager mv.

3. Datalaget er databaseserveren: vores server interagerer med den. Dette lag gemmer al den information, der er nødvendig for, at applikationen kan fungere.

Vores server påtager sig således alt ansvar for at få adgang til dataene og tillader ikke brugeren at få direkte adgang til dem.

Fordele ved en tre-lags arkitektur

En arkitektur som denne giver os mange fordele, herunder:

1. Evnen til at beskytte mod SQL-injektion (dette er et angreb på en server; det involverer at sende SQL-kode, der, når den udføres, tillader en angriber at påvirke vores database).

2. Adskillelse af de data, som vi ønsker at kontrollere brugeradgang til.

3. Muligheden for at ændre data, før de sendes til klienten.

4. Skalerbarhed (evnen til at udvide vores applikation til flere servere, der vil bruge den samme database.

5. Mindre strenge krav til kvaliteten af ​​brugerforbindelser. Når vi genererer et svar på serveren, får vi ofte en masse forskellig information fra en database og formaterer den, så der kun er tilbage, hvad brugeren har brug for. Dette reducerer mængden af ​​information, som vi sender i vores svar til kunden.

Hvor ofte skal arkitektoniske mønstre bruges?

Hvis du er bekendt med f.eks. fabriksmetodens designmønster , har du sikkert spekuleret på, hvornår du skal bruge det. Nogle gange er det svært at beslutte, hvad man skal gøre: oprette et objekt ved hjælp af den nye operatør eller ved hjælp af en fabriksmetode. Men med tiden kommer forståelsen. Tingene er lidt anderledes, når det kommer til arkitektoniske mønstre. Enterprise frameworks er designet til at give en programmør mulighed for at skabe et projekt baseret på et generelt accepteret mønster. Derfor, før du lærer Spring Framework, bør du helt sikkert forstå klient-server-arkitekturen, tre-lags-arkitekturen og MVC-arkitekturen. Bare rolig: vi vil endnu tale om MVC-arkitekturen. Del 3. HTTP/HTTPS Del 4. Det grundlæggende i Maven Del 5. Servlets og Java Servlet API. Skrivning af en simpel webapplikation Del 6. Servlet-beholdere Del 7. Introduktion til MVC (Model-View-Controller) mønsteret