Od špagety k objektům (3) - MVC
Na rozdíl od předchozího článku o OOP bylo o architektuře „MVC“ napsáno nesčetné množství méně či více kvalitních článků, filosofických úvah a komentářů v diskusích. Na internetu lze se nalézt mnoho různých úhlů pohledů na otázku, co „MVC“ je a co už „MVC“ není.
1. Úvod
Rozdělit kód na části lze mnoha různými způsoby a jedna z doporučených a dlouhodobě nejudržitelnějších architektur je právě „MVC“. Její princip provází tento seriál článků od samého začátku. Nejedná se ve své podstatě o nic složitějšího než rozdělení kódu do tří částí. Jedna část se stará o „bussines logiku“ aplikace (Model), druhá část se stará o vzhled (View) a třetí část o vzájemnou interakci mezi předchozími částmi (Controller). Díky tomuto principu se lze v kódu poměrně rychle zorientovat a zároveň tato architektura pomáhá, aby byl kód rozšiřitelný za rámec původního očekávání bez veliké náchylnosti na chyby, které mohou vzniknout úpravou.
Je-li dodržena tato architektura, neměla by být například ohrožena „bussines logika“ aplikace, když se upravuje vzhled a naopak. Jedna z dalších výhod spočívá v možnosti snadného oddělení technologicky náročné „bussines logiky“ na samostatný server a následného napojení více různých pohledů, aniž by se duplikoval kód. Takto rozdělený kód lze navíc snadno spustit na více „loadbalancovaných“ serverech a tak snáze škálovat zátěž. Výhod této architektury je ještě mnoho a proto by měla neoddiskutovatelně patřit do repertoáru znalostí každého profesionálního programátora.
V následujících odstavcích budou popsány jednotlivé části architektury, jejich vzájemná závislost a zákonitosti.
2. Model
Snad ve všech článcích popisujících architekturu „MVC“ je napsáno, že část zvaná „Model“ má obsahovat takzvanou „bussines logiku“ aplikace. Málo kde je však možné se dočíst, co to vlastně znamená a pro méně zkušeného programátora to může být největší zdroj problému v pochopení této architektury, přestože se nejedná o nic komplikovaného. V některých článcích nebo odborných diskusích se lze setkat s milným názorem, že „Model“ se stará jen o komunikaci s datovým úložištěm.
Asi nejvhodnějším vodítkem pro pochopení otázky „Co do Modelu patří a co už ne?“ je právě snaha o snadnou oddělitelnost této části na dedikovaný server. Jakmile se tato část oddělí od zbytku aplikace, měla by zůstat zachována její bezpečnost, funkčnost a celková konzistence s minimem úsilí. Měla by tedy obsahovat všechny kontroly na formální i obsahovou validitu vstupních dat. A v případě, že dostane data v neočekávané podobě, měla by vracet srozumitelnou výjimku. Výjimka by však neměla obsahovat citlivé informace jako názvy SQL tabulek, uživatelská hesla nebo úryvky zdrojového kódu.
Další podstatnou částí „Modelu“ je zajištění autorizace uživatele k jednotlivým úkonům. Právě v této části je potřeba kontrolovat, že uživatel smí vykonávat požadovanou operaci s určitým zdrojem v jeho aktuálním stavu. V případě neoprávněného požadavku pak vrátit příslušnou výjimku.
Většina kódu důležitého pro samotnou funkčnost aplikace, neboli „bussines logiku”, patří do této části. Je proto extrémně důležité dbát zvýšené opatrnosti při jejím vytváření nebo úpravě.
3. View
Jak již název napovídá, část zvaná „View“ se stará o zobrazení výstupu uživateli. Pro větší pohodlí programátora a pro vyšší přehlednost se v této části obvykle využívá šablonovací systém, který se zároveň snaží odstínit kodéra od programovacího jazyku. Díky tomu by nemělo dojít k nechtěnému poškození „bussines logiky“ aplikace.
Část „View“ by měla pracovat výhradně s daty, které jsou jí předány, nebo si zažádat, aby jí byla předána data další, ale neměla by si je sama brát. Ačkoliv se to může v některých případech zdát jako přílišně dogmatické pravidlo, jeho porušení má fatální dopad na celkovou přehlednost a tedy i rozšiřitelnost a udržitelnost kódu.
4. Controller
Tato část se stará o vzájemnou komunikaci. Získává data z „Modelu“ a předává je do „View“ a zároveň zpracovává uživatelské požadavky, jako například odeslání formuláře. Zpracování odeslaného formuláře by však mělo spočívat maximálně v sestavení příslušného objektu naplňeného daty od uživatele a následného předání do „Modelu“ a případné zpracování výjimky vrácené z „Modelu“.
Neměly by se zde však řešit otázky vzhledu. Pokud je například potřeba zobrazit popisku vstupního pole formuláře jako jeho „placeholder“, mělo by to být ošetřeno v části „View“. Při správném dodržení tohoto pravidla bude umožněno kodérovi libovolně měnit vzhled aplikace, aniž by byla nutná spolupráce vývojáře.
5. Komponenty
Architektura „MVC“ popisuje rozdělení celé aplikace na jednotlivé části. Existují však „komponenty“, které se mohou vyskytovat ve více aplikacích zároveň, jejichž vývoj v mnoha případech probíhá odděleně a které by měly být z hlediska dlouhodobé udržitelnosti doopravdy modulární. Mezi nejběžnější komponenty patří například vykreslování tabulek s možností vyhledávání, řazení a stránkování, komponenta pro vykreslování anket nebo komponenta pro vykreslování měnícího se obrázku (Carousel). Aby byly komponenty snadno přenositelné a dlouhodobě udržitelné, měly by být oddělené od aplikace. Jejich vnitřní kód by však měl rovněž dodržovat architekturu „MVC“.
6. Doporučené čtení
Následuje seznam odkazů, které by mohly být užitečné pro pochopení problematiky „MVC“.