2. rész. Beszéljünk egy kicsit a szoftver architektúráról

Ez az anyag a "Bevezetés a vállalkozásfejlesztésbe" sorozat része . Az első, a hálózatépítésről szóló rész itt található . A szoftverarchitektúra az alkalmazáson belül létrehozott struktúrát jelenti, azaz a teljes program moduljait és összetevőit, valamint azok interakcióját. A programozók nagyon régóta dolgoznak a jó architektúrákon, így nem meglepő, hogy sok építészeti mintáról hallottunk. Meg kell érteni őket: webalkalmazás írásakor kritikus fontosságú a jó architektúra kialakítása, mivel egy webalkalmazás több összetevőből és modulból áll, mint egy hagyományos alkalmazás. Építészeti mintaegy okos módszer egyes szoftvertervezési problémák megoldására. Valószínűleg találkoztál már olyan tervezési mintákkal, mint a gyári módszer, az absztrakt gyár, az építő, a prototípus, a singleton és esetleg mások. Használjuk őket kód írása, osztályok létrehozása és az osztályok interakciójának megtervezése során. Az építészeti mintákat az absztrakció magasabb szintjén használják, amikor a felhasználó szerverekkel, adatokkal és egyéb összetevőkkel való interakcióját tervezik. Vessünk egy gyors pillantást néhány mintára és azok használatára.

Kliens-szerver architektúra

A név azt a benyomást kelti, hogy ezzel a mintával kapcsolatban minden egyszerű és világos. De tisztázzunk néhány pontot, hogy amikor elkezded tanulmányozni a Tavaszt, megértsd, miről beszélünk. Tegyük fel, hogy írt egy csevegőalkalmazást, és Ön és egy barátja elkezdi használni. Elfogadhat egy nagyon egyszerű megközelítést, amely üzeneteket küld egymásnak közvetlenül az interneten keresztül ismert IP-címek használatával: Eleinte minden jól működik, amíg egy másik barátja fel nem kéri, hogy csatlakozzon a chathez. Így amikor úgy dönt, hogy felveszi közös barátját a chatbe, felépítési problémával kell szembenéznie: minden chat-résztvevő esetében meg kell adnia az aktuális információkat a felhasználók számáról és az új felhasználók IP-címéről. És amikor elküldik az üzenetet, azt minden résztvevőnek el kell juttatni. Ezek a legnyilvánvalóbb problémák, amelyek felmerülhetnek. Egy másik csomó probléma rejtőzik magában a kódban. Ezek elkerüléséhez szervert kell használnia, amely minden információt tárol a felhasználókról, beleértve a címeiket is. Az üzeneteket csak a szervernek kell elküldeni. Ez viszont minden címzettnek üzenetet küld. Amikor úgy dönt, hogy hozzáad egy szerverrészt a csevegőalkalmazáshoz, akkor elkezdi felépíteni a kliens-szerver architektúrát.

A kliens-szerver architektúra összetevői

Lássuk, miről is van szó. A kliens-szerver architektúra egy webalkalmazások létrehozására használt tervezési minta. Ez az architektúra három összetevőből áll:

1. Kliens – A nevéből megállapíthatjuk, hogy ez az összetevő valamilyen szolgáltatást (a webalkalmazást) használ, felveszi a kapcsolatot egy szerverrel, hogy információkat kérjen.

2. Szerver – Itt található a webalkalmazása vagy annak szerver része. A szükséges felhasználói információkat tárolja vagy kérheti. Ezenkívül, amikor egy ügyfél kérést küld, a szerver adja vissza a kért információkat.

3. Hálózat – Ez a rész egyszerű. Megkönnyíti az információcserét a kliens és a szerver között.

A szerver nagyszámú kérést képes kezelni a különböző felhasználóktól. Ez azt jelenti, hogy sok ügyfél lehet. Ha információt kell cserélniük egymás között, ennek a szerveren keresztül kell megtörténnie. Így a szervernek van egy másik funkciója is: a forgalomirányítás. Ami a többfelhasználós chatprogramunkat illeti, az egész alkalmazás két modulból fog állni:

• kliens modul — grafikus felületet tartalmaz a bejelentkezéshez és az üzenetek küldéséhez/fogadásához

• szervermodul – egy webes alkalmazás, amely egy szerveren található, és fogadja a felhasználók üzeneteit, feldolgozza azokat, majd elküldi a címzetteknek

Ha hasznos (vagy nem túl hasznos) információkat szeretnénk nézni az interneten, megnyitunk egy böngészőt, beírunk egy lekérdezést a keresősávba, és válaszul információt kapunk a keresőtől. Ebben a láncban a böngésző a kliens. Kérést küld a szervernek azzal kapcsolatban, hogy mit keresünk. A szerver feldolgozza a kérést, megkeresi a legrelevánsabb találatokat, a böngésző (kliens) számára érthető formátumba csomagolja és visszaküldi. Az összetett szolgáltatásoknak, például a keresőmotoroknak sok szerverük lehet. Például egy jogosultságkiszolgáló, egy információkereső szerver, egy kiszolgáló a válasz generálására stb. De a kliensnek nincs tudomása erről, és nem is foglalkozik vele: a kliens számára a szerver egy egységes entitás. Az ügyfél csak a belépési pontról tud, azaz annak a szervernek a címe, amelyre a kéréseket el kell küldeni. Emlékezzünk vissza az általunk megvizsgált pályázatraa sorozat előző része . Valamennyi ország átlagos léghőmérsékletének valós idejű monitorozására szolgált. Az architektúrája valahogy így néz ki: Alkalmazásunk a szerveren található. Tegyük fel, hogy öt másodpercenként kéréseket küld a helyi meteorológiai állomások által üzemeltetett szervereknek, megkapja a kiszolgálóktól egy adott ország hőmérsékleti adatait, és ezeket az információkat tárolja. Amikor az ügyfél azt kéri tőlünk, hogy „nézzük meg a világ aktuális levegőhőmérsékletét”, visszaküldjük a legutóbb tárolt információkat, országok szerint rendezve. Így alkalmazásunk szerverként (amikor a felhasználói kéréseket dolgozza fel) és kliensként (amikor információkat kap más szerverektől) egyaránt működik. Egy egyszerű kliens-szerver architektúrát nagyon ritkán és csak nagyon egyszerű alkalmazásokhoz használnak. Az igazán nagy és összetett projektekhez különböző architektúrákat használunk, amelyekkel a jövőben találkozni fog. Most nézzünk egy modellt, amely nagyon hasonlít a kliens-szerver architektúrára.

Háromszintű architektúra

Ez egy olyan építészeti minta, amely egy harmadik modult – az adattárolást – vezet be . Ebben a mintában a három szintet általában rétegeknek vagy rétegeknek nevezik:

1. Az ügyfélréteg a felhasználói felület, más néven prezentációs szint. Ez lehet HTML oldalakat fogadó webböngésző, vagy JavaFX segítségével írt grafikus felhasználói felület. A lényeg az, hogy ez a réteg lehetővé teszi a felhasználó számára, hogy kéréseket küldjön a szervernek, és feldolgozza a válaszait.

2. A logikai réteg a kéréseket/válaszokat feldolgozó szerver. Gyakran szerverrétegnek is nevezik. Itt történik minden logikai művelet is: matematikai számítások, adatműveletek, más szolgáltatások vagy adattárolók hívásai stb.

3. Az adatréteg az adatbázisszerver: a szerverünk interakcióba lép vele. Ez a réteg tárolja az alkalmazás működéséhez szükséges összes információt.

Így szerverünk minden felelősséget vállal az adatokhoz való hozzáférésért, és nem engedi, hogy a felhasználó közvetlenül hozzáférjen azokhoz.

A háromszintű architektúra előnyei

Egy ilyen architektúra számos előnnyel jár, többek között:

1. Az SQL-befecskendezés elleni védelem képessége (ez egy szerver elleni támadás; olyan SQL-kód küldésével jár, amely végrehajtása esetén a támadó hatással lehet az adatbázisunkra).

2. Azon adatok elkülönítése, amelyekhez a felhasználói hozzáférést szabályozni kívánjuk.

3. Lehetőség az adatok módosítására az ügyfélnek való elküldés előtt.

4. Skálázhatóság (alkalmazásunk kiterjesztésének lehetősége több szerverre, amelyek ugyanazt az adatbázist használják.

5. Kevésbé szigorú követelmények a felhasználói kapcsolatok minőségére vonatkozóan. Amikor választ generálunk a szerveren, gyakran sok különböző információt kapunk egy adatbázisból, és formázzuk azt, így csak azt hagyjuk meg, amire a felhasználónak szüksége van. Ez csökkenti az ügyfélnek adott válaszunkban elküldött információk mennyiségét.

Milyen gyakran kell építészeti mintákat használni?

Ha valaki ismeri mondjuk a gyári módszeres tervezési mintát, akkor valószínűleg elgondolkodott azon, hogy mikor érdemes használni. Néha nehéz eldönteni, mit tegyen: hozzon létre egy objektumot az új operátorral vagy egy gyári módszerrel. De idővel jön a megértés. A dolgok alig különböznek, ha az építészeti mintákról van szó. A vállalati keretrendszerek célja, hogy lehetővé tegyék a programozó számára, hogy valamilyen általánosan elfogadott minta alapján hozzon létre projektet. Ennek megfelelően a Spring Framework megtanulása előtt feltétlenül ismernie kell a kliens-szerver architektúrát, a háromrétegű architektúrát és az MVC architektúrát. Ne aggódjon: még fogunk beszélni az MVC architektúráról. 3. rész. HTTP/HTTPS 4. rész. A Maven alapjai 5. rész. Szervletek és a Java Servlet API. Egyszerű webalkalmazás írása 6. rész. Szervlet konténerek 7. rész Az MVC (Model-View-Controller) minta bemutatása