Del 2. Låt oss prata lite om mjukvaruarkitektur

Detta material är en del av serien "Introduktion till företagsutveckling" . Den första delen, om nätverkande, är här . Mjukvaruarkitektur avser strukturen som skapas inom en applikation, dvs hela programmets moduler och komponenter och hur de samverkar. Programmerare har arbetat med bra arkitekturer under en mycket lång tid, så det är inte förvånande att vi har hört talas om många arkitektoniska mönster. Du måste förstå dem: när du skriver en webbapplikation är det viktigt att komma med en bra arkitektur, eftersom en webbapplikation har fler komponenter och moduler än en vanlig applikation. Ett arkitektoniskt mönsterär ett smart sätt att lösa vissa mjukvarudesignproblem. Du har förmodligen stött på designmönster som fabriksmetod, abstrakt fabrik, byggare, prototyp, singleton och möjligen andra. Vi använder dem när vi skriver kod, skapar klasser och planerar hur klasserna ska interagera. Arkitektoniska mönster används på en högre abstraktionsnivå, när man planerar användarens interaktion med servrar, data och andra komponenter. Låt oss ta en snabb titt på några mönster och hur man använder dem.

Klient-server-arkitektur

Namnet skapar intrycket att allt med detta mönster är enkelt och tydligt. Men låt oss förtydliga några punkter, så att när du börjar studera Spring kommer du att förstå vad vi pratar om. Låt oss säga att du har skrivit en chattapp och att du och en vän börjar använda den. Du kan använda ett mycket enkelt tillvägagångssätt, skicka meddelanden till varandra direkt via Internet med hjälp av kända IP-adresser: Till en början verkar allt fungera bra tills en annan av dina vänner ber om att få gå med i chatten. Så när du bestämmer dig för att lägga till din gemensamma vän till chatten står du inför ett arkitektoniskt problem: för varje chattdeltagare måste du ge aktuell information om antalet användare och IP-adressen för nya användare. Och när ett meddelande skickas måste det levereras till alla deltagare. Det är de mest uppenbara problemen som kommer att uppstå. Ytterligare ett gäng problem kommer att döljas i själva koden. För att undvika dem måste du använda en server, som kommer att lagra all information om användare, inklusive deras adresser. Meddelanden behöver bara skickas till servern. Den skickar i sin tur meddelanden till var och en av mottagarna. När du bestämmer dig för att lägga till en serverdel i din chattapp börjar du bygga en klient-server-arkitektur.

Komponenter i klient-server-arkitekturen

Låt oss se vad det handlar om. En klient-serverarkitektur är ett designmönster som används för att skapa webbapplikationer. Denna arkitektur består av tre komponenter:

1. Klient — Från dess namn kan vi säga att den här komponenten använder någon tjänst (webbapplikationen), och kontaktar en server för att begära information.

2. Server — Det är här din webbapplikation eller serverdelen av den finns. Den lagrar nödvändig användarinformation eller kan begära den. Dessutom, när en klient skickar en begäran är det servern som returnerar den begärda informationen.

3. Nätverk — Den här delen är enkel. Det underlättar utbytet av information mellan klienten och servern.

Servern kan hantera ett stort antal förfrågningar från olika användare. Det gör att det kan finnas många kunder. Om de behöver utbyta information sinsemellan måste detta ske via servern. Servern har alltså en annan funktion: trafikkontroll. När det gäller vårt chattprogram för flera användare kommer hela applikationen att bestå av två moduler:

• en klientmodul — innehåller ett grafiskt gränssnitt för att logga in och skicka/ta emot meddelanden

• en servermodul — en webbapplikation som finns på en server och som tar emot meddelanden från användare, bearbetar dem och sedan skickar dem till mottagare

När vi vill titta på användbar (eller inte särskilt användbar) information på Internet öppnar vi en webbläsare, anger en fråga i sökfältet och får information från sökmotorn som svar. I denna kedja är webbläsaren klienten. Den skickar en förfrågan med information om vad vi letar efter till servern. Servern bearbetar förfrågan, hittar de mest relevanta resultaten, paketerar dem i ett format som webbläsaren (klienten) kan förstå och skickar tillbaka dem. Komplexa tjänster som sökmotorer kan ha många servrar. Till exempel en auktoriseringsserver, en server för att hitta information, en server för att generera svaret, etc. Men klienten är omedveten om och bryr sig inte om något av detta: för klienten är servern en enhetlig enhet. Kunden känner bara till ingångspunkten, dvs. adressen till servern som förfrågningar ska skickas till. Kom ihåg ansökan som vi granskade iföregående del av denna serie . Det var för att övervaka den genomsnittliga lufttemperaturen i alla länder i realtid. Dess arkitektur ser ut ungefär så här: Vår applikation finns på servern. Låt oss säga att det var femte sekund skickar förfrågningar till servrar som drivs av lokala meteorologiska stationer, tar emot temperaturinformation för ett visst land från servrarna och lagrar denna information. När kunden ber oss att "se världens aktuella lufttemperatur" returnerar vi den senast lagrade informationen, sorterad efter land. Således fungerar vår applikation både som en server (när den behandlar användarförfrågningar) och en klient (när den tar emot information från andra servrar). En enkel klient-server-arkitektur används mycket sällan och endast för mycket enkla applikationer. För riktigt stora och komplexa projekt använder vi olika arkitekturer, som du kommer att möta i framtiden. Låt oss nu titta på en modell som är mycket lik klient-server-arkitekturen.

Trestegsarkitektur

Detta är ett arkitektoniskt mönster som introducerar en tredje modul - datalagring . I det här mönstret kallas de tre nivåerna vanligtvis för lager eller nivåer:

1. Klientlagret är användargränssnittet, även kallat presentationsnivån. Det kan vara en webbläsare som tar emot HTML-sidor, eller ett grafiskt användargränssnitt skrivet med JavaFX. Huvudsaken är att detta lager låter användaren skicka förfrågningar till servern och bearbeta dess svar.

2. Det logiska lagret är servern som behandlar förfrågningar/svar. Ofta kallas det även för serverlagret. Det är också här alla logiska operationer äger rum: matematiska beräkningar, dataoperationer, anrop till andra tjänster eller datalagringar etc.

3. Datalagret är databasservern: vår server interagerar med den. Detta lager lagrar all information som behövs för att applikationen ska fungera.

Således tar vår server på sig allt ansvar för att komma åt data och tillåter inte användaren att komma åt den direkt.

Fördelar med en arkitektur i tre nivåer

En arkitektur som denna ger oss många fördelar, inklusive:

1. Möjligheten att skydda mot SQL-injektion (detta är en attack på en server; det innebär att skicka SQL-kod som, när den exekveras, tillåter en angripare att påverka vår databas).

2. Separation av data som vi vill kontrollera användaråtkomst till.

3. Möjligheten att ändra data innan de skickas till klienten.

4. Skalbarhet (möjligheten att utöka vår applikation till flera servrar som kommer att använda samma databas.

5. Mindre stränga krav på kvaliteten på användaranslutningar. När vi genererar ett svar på servern får vi ofta mycket olika information från en databas och formaterar den, så att bara det som användaren behöver lämnas kvar. Genom att göra detta minskar mängden information som vi skickar i vårt svar till kunden.

Hur ofta ska arkitektoniska mönster användas?

Om du är bekant med, säg, fabriksmetodens designmönster , har du förmodligen undrat när du ska använda det. Ibland är det svårt att bestämma vad man ska göra: skapa ett objekt med den nya operatorn eller med en fabriksmetod. Men med tiden kommer förståelsen. Saker och ting är lite annorlunda när det kommer till arkitektoniska mönster. Enterprise-ramverk är utformade för att tillåta en programmerare att skapa ett projekt baserat på något allmänt accepterat mönster. Följaktligen, innan du lär dig Spring Framework, bör du definitivt förstå klient-server-arkitekturen, treskiktsarkitekturen och MVC-arkitekturen. Oroa dig inte: vi kommer ännu att prata om MVC-arkitekturen. Del 3. HTTP/HTTPS Del 4. Grunderna i Maven Del 5. Servlets och Java Servlet API. Att skriva en enkel webbapplikation Del 6. Servletbehållare Del 7. Introduktion av MVC-mönstret (Model-View-Controller)