Tento příspěvek je písemnou verzí přednášky Garann Means na LXJS a NYCjs. Byl naformátován tak, aby odpovídal vaší obrazovce.
O architekturu JavaScript MVC (Model-View-Controller) není nouze. Nejznámější je Backbone, ale existují i další:Spine, Agility, Knockback atd. A kromě řady MVC frameworků existují varianty MV-whatever. Tato věc je, neoficiálně, docela populární. V době psaní tohoto článku je Backbone 7. nejsledovanějším repo na GitHubu. Vývojáři milují MVC.
Co dělá MVC tak přitažlivým, zejména pro JavaScript, kde se stále primárně používá, na klientovi? Pokud jste v aplikačních architekturách nováčkem, je to určitě velmi dostupné – modelem jsou data, pohled je pohled a řadič je nutí dělat věci. Snadný! Pokud jste začali kódovat na straně serveru, MVC je pravděpodobně již známé. Většina objektově orientovaného programování zahrnuje tento vzor a můžete najít velmi oblíbené rámce MVC pro Javu, .NET, Python, PHP atd. Samotný vzor ve skutečnosti předchází a byl poprvé implementován ve Smalltalku poté, co byl vynalezen Trygve Reenskaug na konci 70. , takže její vztah s OOP tu byl od začátku. Vzhledem k nezpochybnitelné nadřazenosti OOP až do poměrně nedávné doby není překvapivé, že MVC dává mnohým z nás okamžitý smysl.
JavaScript však není přesně OOP. Můžeme s tím udělat OOP, ale ty dva stěží jdou ruku v ruce. Vhodnost MVC se proto liší podle případu použití. Pro zadávání dat, redakční systémy a situace, kdy si můžeme vybrat jasné a zřejmé „modely“, to bývá velmi příjemné. Ale tam, kde je stav aplikace amorfnější a není vždy sledován na stejném místě, v aplikacích se spoustou uživatelských interakcí předtím, než se jakákoli data skutečně změní, a v aplikacích s velmi složitými nebo složitými widgety, je méně jasné, že je to správná volba. . A pokud jsou vaše stránky náročné na JS, ale stále statické, samozřejmě na to zapomeňte. Provádění všech těchto nastavení na stránce, která se znovu načte a vše ztratí, nemá žádnou výhodu.
Problém, na který narazíme, když mluvíme o MVC nebo jakémkoli jiném architektonickém vzoru, je ten, že jako weboví vývojáři tyto věci nebyly vytvořeny pro nás. Nejběžnější vzory můžeme vysledovat zpět do Návrhové vzory (aka kniha Gang of Four), která vyšla v roce 1995. Úsvit našeho oboru, doslova. Tyto vzory byly pro programátory, kteří vytvářejí programy primárně pro své vlastní použití, a rozhodně ne pro programátory, jejichž práce byla snadno odhalena tím, že přešli do nabídky a klepli na View Source. I když se všechny tyto vzory dostaly v nějaké formě do back-endu, tento kánon zcela předchází JavaScript.
MVC však byla jednou z mála starověkých metod, které dávaly okamžitý smysl. Protože má jasné místo pro existenci uživatelského rozhraní, lze jej snadno aplikovat na front-end (i když tato aplikace opět není kánonem). Protože každý vzor, který chceme použít, musí být trochu předělán, aby zapadl do našeho kontextu, je MVC skvělým místem, kde začít. Ale není to jediná možnost, kterou máme.
Zdá se spravedlivé nazývat architektury řízené událostmi druhý nejviditelnější vzorec. Vzory řízené událostmi používáme všude v JS a dokonce i v kombinaci se vzory MV*. Fungují dobře tam, kde potřebujeme hodně zpráv, a méně potřebujeme jasné, klasické „objekty“. Pro objekty, které máme, gettry a settery (a brzy Object.observe() ) lze použít jako vydavatele a předplatitele, oddělující události, jádro aplikace, od věcí, které ovlivňují. Hodnota však spočívá v tom, že tyto oddělené události nemusejí ovlivňovat pouze objekty, ale mohou také ovlivnit DOM nebo interakce se serverem nebo jiné události, a nic z toho nemusí být zabaleno v Model-View-Controller. triáda, pokud to nedává smysl jako jeden.
Nahé předměty pattern má nejbližší vztah k MV* a nebylo by nespravedlivé nazývat jej variantou Prezentace-Abstrakce-Kontrola (vzdálenější příbuzný). To je dobré pro velké masité widgety, které potřebují obsahovat a vykreslovat svá vlastní data a jejichž vizuální reprezentace se mapuje přímo na data, která obsahují. Má podobnost s IDE přetahováním, které jsme používali k vytváření desktopových aplikací, ale bez bitu přetahování. Rebecca Murphey použila podobný vzor při vytváření rámce mobilní aplikace Mulberry, což je perfektní případ použití, protože Naked Objects je skvělý způsob, jak organizovat sestavitelný rámec, jehož implementaci bude lépe vyhovovat jiný vzor.
Třetí vzorec, o kterém si myslím, že si zaslouží podrobnější zkoumání, je Potrubí . To by mělo být známé vývojářům jQuery nebo komukoli, kdo se zabývá velkým množstvím zpětných volání. Potrubí řetězí operace dohromady, aby ovlivnily sdílený stav, což může být vizuální reprezentace nebo jen sada dat (nebo obojí!). Zajímavé pro mě je, že tento vzor můžeme použít synchronně i asynchronně, například použitím globálních funkcí k inicializaci, vykreslení a propojení stránky, pak použít funkce specifické pro instanci k čekání na interakci uživatele, ověření, pokus uložit ji a znovu vykreslit, a přitom měnit stav abstrakce dané stránky. Cokoli se stavem může mít v kódu odpovídající stavový diagram se schopností upravit cestu, kterou se ubírá v závislosti na výsledku každého kroku.
U všech těchto, stejně jako u MVC nebo jakéhokoli jiného vzoru, musíte zvážit, jak a kde chcete, aby byla vaše aplikace pevně nebo volně propojena, a zda potřebujete centralizovaný snímek aplikace, nebo je lépe uložen v komponentách, kterých se týká. Věci jako nahé předměty by byly přehnané, pokud i ty nejsložitější ovládací prvky použijete pouze jednou. Věci jako EDA by byly zbytečné, pokud většinu vašeho kódu tvoří instalační a inicializační kód. A pokud je váš web statický, bylo by vhodnější cokoli, co zavádí nejmenší rámcový kód a přitom vám stále pomáhá vytvořit jasné konvence.
Na konci dne byste měli stále používat Backbone, spíše než nepoužívat nic. Pokud se však ocitnete v aplikaci, která snáze zapadne do nějakého jiného vzoru, neměli byste se bát ji použít. Je smutné, že pro většinu těchto vzorů (a nesčetné množství, které jsem ani nezmínil), budete mít problém najít něco tak robustního a dostupného, jako je Backbone. Takže ještě důležitější je, že pokud sedíte a píšete nový aplikační rámec JS, uděláte nám všem službu tím, že prozkoumáte alternativu k MVC, takže výběr správného nástroje pro tuto práci nebude otázkou výběr z nabídky pěkných kladiv s různými značkami k utažení šroubů. Ať už si vyberete jakoukoli aplikaci a jakoukoli aplikaci, pamatujte, že všechny implementace chátrají a je stejně důležité ponechat příležitost ke zlepšení architektury jako ponechat způsoby, jak zlepšit samotný kód.