A Model-View-Controller meghalt az elülső végén?

Egyre több front-end fejlesztő alkalmaz egyirányú architektúrát. Mi tehát a klasszikus Model-View-Controller (MVC) megközelítés jövője?

Annak érdekében, hogy megértsük, hogyan jutottunk el idáig, először nézzük át a front-end architektúra fejlődését.

Az elmúlt négy évben rengeteg webes projekten dolgoztam, és sok időt töltöttem a kezelőfelületek tervezésével és a keretek integrálásával.

2010 előtt a JavaScriptet - amelybe a jQuery programozási nyelvet írták - főleg arra használták, hogy a DOM-manipulációt hozzáadják a hagyományos weboldalakhoz. Úgy tűnik, hogy a fejlesztők nem sokat törődtek magával az építészettel. Az olyan dolgok, mint a leleplező modulminta, elég jók voltak ahhoz, hogy strukturálják a kódalapjainkat.

A front-end és a back-end architektúráról szóló jelenlegi vitánk csak 2010 végén jött létre. Ekkor kezdték el a fejlesztők komolyan venni az egyoldalas alkalmazás koncepcióját . Ekkor kezdtek népszerűvé válni olyan keretek, mint a Backbone és a Knockout.

Mivel sok olyan elv, amely köré ezek a keretek épültek, akkoriban egészen újnak számítottak, tervezőiknek máshonnan kellett inspirációt keresniük. Olyan gyakorlatokat kölcsönöztek, amelyek már jól beváltak a szerveroldali architektúrához. És abban a pillanatban az összes népszerű szerveroldali keret magában foglalta a klasszikus MVC modell valamilyen megvalósítását (variációi miatt MV * néven is ismert).

Amikor a React.js-t először renderelt könyvtárként mutatták be, sok fejlesztő kigúnyolta, mert intuitívnak vélték a HTML-ben történő JavaScript-kezelés módját. De figyelmen kívül hagyták a React által az asztalra tett legfontosabb hozzájárulást - az alkatrészalapú architektúrát .

A React nem talált ki alkatrészeket, de egy lépéssel tovább vitte ezt az ötletet.

Ezt a jelentős áttörést az építészetben még a Facebook is figyelmen kívül hagyta, amikor a React „V-ben az MVC-ben” hirdették.

Megjegyzendő, hogy még mindig vannak rémálmaim, miután áttekintettem egy kódalapot, amelyen mind az Angular 1.x, mind a React együtt működött.

2015 jelentős elmozdulást hozott számunkra - a megszokott MVC mintától kezdve az egyirányú architektúrákig és a fluxusból és a funkcionális reaktív programozásból származó adatfolyamokba, olyan eszközök támogatásával, mint a Redux vagy az RxJS.

Tehát hol romlott el az MVC számára?

Az MVC valószínűleg még mindig a legjobb módja a szerver oldal kezelésének. Olyan keretekkel, mint a Rails és a Django, öröm dolgozni.

A problémák abból fakadnak, hogy az MVC által a szerveren bevezetett elvek és elválasztások nem ugyanazok, mint az ügyfélnél.

Vezérlő és nézet összekapcsolása

Az alábbiakban bemutatjuk, hogy a Nézet és a Vezérlő hogyan hat egymással a kiszolgálón. Csak két érintési pont van közöttük, mindkettő átlépi az ügyfél és a szerver közötti határt.

Amikor a kliensen az MVC-re költözik, probléma adódik. A vezérlők hasonlítanak az úgynevezett „kód mögött” -re. A vezérlő nagymértékben függ a nézettől. A legtöbb keretrendszer megvalósításában még a Nézet is létrehozza (mint például az ng-controller in Angular esetében).

Ezenkívül, ha az Egységes Felelősség Elvére gondol, ez egyértelműen megszegi a szabályokat. Az ügyfél vezérlő kód foglalkozik mind esemény kezelését és az üzleti logika , egy bizonyos szinten.

Kövér modellek

Gondoljon egy kicsit arra, hogy milyen típusú adatokat tárol a Model az ügyfél oldalon.

Egyrészt olyan adatokkal rendelkezik, mint a felhasználók és a termékek , amelyek képviselik az alkalmazás állapotát . Másrészt tárolnia kell a felhasználói felület állapotát - például a showTab vagy a selectedValue .

A vezérlőhöz hasonlóan a modell megsérti az egységes felelősség elvét, mert nincs külön módja a felhasználói felület és az alkalmazás állapotának kezelésére .

Tehát hol illenek az alkatrészek ebbe a modellbe?

Az összetevők a következők: Nézetek + Eseménykezelés + Felhasználói felület állapota .

Az alábbi ábra azt mutatja, hogy az eredeti MVC modellt hogyan osztotta fel valójában az alkatrészek megszerzéséhez. Ami a sor fölött maradt, pontosan azt próbálja megoldani a Flux : az Alkalmazásállapot és az üzleti logika kezelése .

A React és a komponens-alapú architektúra népszerűségével az egyirányú architektúrák növekedését tapasztaltuk az alkalmazás állapotának kezelésében.

Az egyik oka annak, hogy e kettő olyan jól összeillik, hogy teljesen lefedi a klasszikus MVC megközelítést. Sokkal jobban elkülönítik az aggodalmakat is a front-end architektúrák felépítésével kapcsolatban.

De ez már nem egy React-történet. Ha megnézi az Angular 2-t, akkor pontosan ugyanazt a mintát fogja látni, annak ellenére, hogy különböző lehetőségei vannak az alkalmazás állapotának kezelésére, mint például az ngrx / store.

Nem igazán volt semmi, amit az MVC jobban megtehetett volna az ügyfélnél. Már a kezdetektől kudarcra volt ítélve. Csak időre volt szükségünk, hogy ezt meglássuk. Ezen ötéves folyamat révén a front-end architektúra a maizá vált. És ha belegondolunk, öt év nem olyan hosszú idő a legjobb gyakorlatok megjelenésére.

Az MVC-re azért volt szükség az elején, mert a kezelőfelületünk alkalmazásai egyre nagyobbak és összetettebbek voltak, és nem tudtuk, hogyan kell felépíteni őket. Úgy gondolom, hogy teljesítette a célját, ugyanakkor jó tanulsággal szolgált arról is, hogy az egyik kontextusból (a szerver) átveszi a jó gyakorlatot, és hogyan alkalmazza azt a másikra (az ügyfél).

Tehát mit hoz a jövő?

Nem hiszem, hogy hamarosan visszatérünk a klasszikus MVC architektúrához az elülső alkalmazások számára.

Amint egyre több fejlesztő kezdi megérteni az összetevők és az egyirányú architektúrák előnyeit, a hangsúly az ezen az úton haladó jobb eszközök és könyvtárak építésére fog összpontosítani.

Ez a fajta építészet lesz a legjobb megoldás öt év múlva? Jó esély van arra, hogy ez megtörténjen, de megint semmi sem biztos.

Öt évvel ezelőtt még senki sem tudta megjósolni, hogyan fogunk végül appokat írni. Tehát nem gondolom, hogy biztonságos a jövőbeni fogadások megkötése.

Nagyjából ennyi! Remélem tetszett olvasni ezt. Üdvözlöm az alábbi visszajelzéseket.

Ha tetszett a cikk, kattintson az alábbi zöld szívre, és tudom, hogy erőfeszítéseim nem hiábavalók.