7. rész Az MVC (Model-View-Controller) minta bemutatása

Ez az anyag a "Bevezetés a vállalkozásfejlesztésbe" sorozat része. Korábbi cikkek:

• a hálózatépítésről
• a szoftver architektúráról
• a HTTP/HTTPS-ről
• a Maven alapjairól
• a szervletekről (egy egyszerű webalkalmazás írása)
• servlet konténerekről

Ebben a cikkben megismerjük az MVC-t. Beszélünk arról, hogy mi az MVC, érintjük a történetét, feltárjuk az MVC-ben megtestesülő alapötleteket és koncepciókat, lépésről lépésre megnézzük, hogyan bonthatunk fel egy alkalmazást Model, View és Controller modulokra, írunk egy kis webalkalmazást a Spring Boot használatával, és a Spring MVC példaként való felhasználásával megtekintheti, hogyan kerülnek az adatok a Java kódból a HTML oldalakra. Az anyag megértéséhez ismernie kell a tervezési mintákat, különösen a megfigyelőt és a homlokzatot. Ismerje meg a HTTP-kéréseket és -válaszokat, ismerje meg a HTML alapjait, és ismerje meg, mik a Java annotációk. Igyál meg egy csésze kávét és nassolj, és helyezkedj el kényelmesen. Kezdjük.

Az MVC története

Az MVC mögött meghúzódó ötleteket Trygve Reenskaug fogalmazta meg, miközben a Xerox PARC-nál dolgozott az 1970-es évek végén. Akkoriban a számítógéppel való munkavégzés megkövetelte a diplomát és a terjedelmes dokumentáció folyamatos tanulmányozását. A Reenskaug egy nagyon erős fejlesztőcsoporttal közösen megoldott feladat az volt, hogy egyszerűsítse a hétköznapi felhasználó számítógéppel való interakcióját. Olyan eszközöket kellett létrehozni, amelyek egyrészt rendkívül egyszerűek és érthetőek lennének, másrészt lehetővé teszik a számítógépek, összetett alkalmazások vezérlését. Reenskaug egy olyan csapaton dolgozott, amely Alan Kay vezetésével egy laptopot fejlesztett ki „minden életkorú gyermekek számára” – a Dynabookot, valamint a SmallTalk nyelvet. Ekkor határozták meg a barátságos felület fogalmait. Sok tekintetben, Reenskaug és csapata által végzett munka befolyásolta az IT szféra fejlődését. Itt van egy érdekes tény, amely nem vonatkozik közvetlenül az MVC-re, de jól szemlélteti e fejlesztések jelentőségét. Alan Kaymondott, "Amikor először eljutottam az Apple-hez, ami 84-ben volt, a Mac már megjelent, és a Newsweek megkeresett, és megkérdezte, mit gondolok a Macről. Azt mondtam: "Nos, a Mac az első személyi számítógép, amely elég jó ahhoz, hogy kritizálják. Szóval, miután 2007-ben bejelentette az iPhone-t, felhozta nekem, és átadta, és azt mondta: "Alan, ez elég jó ahhoz, hogy kritizálják?" És azt mondtam: "Steve, csináld akkora, mint egy táblagép, és uralni fogod a világot." 3 év után, 2010. január 27-én az Apple bemutatta a 9,7 hüvelykes átlójú iPadet. Más szavakkal, Steve Jobs szinte pontosan követte Alan Kay tanácsát. Reenskaug projektje 10 évig tartott. De az első publikáció az MVC-ről újabb 10 év után látott napvilágot. Martin Fowler, számos könyv és cikk szerzője a szoftverarchitektúráról, megemlíti, hogy az MVC-t a Smalltalk működő verziójával tanulta. Mivel az MVC-ről az eredeti forrásból sokáig nem volt információ, és több más okból is, ennek a fogalomnak nagyszámú különböző értelmezése jelent meg. Ennek eredményeként sokan az MVC-t tervezési mintának tekintik. Ritkábban az MVC-t összetett mintának vagy több minta kombinációjának nevezik, amelyek együttesen alkotnak összetett alkalmazásokat. De, ahogy korábban említettük, az MVC valójában elsősorban építészeti ötletek/elvek/megközelítések halmaza, amelyek különféle minták segítségével többféleképpen is megvalósíthatók... Ezután az MVC koncepcióba ágyazott főbb ötleteket tekintjük át. és több más okból is nagyszámú különböző értelmezése jelent meg ennek a fogalomnak. Ennek eredményeként sokan az MVC-t tervezési mintának tekintik. Ritkábban az MVC-t összetett mintának vagy több minta kombinációjának nevezik, amelyek együttesen alkotnak összetett alkalmazásokat. De, ahogy korábban említettük, az MVC valójában elsősorban építészeti ötletek/elvek/megközelítések halmaza, amelyek különféle minták segítségével többféleképpen is megvalósíthatók... Ezután az MVC koncepcióba ágyazott főbb ötleteket tekintjük át. és több más okból is nagyszámú különböző értelmezése jelent meg ennek a fogalomnak. Ennek eredményeként sokan az MVC-t tervezési mintának tekintik. Ritkábban az MVC-t összetett mintának vagy több minta kombinációjának nevezik, amelyek együttesen alkotnak összetett alkalmazásokat. De, ahogy korábban említettük, az MVC valójában elsősorban építészeti ötletek/elvek/megközelítések halmaza, amelyek különféle minták segítségével többféleképpen is megvalósíthatók... Ezután az MVC koncepcióba ágyazott főbb ötleteket tekintjük át.

MVC: Alapötletek és alapelvek

• A VC olyan építészeti ötletek és alapelvek halmaza, amelyek felhasználói felülettel rendelkező komplex információs rendszerek felépítéséhez szükségesek
• Az MVC egy rövidítés, ami a következőt jelenti: Model-View-Controller

Jogi nyilatkozat: Az MVC nem tervezési minta. Az MVC olyan építészeti ötletek és alapelvek összessége, amelyek felhasználói felülettel rendelkező komplex rendszerek felépítéséhez szükségesek. De a kényelem kedvéért, hogy ne mondjuk ismételten "építészeti ötletek halmaza...", hivatkozzunk az MVC mintára. Kezdjük az egyszerűvel. Mi rejtőzik a Model-View-Controller szavak mögött? Ha MVC mintát használ felhasználói felülettel rendelkező rendszerek fejlesztésére, a rendszert három részre kell osztani. Moduloknak vagy komponenseknek is nevezhetjük őket. Nevezd őket, ahogy akarod, de oszd három részre a rendszert. Minden összetevőnek megvan a maga célja. Modell. Az első komponenst/modult modellnek nevezzük. Tartalmazza az alkalmazás összes üzleti logikáját. Kilátás.A rendszer második része a nézet. Ez a modul felelős az adatok megjelenítéséért a felhasználó számára. Minden, amit a felhasználó lát, a nézet generálja. Vezérlő.A harmadik láncszem a vezérlő. Tartalmazza azt a kódot, amely a felhasználói műveletek kezeléséért felelős (az összes felhasználói műveletet a vezérlő kezeli). A modell a rendszer legfüggetlenebb része. Annyira független, hogy nem tud semmit a nézet és a vezérlő modulokról. A modell annyira független, hogy fejlesztői gyakorlatilag semmit sem tudnak a nézetről és a vezérlőről. A nézet fő célja, hogy a modellből információt adjon a felhasználó által fogyasztható formátumban. A nézet fő korlátja, hogy semmilyen módon nem változtathatja meg a modellt. A vezérlő fő célja a felhasználói műveletek kezelése. A felhasználó a vezérlőn keresztül módosítja a modellt. Pontosabban a modellben tárolt adatokra. Íme a diagram, amelyet korábban láttál a leckében: Mindebből logikus következtetést vonhatunk le. Egy összetett rendszert modulokra kell osztani. Röviden írjuk le az elválasztás lépéseit.

1. lépés: Válassza le az alkalmazás üzleti logikáját a felhasználói felületről

Az MVC alapötlete, hogy bármely felhasználói felülettel rendelkező alkalmazás 2 modulra osztható: az üzleti logika megvalósításáért felelős modulra és a felhasználói felületre. Az első modul megvalósítja az alkalmazás fő funkcióit. Ez a modul a rendszer magja, ahol az alkalmazás tartománymodelljét implementálják. Az MVC paradigmában ez a modul az M betű, azaz a modell. A második modul megvalósítja a teljes felhasználói felületet, beleértve az adatok felhasználó számára történő megjelenítésének és az alkalmazással való felhasználói interakció kezelésének logikáját. Ennek a szétválasztásnak a fő célja annak biztosítása, hogy a rendszer magja (MVC terminológiában a "modell") függetlenül fejleszthető és tesztelhető legyen. A szétválasztás után az alkalmazás architektúrája így néz ki:

2. lépés Használja a megfigyelő mintát a modell még függetlenebbé tételéhez és a felhasználói felületek szinkronizálásához

2 célunk van:

1. Érjen el még nagyobb függetlenséget a modell számára
2. A felhasználói felületek szinkronizálása

A következő példa segít megérteni, mit értünk a felhasználói felületek szinkronizálása alatt. Tegyük fel, hogy online mozijegyet vásárolunk, és megnézzük a szabad helyek számát a moziban. Ugyanakkor lehet, hogy valaki más vásárol mozijegyet. Ha ez a másik személy előttünk vásárol jegyet, akkor szeretnénk, ha csökkenne a férőhelyek száma az általunk fontolóra vett műsoridőben. Most pedig gondoljuk át, hogyan valósítható meg ez egy programon belül. Tegyük fel, hogy megvan a rendszerünk magja (modellünk) és felületünk (a jegyvásárlás weboldala). Két felhasználó egyszerre próbál helyet választani a színházban. Az első felhasználó jegyet vásárol. A weboldalnak meg kell mutatnia a második felhasználónak, hogy ez megtörtént. Hogyan kellene ennek megtörténnie? Ha a felületet a magról frissítjük, akkor a mag (modellünk) az interfésztől függ. A modell fejlesztése és tesztelése során szem előtt kell tartanunk a felület frissítésének különféle módjait. Ennek eléréséhez meg kell valósítanunk a megfigyelői mintát. Ez a minta lehetővé teszi, hogy a modell változási értesítéseket küldjön az összes hallgatónak. Eseményfigyelőként (vagy megfigyelőként) a felhasználói felület értesítéseket kap és frissül. Egyrészt a megfigyelő minta lehetővé teszi, hogy a modell tájékoztassa az interfészt (nézetet és vezérlőt) arról, hogy változások történtek anélkül, hogy ténylegesen tudna róla semmit, így független marad. Másrészt lehetővé teszi a felhasználói felületek szinkronizálását. meg kell valósítanunk a megfigyelői mintát. Ez a minta lehetővé teszi, hogy a modell változási értesítéseket küldjön az összes hallgatónak. Eseményfigyelőként (vagy megfigyelőként) a felhasználói felület értesítéseket kap és frissül. Egyrészt a megfigyelő minta lehetővé teszi, hogy a modell tájékoztassa az interfészt (nézetet és vezérlőt) arról, hogy változások történtek anélkül, hogy ténylegesen tudna róla semmit, így független marad. Másrészt lehetővé teszi a felhasználói felületek szinkronizálását. meg kell valósítanunk a megfigyelői mintát. Ez a minta lehetővé teszi, hogy a modell változási értesítéseket küldjön az összes hallgatónak. Eseményfigyelőként (vagy megfigyelőként) a felhasználói felület értesítéseket kap és frissül. Egyrészt a megfigyelő minta lehetővé teszi, hogy a modell tájékoztassa az interfészt (nézetet és vezérlőt) arról, hogy változások történtek anélkül, hogy ténylegesen tudna róla semmit, így független marad. Másrészt lehetővé teszi a felhasználói felületek szinkronizálását.

3. lépés Válassza szét az interfészt nézetből és vezérlőből

Folytatjuk az alkalmazás modulokra osztását, de most a hierarchia alacsonyabb szintjén. Ebben a lépésben a felhasználói felület (amelyet az 1. lépésben külön modulra osztottunk) egy nézetre és egy vezérlőre van felosztva. Nehéz szigorú határvonalat húzni a nézet és a vezérlő között. Ha azt mondjuk, hogy a nézet az, amit a felhasználó lát, és a vezérlő az a mechanizmus, amely lehetővé teszi a felhasználó számára, hogy interakcióba lépjen a rendszerrel, akkor rámutathat egy ellentmondásra. A vezérlőelemek, például a weboldalon lévő gombok vagy a telefon képernyőjén lévő virtuális billentyűzet alapvetően a vezérlő részét képezik. De ugyanúgy láthatóak a felhasználó számára, mint a nézet bármely része. Amiről itt valójában beszélünk, az a funkcionális szétválasztás. A felhasználói felület fő feladata, hogy megkönnyítse a felhasználó interakcióját a rendszerrel.

• kiadja és kényelmesen megjeleníti a rendszerinformációkat a felhasználó számára
• adja meg a felhasználói adatokat és parancsokat (közölje a rendszerrel)

Ezek a funkciók határozzák meg, hogy a felhasználói felületet hogyan kell modulokra osztani. A rendszerarchitektúra végül így néz ki: És így jutunk el egy három modulból álló alkalmazáshoz, amelyet modellnek, nézetnek és vezérlőnek neveznek. Összefoglaljuk:

1. Az MVC paradigma elvei szerint egy rendszert modulokra kell osztani.
2. A legfontosabb és független modul a modell legyen.
3. A modell a rendszer magja. Lehetővé kell tenni a felhasználói felülettől függetlenül történő fejlesztését és tesztelését.
4. Ennek eléréséhez a felosztás első lépésében a rendszert modellre és felhasználói felületre kell felosztanunk.
5. Ezután a megfigyelő minta segítségével erősítjük a modell függetlenségét és szinkronizáljuk a felhasználói felületeket.
6. A harmadik lépés a felhasználói felület felosztása vezérlőre és nézetre.
7. Minden, ami a felhasználói adatok rendszerbe történő fogadásához szükséges, a vezérlőben található.
8. A nézetben minden szükséges információ a felhasználóhoz való eljuttatásához.

Még egy fontos dolog, amit meg kell beszélned, mielőtt meginnád a forró csokit.

Egy kicsit arról, hogy a nézet és a vezérlő hogyan működik együtt a modellel

A vezérlőn keresztül történő információbevitellel a felhasználó megváltoztatja a modellt. Vagy legalábbis a felhasználó módosítja a modelladatokat. Amikor a felhasználó információt kap az interfész elemeken keresztül (a nézeten keresztül), a felhasználó információt kap a modellről. Hogyan történik ez? Milyen eszközökkel lép kapcsolatba a nézet és a vezérlő a modellel? Végül is a nézet osztályai nem hívhatják meg közvetlenül a modell osztályainak metódusait adatok olvasására/írására. Ellenkező esetben nem mondhatnánk, hogy a modell független. A modell szorosan kapcsolódó osztályok halmaza, amelyekhez sem a nézetnek, sem a vezérlőnek nem szabad hozzáférnie. A modell nézethez és vezérlőhöz való csatlakoztatásához meg kell valósítanunk a homlokzati tervezési mintát. A modell homlokzata a modell és a felhasználói felület közötti réteg, amelyen keresztül a nézet kényelmesen formázott adatokat kap, a Vezérlő pedig a szükséges metódusok előhívásával módosítja az adatokat. A végén minden így néz ki:

MVC: Mit nyerünk?

Az MVC paradigma fő célja az üzleti logika (a modell) megvalósításának elválasztása a vizualizációtól (a nézet). Ez a szétválasztás növeli a kód újrafelhasználásának lehetőségeit. Az MVC előnyei akkor a legnyilvánvalóbbak, ha ugyanazokat az adatokat különböző formátumokban kell bemutatnunk. Például táblázatként, grafikonként vagy diagramként (különböző nézetekkel). Ugyanakkor anélkül, hogy befolyásolnánk a nézetek megvalósítását, megváltoztathatjuk, hogyan reagálunk a felhasználói műveletekre (gombkattintás, adatbevitel). Ha követi az MVC elveit, leegyszerűsítheti a szoftverfejlesztést, növelheti a kód olvashatóságát, valamint javíthatja a bővíthetőséget és a karbantarthatóságot. A „Bevezetés a vállalatfejlesztésbe” sorozat utolsó cikkében a Spring MVC segítségével épített MVC-megvalósítást tekintjük meg. 8. rész. Írjunk egy kis alkalmazást a Spring Boot segítségével