MVC - obecně

Psát co je MVC je v dnešní době patrně zbytečné. Ale pro úplnost uveďme, že se jedná o filozofii návrhu aplikací, kdy je aplikace rozdělena na tři samostatné, ale navzájem propojené části: Model, View, Controller

Model

Část aplikace pracující s daty. Je to čistě abstraktní pojem. Sice se ihned vkrádá na mysl nějaká databáze, tabulky a podobně, ale není tomu vždy tak. Klidně se může jednat o napojení na systém další strany, práci s nějakým API, operace zaměřené spíše na výpočty než na datové struktury, práce se soubory a ano i ona práce s databází. Je to prostě práci s daty a informacemi v nejrůznějších formách - jakýchkoliv. Nemusí se jednat (a v praxi se často nejedná) rovnou o SQL, ORM a podobně.

Důležité je, že tato část aplikace je zaměřená opravdu právě na práci s daty a informacemi. Ne však na interakci s koncovým uživatelem, nebo prezentaci uživatelského rozhraní. 

Dejme tomu, že je model opravdu například nějaká práce s databází. Například s články v redakčínm systému, nebo produkty v e-shopu, či uživatelské účty nějakého komunitního webu. Ano, takový model určitě bude pracovat s databází. Ale již například neřeší jak uživateli zobrazit element uživatelského datagrid a jak zachytávat a vyhodnocovat vstupy. 

Nebo model klidně může být klient nějakého API. Například napojení na dopravce, či účetní systém v rámci e-shopu. I to je model.

View

Část aplikace, která se stará o zobrazení všeho co uživatel vidí. V našem světě online aplikací jde nejčastěji (ale ne výhradně) o generování HTML.

Není pravda, že v této části nemá být žádná logika. Vůbec ne. Například bez cyklů a podmínek se zde neobejdete (je velký masochismus se o to snažit a nemá to smysl a opodstatnění). Nějaká ta logika je pevná a nedílná součást efektivního generování HTML, které se stane uživatelským rozhraním vaší aplikace, informačního systému, e-shopu, zábavného portálu, prostě všeho co vás napadne. 

Ale v této vrstvě určitě nebudete volat a provádět žádné SQL dotazy, stejně v této části nemá  co dělat například použití CURL za účelem práce s nějakým REST API a tak dále. To vše má být v modelu. View "pouze" zobrazuje co se po něm chce na základě dat, která jsou mu předána (zpravidla kontrolerem), nebo pro která si view samo "sáhne" voláním nějaké části modelu (i to je legitimní cesta, pokud je pro danou situaci efektivnější).

Tedy jednoduše: ve view tedy najdete vše potřebné pro efektivní vygenerování výstupu (tedy HTML, XML, či klidně těla mailu). Ne však cokoliv jiného. Práci s daty řeší model. View pouze vytváří výstup na základě dat a informací, které zajistí jiné vrstvy a komponenty.

Controller

To je abstraktní pojem pro logiku, která vše řídí a může mít různé podoby a může se jednat o logiku více či méně složitou. Je to vlastně to co celou aplikaci spojuje do funkčního celku. 

Bude v ní vše ostatní co není v částech Model a View. 

Tedy v rámci kontroleru se nepracuje s daty, nebudete tam rozhodně implementovat žádného klienta pro cokoliv, určitě tam nemá co dělat žádný SQL dotaz.

Ale v rámci kontroleru vás určitě bude zajímat například jaká je URL HTTP požadavku, co je v POST a GET datech, co je v session a podobně.

Dalo by se říct, že kontroler zkoumá v jakém je aplikace stavu, co že vlastně znamená příchozí HTTP požadavek a co se na základě toho bude dít.

Chce uživatel v administraci vytvořit nový článek? Kontroler určí že tomu tak je. Vytvoří novou instanci článku (tedy modelu), provede vše potřebné (například zavolá zachycení formuláře a zjistí, zda uživatel článek již ukládá) a ve finále zavolá view ať se postará o vygenerování potřebného HTML.

Nebo chce uživatel administrace e-shopu vytvořit zásilku u dopravce? Kontroler se opět postará o to, aby situaci vyhodnotil. Požádá model ať si vyhodnotí správnost vstupů, po té požádá model o provedení požadované akce a nakonec předá vše view k zobrazení výsledku (například čísla vytvořené zásilky a zobrazení vygenerovaných expedičních štítků).

Tedy kontroler ani nevolá v tomto případě cizí API (to udělá model), ani negeneruje HTML (to udělá view), ale kontroler je právě ten dirigent, který určí co a jak se stane.

Důležité je, že vše je abstraktní

Není žádný univerzální způsob jak to dělat. Není jedna jediná správná cesta. 

Těch cest je víc. Každá se hodí pro jinou situaci. MVC samo o sobě je druh uvažování. Je to filozofie jak aplikaci vidět a chápat. 

Stejně jako je řada možností jak se v životě dostat z místa A do místa B, tak je řada možností jak realizovat MVC. 

Vše má své výhody a nevýhody, každá možnost se hodí pro určitou situaci. Někde a někdy je třeba komplexita, někde a někdy je třeba jednoduchost. Někde by komplexita překážela, někde by jednoduchost nestačila. A samozřejmě často je správné řešení někde uprostřed.

A právě proto je víc možností jak MVC v rámci Jet používat. Od komplexního systému po jednoduché použití například samotného (třídy Jet\MVC_View) v samostatném skriptu, který je vlastně sám o sobě kontrolerem.

Dogmata jsou na škodu. Důležité je držet se jádra správné myšlenky. A pak zvolit správnou cestu, správné nástroje a správný přístup řešení konkrétního problému.

A právě o tom všem si budeme v následujích kapitolách povídat.

Předchozí kapitola
Lokalizace - Jet\Locale
Další kapitola
Jet MVC