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:
-
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.
-
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.
-
Netværk — Denne del er enkel. Det letter udvekslingen af information mellem klienten og serveren.
-
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).
| Her er en vigtig pointe: Konceptet med en server handler ikke om en bestemt computer, men snarere om forholdet mellem netværksenheder . |
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:
-
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.
-
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.
-
Datalaget er databaseserveren: vores server interagerer med den. Dette lag gemmer al den information, der er nødvendig for, at applikationen kan fungere.
Fordele ved en tre-lags arkitektur
En arkitektur som denne giver os mange fordele, herunder:-
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).
-
Adskillelse af de data, som vi ønsker at kontrollere brugeradgang til.
-
Muligheden for at ændre data, før de sendes til klienten.
-
Skalerbarhed (evnen til at udvide vores applikation til flere servere, der vil bruge den samme database.
-
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.
GO TO FULL VERSION