MVC architektúra

MVC je veľmi obľúbený architektonický vzor, ktorý sa uchytil najmä na webe, hoci pôvodne vznikol na desktopoch. Je súčasťou populárnych webových frameworkov, akými sú napr. Zend alebo Nette pre PHP, Ruby On Rail pre Ruby alebo MVC pre ASP .NET. Osobne si bez neho (alebo nejakého podobného princípu) nedokážem predstaviť zložitejšie web.

Motivácia

Základnou myšlienkou MVC architektúry je oddelenie logiky od výstupu. Rieši teda problém tzv. "Špagetového kódu", kedy máme v jednom súbore (triede) logické operácie a zároveň renderovanie výstupu. Súbor teda obsahuje databázové dotazy, logiku (napr. PHP operácie) a rôzne pohádzané HTML tagy. Všetko je zamotané do seba ako špagety.

Kód sa samozrejme zle udržuje, nieto rozširuje. Je zle highlightovaný, pretože si s ním IDE nevie rady, HTML nie je správne naformátované, strácame sa v jeho stromovej štruktúre. Naším cieľom je, aby zdrojový kód s logikou vyzeral ako zdrojový kód (napr. PHP) a výstup vyzeral ako HTML stránka s čo najmenšou prímesou ďalšieho kódu.

Komponenty

Celá aplikácia je rozdelená na komponenty 3 typov, hovoríme o modeli, View (pohľadoch) a Controller (kontroléry), od toho MVC. Označenie pohľad sa budem snažiť vyhýbať, pretože mi príde mätúce, že takto preloženej nekorešponduje s označením V. Neexistuje žiadna striktná definícia architektúry a tak sa môžete stretnúť s viacerými výklady. Zameral som sa na ten najrozšírenejší.

Komponenty sú samozrejme triedy, odděděné z abstraktných tried Model, View a Controller. Poďme si jednotlivé komponenty najprv popísať.

Model

Model obsahuje logiku a všetko, čo do nej spadá. Môžu to byť výpočty, databázové dotazy, validácie a podobne. Model vôbec nevie o výstupe. Jeho funkcia spočíva v prijatí parametrov zvonku a vydanie dát von. Zdôrazním, že parametre nemyslím URL adresu ani žiadne iné parametre od užívateľa. Model nevie, odkiaľ dáta v parametroch prišla a ani ako budú výstupné dáta naformátovaná a vypísaná.

Ak používame ORM (Objektovo-Relačná Mapovanie), korešpondujú modely priamo s databázovými tabuľkami. Máme teda model Uzivatel, Komentar alebo Clanok. Instance modelov obsahujú samozrejme atribúty z databázy. Instance modelu Uzivatel má atribút meno. Triede môžeme definovať inštančný metódy, napr. Takú, ktorá vypočíta vek používateľa podľa jeho dátumu narodenia. Metódy týkajúce sa všeobecne užívateľov (teda triedny) často vkladáme do modelu ako statické, napr. Overenie správnej dĺžky a znakov hesla (teda jeho validáciu, pretože heslo overujeme ešte predtým, než je inštancia používateľa vytvorená a zároveň s užívateľom logicky súvisí).

Pre programovanie bez ORM môžeme využiť princípe manažérov. Modely máme napr. UzivatelManazer, KomentarManazer alebo ClanekManazer. Obsahujú metódy k výberu potrebných údajov z databázy, napr. Metódu k výberu prezývky a informácií o používateľovi pri vypísaní jeho profilu. Inou metódou by sme vyberali odtlačok heslá z databázy, aby sme overili prihlásenie, ďalší by nám vrátila sa články používateľa. V správcovi zároveň nájdeme pomocné metódy k práci s užívateľmi, napr. Ono overenie správnej dĺžky a znakov hesla.

Teraz máme predstavu, čo model vykonáva, poďme sa pozrieť na pohľad.

View

Pohľad (View) sa stará o zobrazenie výstupu užívateľovi. Najčastejšie sa jedná o phtml šablónu, obsahujúci HTML stránku a tagy nejakého značkovacieho jazyka, ktorý umožňuje do šablóny vkladať premenné, prípadne vykonávať iterácie (cykly) a podmienky. Pre PHP nemá príliš veľký zmysel používať značkovací jazyk, pretože je samo značkovacom jazykom a umožňuje taký štýl zápisu kódu, aby štruktúra HTML stránky zostala zachovaná. Pohľad uzivatel teda vypíše detaily o používateľovi, pohľad clanek vypíše obsah článku.

Pohľadov máme veľa, napr. Pre funkcionalitu s entitou užívateľa: uzivatel_regis­trace, uzivatel_prih­laseni, uzivatel_profil a podobne. Pohľad uzivatel_profil je ale už spoločný všetkým užívateľom a sú do neho posielané rôzne dáta, vždy podľa toho, koho zrovna zobrazujeme. Tieto dáta sú potom dosadená do HTML elementov šablóny.

Šablóny možno samozrejme vkladať do seba, aby sme sa neopakovali (šablóna s layoutom stránky, šablóna s menu a šablóna článkom).

View nie je len šablóna, ale zobrazovač výstupu. Obsahuje teda minimálne množstvo logiky, ktorá je pre výpis nutná (napr. Kontrola, či si užívateľ vyplnil prezdívku pred jej vypísaním alebo cyklus s komentármi, ktoré sa vypisujú).

View podobne ako Model vôbec nevie, odkiaľ mu dáta prišla, stará sa len o ich zobrazenie užívateľovi.

Controller

Controller je teraz onen chýbajúci prvok, ktorý osvetlí funkčnosť celého vzoru. Ide o akéhosi prostredníka, s ktorým komunikuje užívateľ, model i view. Drží teda celý systém pohromade a komponenty prepája. Jeho funkciu pochopíme z ukážky životného cyklu stránky. Opäť existuje veľa rôznych prístupov, najčastejšie má každá entita jeden controller, máme teda UzivatelController, ClanekController a tak podobne.

Životný cyklus stránky

Životný cyklus začína používateľ, ktorý zadá do prehliadača adresu webu a parametre, ktorými nám oznámi, ktorú podstránku si želá zobraziť. Budeme chcieť zobraziť detail uzivatele s id 15. Urobme si ukážku URL adresy:

http://www.domena.cz/uzivatel/detail/15

Požiadavka ako prvý zachytí tzv. Router. Ten podľa parametrov spozná, ktorý controller voláme. Iste by sme vymysleli mnoho spôsobov, ako meno Controlleru spoznať, najjednoduchšie sa zdá byť uviesť ho ako 1. parameter. Tu je teda zavolaný controller UzivatelContro­ller., Ktorému sú odovzdané parametre detail a 15.

Daný controller podľa parametrov spozná, čo sa po ňom chce, teda že má zobraziť detail užívateľa. Zavolá model, ktorý používateľa vyhľadá v databáze a vráti jeho údaje. Ďalej zavolá ďalšiu metódu modelu, ktorá napr. Vypočíta vek používateľa. Tieto údaje si controller ukladá do premenných. Nakoniec vyrenderuje view (pohľad). Názov pohľadu poznáme podľa akcie, ktorú vykonávame. View sú odovzdané premenné s príslušnými dátami. Controller teda poslúchol užívateľa, obstaral podľa parametrov dotazu dáta od modelu a odovzdal ich view.

View prijme dáta od Controlleru a vloží ich do pripravenej šablóny. Hotová stránka je zobrazená užívateľovi, ktorý často o celej tejto kráse ani netušia

Celú situáciu môžeme znázorniť diagramom:

Získali sme teda oddelenie logiky od výstupu, view sú ako HTML, modely zas v našom skriptovacom jazyku (napr. V PHP). Dosiahli sme prehľadnosti kódu, ktorý je logicky rozčlenený.

MVC architektúra nám uľahčuje aj myslenia pri vývoji projektu. Keď píšem logiku, patrí do modelu, formátovanie a štýlovanie výstupu riešim v šablóne, to čo užívateľ chce z parametrov zisťujem v Controlleru. 3 rôzne problémy na 3 rôznych miestach, oddelené tak, aby do seba nezasahovali a nerobili nám vývoj zložitejšie.