Bevezetés az MVC architektúrába
A legnépszerűbb alkalmazásarchitektúra, amelyet minden programozó ismer, az MVC . Az MVC a Model-View-Controller rövidítése .
Ez nem annyira az alkalmazások architektúrája, mint inkább az alkalmazáskomponensek architektúrája, de erre az árnyalatra később még visszatérünk. Mi az MVC?
Az MVC egy olyan séma, amely az alkalmazásadatokat és a vezérlési logikát három különálló komponensre – modellre, nézetre és vezérlőre – választja szét, így az egyes összetevők egymástól függetlenül módosíthatók.
- A modell (Modell) adatokat szolgáltat, és állapotának megváltoztatásával válaszol a vezérlőparancsokra.
- A Nézet felelős azért, hogy a modelladatokat megjelenítse a felhasználó számára a modellváltozások hatására.
- A Vezérlő (Controller) értelmezi a felhasználó tevékenységét, értesítve a modellt a változtatások szükségességéről.
Ezt a modellt még 1978-ban (!) évben találták fel. Igen, a megfelelő szoftverarchitektúrával kapcsolatos problémák 50 évvel ezelőtt is relevánsak voltak. Ezt a modellt a következőképpen írja le az eredeti ábrája:
A modell adatokat és módszereket biztosít a velük való munkavégzéshez: lekérdezések az adatbázisba, helyesség-ellenőrzés. A modell független a nézettől (nem tudja, hogyan kell megjeleníteni az adatokat) és a vezérlőtől (nincs felhasználói interakciós pontja), hozzáférést és kezelést biztosít az adatokhoz.
A modell úgy épül fel, hogy állapotának megváltoztatásával válaszoljon a kérésekre, és beépíthető a „megfigyelők” értesítése. A modellnek a vizuális reprezentációtól való függetlensége miatt több különböző reprezentációja is lehet egy „modellhez”.
A nézet felelős azért, hogy a szükséges adatokat megkapja a modelltől és elküldje a felhasználónak. A nézet nem dolgozza fel a felhasználói bevitelt.
A vezérlő biztosítja a „kommunikációt” a felhasználó és a rendszer között. Vezérli és irányítja az adatokat a felhasználótól a rendszerbe és fordítva. Modellt és nézetet használ a kívánt művelet végrehajtásához.
Némi nehézséget okoz az a tény, hogy ez a modell egy kicsit fejlődött az évtizedek során. Vagyis a név ugyanaz maradt, de az alkatrészek célja megváltozni kezdett.
MVC architektúra a weben
Az MVC tervezési mintája mögött meghúzódó ötlet nagyon egyszerű: világosan el kell különítenünk a felelősséget az alkalmazásaink különböző viselkedéseiért:
Modell— adatfeldolgozás és alkalmazáslogika.
Kilátás— adatszolgáltatás a felhasználónak bármilyen támogatott formátumban.
vezérlő- felhasználói kérések feldolgozása és a megfelelő erőforrások lehívása.
Az alkalmazás három fő összetevőre oszlik, amelyek mindegyike más-más feladatokért felelős. Nézzük meg közelebbről egy kliens-szerver alkalmazás összetevőit egy példa segítségével.
Vezérlő
A felhasználó a böngészőben az oldalon található különböző elemekre kattint, aminek eredményeként a böngésző különböző HTTP-kéréseket küld: GET, POST vagy más. A vezérlő tartalmazhatja az oldalon belül működő böngészőt és JS-kódot.
A vezérlő fő funkciója ebben az esetben a metódusok meghívása a szükséges objektumokon, az erőforrásokhoz való hozzáférés kezelése a felhasználó által meghatározott feladatok végrehajtásához. Általában a vezérlő meghívja a feladathoz megfelelő modellt, és kiválasztja a megfelelő nézetet.
Modell
A modell tág értelemben az adatok és szabályok, amelyeket az adatokkal való munkavégzéshez használnak – ezek együttesen alkotják az alkalmazás üzleti logikáját. Egy alkalmazás tervezése mindig az általa működtetett objektumok modelljének elkészítésével kezdődik.
Tegyük fel, hogy van egy könyveket árusító online áruházunk, akkor az ember csak alkalmazás felhasználó, vagy könyv szerzője is? Ezeket a fontos kérdéseket a modelltervezés során meg kell oldani.
Vannak továbbá szabályrendszerek: mit lehet tenni, mit nem, mely adatsorok elfogadhatók és melyek nem. Létezhet-e könyv szerző nélkül? És a szerző könyvek nélkül? Lehet-e a felhasználó születési dátuma 300 és így tovább.
A modell nézetet ad a vezérlőnek a felhasználó által kért adatokról (üzenet, könyvoldal, képek stb.). Az adatmodell ugyanaz lesz, akárhogyan is szeretnénk bemutatni a felhasználónak. Ezért bármelyik elérhető nézetet kiválasztjuk az adatok megjelenítéséhez.
A modell tartalmazza az alkalmazási logikánk legfontosabb részét , azt a logikát, amely megoldja a problémát (fórum, bolt, bank stb.). A vezérlő többnyire magának az alkalmazásnak a szervezeti logikáját tartalmazza (akárcsak a projektmenedzsere).
Kilátás
A nézet különféle módokat kínál a modelltől kapott adatok megjelenítésére. Ez lehet egy adatokkal megtöltött sablon. Többféle nézet is lehet, és a vezérlő kiválasztja, hogy melyik a legjobb az aktuális helyzethez.
A webalkalmazások általában vezérlők, modellek és nézetek halmazából állnak. A vezérlő csak a háttérben lehet, de létezhet több vezérlőből álló változat is, amikor a logikája a frontendre is kiterjed. Jó példa erre a megközelítésre bármely mobilalkalmazás.
MVC példa a weben
Tegyük fel, hogy létre kell hoznia egy online áruházat, amely könyveket árusít. A felhasználó a következő műveleteket hajthatja végre: könyveket tekinthet meg, regisztrálhat, vásárolhat, tételeket adhat hozzá az aktuális rendeléshez, megjelölheti a neki tetsző könyveket és megvásárolhatja azokat.
Az alkalmazásnak rendelkeznie kell egy olyan modellel , amely felelős az összes üzleti logikáért. Szüksége van egy vezérlőre is , amely feldolgozza az összes felhasználói műveletet, és üzleti logikából metódushívásokká alakítja azokat. Egy vezérlő metódus azonban számos különböző modellmódszert hívhat meg.
Nézetkészletekre is szükség van: könyvek listája, információ egy könyvről, bevásárlókosár, rendelések listája. A webalkalmazás minden oldala valójában egy külön nézet, amely a modell egy bizonyos aspektusát jeleníti meg a felhasználó számára.
Nézzük meg, mi történik, ha a felhasználó megnyitja a könyvesboltokban ajánlott könyvek listáját a címek megtekintéséhez. A műveletek teljes sorozata 6 lépésben írható le:
Lépések:
- A felhasználó rákattint az "ajánlott" linkre, és a böngésző kérést küld mondjuk a /books/recommendations címre.
- A vezérlő ellenőrzi a kérést : a felhasználónak be kell jelentkeznie. Vagy könyvgyűjteményeket kellene létrehoznunk a be nem jelentkezett felhasználók számára. A vezérlő ezután felhívja a modellt, és megkéri, hogy küldje vissza az N felhasználónak ajánlott könyvek listáját.
- A modell hozzáfér az adatbázishoz, onnan kér információkat a könyvekről: a jelenleg népszerű könyvekről, a felhasználó által vásárolt könyvekről, a barátai által vásárolt könyvekről, a kívánságlistájáról. Ezen adatok alapján a modell összeállít egy listát 10 ajánlott könyvből, és visszaküldi azokat a vezérlőnek.
- A vezérlő megkapja az ajánlott könyvek listáját, és megnézi. Ebben a szakaszban a kontroller hoz döntéseket! Ha kevés könyv van, vagy a lista teljesen üres, akkor kéri a könyvek listáját egy nem bejelentkezett felhasználó számára. Ha éppen promóció van folyamatban, a vezérlő felvehet promóciós könyveket a listára.
- A vezérlő határozza meg, hogy melyik oldalt jelenítse meg a felhasználónak. Ez lehet egy hibaoldal, egy könyvlistát tartalmazó oldal, egy olyan oldal, amely gratulál ahhoz, hogy a felhasználó milliomodik látogatója lett.
- A szerver megadja a kliensnek a vezérlő által kiválasztott oldalt ( nézetet ). Feltöltve a szükséges adatokkal (felhasználónév, könyvek listája) kerül a klienshez.
- A kliens megkapja az oldalt és megjeleníti a felhasználónak.
Milyen előnyei vannak ennek a megközelítésnek?
A legnyilvánvalóbb előny, amit az MVC-koncepció használatával kapunk, a prezentációs logika (felhasználói felület) és az alkalmazáslogika (háttérrendszer) egyértelmű szétválasztása.
A második előny a szerver rész kettéosztása: egy intelligens modellre ( végrehajtó ) és egy vezérlőre ( döntési központ ).
Az előző példában volt egy pillanat, amikor a vezérlő megkaphatta a modelltől az ajánlott könyvek üres listáját, és eldönthette, mit kezdjen vele. Elméletileg ez a logika közvetlenül a modellbe illeszthető.
Először is, az ajánlott könyvek kérésekor a modell eldönti, mit tegyen, ha a lista üres. Akkor ugyanoda kellene feltennem a kódot, mit tegyek, ha most akció van, akkor több különböző lehetőség.
Aztán kiderült, hogy az üzlet adminisztrátora meg akarta nézni, hogyan nézne ki a felhasználó oldala promóció nélkül, vagy fordítva, most nincs promóció, viszont szeretné látni, hogy a majdani promóció hogyan fog megjelenni. És erre nincsenek módszerek. Ezért úgy döntöttek, hogy a döntési központot (kontrollert) elválasztják az üzleti logikától (modelltől).
A nézetek alkalmazáslogikától való elkülönítése mellett az MVC koncepció nagyban csökkenti a nagy alkalmazások bonyolultságát. A kód sokkal strukturáltabb, ami megkönnyíti a megoldások karbantartását, tesztelését és újrafelhasználását.
Az MVC fogalmának megértése során Ön, mint fejlesztő, rájön, hol kell hozzárendelnie a könyvlistát:
- Az adatbázis lekérdezés szintjén.
- Az üzleti logika (modell) szintjén.
- Üzleti logikai szinten (kontroller).
- A nézetben - az ügyfél oldalon.
És ez nem költői kérdés. Most gondolja át, hol és miért kell hozzáadnia a kódot a könyvek listájának rendezéséhez.
Klasszikus MVC modell
Az MVC-komponensek közötti interakció a webalkalmazásokban és a mobilalkalmazásokban eltérően valósul meg. Ennek az az oka, hogy a webalkalmazás rövid életű, egy felhasználói kérést dolgoz fel és kilép, míg a mobilalkalmazás sok kérést dolgoz fel újraindítás nélkül.
A webes alkalmazások általában a „passzív” modellt használják, míg a mobilalkalmazások az „aktív” modellt. Az aktív modell, ellentétben a passzív modellel, lehetővé teszi az előfizetést és értesítések fogadását a változásairól. Ez nem szükséges a webes alkalmazásokhoz.
Így néz ki a komponensek kölcsönhatása a különböző modellekben:
A mobil alkalmazások (aktív modell) aktívan használják az eseményeket és az esemény-előfizetési mechanizmust. Ezzel a megközelítéssel a nézet ( nézet ) feliratkozik a modellváltozásokra. Ezután, amikor valamilyen esemény történik (például a felhasználó rákattint egy gombra), a vezérlő meghívásra kerül . Ezenkívül parancsot ad a modellnek az adatok megváltoztatására.
Ha néhány adat megváltozott, akkor a modell eseményt generál az adatok módosításáról. Minden olyan nézet, amely feliratkozott erre az eseményre (amelynél fontos az adott adat módosítása), megkapja ezt az eseményt és frissíti az adatokat a felületén.
A webes alkalmazásokban a dolgok egy kicsit másképp vannak megszervezve. A fő technikai különbség az, hogy a kliens nem tud szerveroldali üzeneteket fogadni a szerver kezdeményezésére .
Ezért egy webalkalmazásban lévő vezérlő általában nem küld üzenetet a nézetnek, hanem egy új oldalt ad a kliensnek, ami technikailag egy új nézet vagy akár egy új kliens alkalmazás (ha az egyik oldal nem tud semmit a másikról) .
Jelenleg ez a probléma részben megoldott a következő megközelítésekkel:
- Rendszeresen lekérdezi a szervert a fontos adatok változásairól (percenként egyszer vagy többször).
- A WebSockets lehetővé teszi a kliens számára, hogy előfizessen a szerver üzeneteire.
- Webes push értesítések a szerver oldaláról.
- A HTTP/2 protokoll lehetővé teszi a szerver számára, hogy üzeneteket küldjön a kliensnek.