3. diel - Trojvrstvová architektúra a ďalšie viacvrstvové architektúry

V minulej lekcii, Monolitická a dvojvrstvová architektúra , sme si vysvetlili, čo je to logická architektúra a prečo je dôležité, aby naše aplikácie nejakú architektúru mali. Spomenuli sme si monolitickou architektúru a tú potom rozdelili na dve vrstvy, čím vznikla architektúra dvojvrstvová. Pre zažitie princípe kontrolerov a modelov sme vytvorili plne funkčný dvojvrstvovú aplikáciu v PHP, ktorá poskytuje API pre získavanie dát o automobiloch.

Trojvrstvová architektúra

Dostávame sa opäť k téme, ktoré padá na väčšine pracovanie pohovorov. Otázku "Čo je to trojvrstvová architektúra?" určite začujete. Keďže sme si už vysvetlili architektúru dvojvrstvovú, nečaká nás toho príliš nové. Ona tretia vrstva sprostredkováva práve zobrazenie výsledku užívateľovi, čo sme mohli u dvojvrstvové aplikácie zanedbať, pretože posielala len JSON kód pre stroj.

Vrstvy aplikácie budú:

• Modely - Logika, typicky SQL dotazy
• Views (pohľady) - Šablóny, typicky HTML súbory
• Controllers - Sprostredkovatelia, s ktorými komunikuje užívateľ a ktorí komunikujú s modelmi a pohľady. Práve prostredník umožňuje plné oddelenie logiky a zobrazenie. O toto sa v každej aplikácii snažíme. Ak si máte niečo zapamätať, tak že architektúry väčšinou oddeľujú logiku a zobrazenia.

Všimnite si, že počiatočné písmená vrstiev dávajú dohromady "MVC", čo je označenie najznámejšia trojvrstvovej architektúry. Ďalšie trojvrstvovej architektúry sú napr .:

• Model-View-ViewModel (MVVM) - Architektúra MVVM prináša ďalšiu vrstvu. Pre lepšie odovzdávanie dát medzi šablónou a kontrolerom a opačne používame minimalistické modely určené pre šablóny, tzv. ViewModel. V praxi tu funguje binding, čo je pomerne sofistikovaný nástroj. Umožňuje nám nadviazať ViewModel na šablónu tak, že sa akákoľvek zmena napr. Hodnoty vo formulári šablóny okamžite prejaví zmenou tejto vlastnosti vo ViewModel a naopak. Jednoduchým vytvorením ViewModel sme teda schopní čítať a zapisovať dáta v šablóne.
• Model-View-Presenter (MVP) - Architektúra MVP je v našich končinách propagovaná najmä populárnym PHP frameworkom Nette. Funguje v podstate rovnako ako MVC, niekedy je chápaná ako implementácia MVC. MVC aj MVP môže byť chápané a implementované v rôznych aplikáciách rôznym spôsobom, medzi konkrétnymi vzormi teda existujú malé rozdiely. V MVP je často umožnené volanie z view na presenter. Niekedy je uvádzané, že view preberá samotné riadenie aplikácie a vytvára si presenter, ktorým si ťahá dáta z logiky. Nutne tak však fungovať nemusia. Ak ste sa v MVC a MVP zamotali, je to bohužiaľ správne, pretože ich špecifikácia je mätúce. Odporúčam sa riadiť skôr skôr uvedeným MVC.

Poďme si pre istotu ešte raz popísať, čo budú jednotlivé vrstvy robiť:

Životný cyklus požiadavky na trojvrstvovú MVC aplikácii bude nasledujúce:

1. Router podľa URL zavolá kontrolér
2. Kontrolér sa opýta na dáta modeli
3. Dáta si kontrolér uloží
4. Dáta odovzdá View
5. View vyplní dátami HTML šablónu
6. Zostavená stránka je odoslaná užívateľovi

Prípadne sa môžete pozrieť na detailné článok MVC architektúra.

Poďme z našej dvojvrstvovej aplikácie urobiť aplikáciu trojvrstvovú, teda aby zobrazovala výsledky ako HTML stránky.

Modely / SpravceAut.php

Model bude stále rovnaký.

Kontrolery / AutaKontroler.php

Kontrolér miesto vypísanie dát pomocou echo() a json_encode() pripraví premenné pre šablónu a následne šablónu načíta:

class AutaKontroler
{

    private $spravceAut;
    private $databaze;

    public function __construct($databaze)
    {
        $this->databaze = $databaze;
        $this->spravceAut = new SpravceAut($this->databaze);
    }

    public function vsechna()
    {
        $auta = $this->spravceAut->vratAuta(); // Proměnná pro šablonu
        require('Sablony/auta.phtml'); // Načtení šablony
    }

    // Případné další akce jako jedno($id), odstran($id), ...

}

Sablóny / auta.phtml

Onou novou vrstvou aplikácie je teraz view, teda šablóna. To je HTML kód s čo najnižšou prímesou syntaxe nejakého ďalšieho jazyka, pomocou ktorej sa v šablóne iteruje nad dátami a vkladajú sa do nej premennej. My tu pomocou cyklu proiterujeme premennú $data, ktorú sme získali od kontroleru.

<html lang="cs">
    <head>
        <title>Výpis automobilů</title>
        <meta charset="UTF-8">
    </head>
    <body>

        <table border="1">
            <?php foreach ($auta as $auto) : ?>
                <tr>
                    <td><?= htmlspecialchars($auto['spz']) ?></td>
                    <td><?= htmlspecialchars($auto['barva']) ?></td>
                </tr>
            <?php endforeach ?>
        </table>

    </body>
</html>

Hotová šablóna je následne odoslaná užívateľovi. Vyzerajú takto:

S našou ukážkovou aplikáciou sme trochu pohli. Závislosti sme síce odovzdávali zatiaľ ručne, ale aplikácia je teraz rozdelená na:

• Models - Súbory s čistou aplikačnou / obchodné logikou
• Views - Súbory s relatívne čistou šablónou
• Controllers - Relatívne malé sprostredkovateľmi

Môžete si pokrok porovnať s príkladom, kedy bolo všetko v jednom súbore. Je nutné si však predstaviť, že je každá časť dostatočne komplexné, aby bola viditeľná pridaná hodnota oddelenie týchto častí.

Formulárové aplikácie

A čo formulárové aplikácie? Ak aplikácia nie je webová, ale napr. Desktopová, samozrejme tu opäť zafunguje nejaká automatika nad naším kódom, ktorá zavolá tú danú triedu pre ten daný formulár alebo čokoľvek prostredníctvom čoho užívateľ komunikuje. Vzor kontrolér možno naozaj aplikovať úplne všade a mali by sme tak aj urobiť. Určite ste nejakú formulárové aplikáciu niekedy vytvorili, trieda obsahujúce obsluhu onoho formulára bola kontrolér. Napr. v JavaFX sa trieda aj tak naozaj volá, ale napr. v C# sa nazvali CodeBehind, aj keď sa jedná o kontrolery. Priznajte sa, písali ste logiku priamo do tohto súboru obsluhujúceho formulár? Tak teraz už viete, že by ste tu mali maximálne vytvoriť modely a volať logiku zapuzdrenou v týchto modeloch. Rovnako ako sme si to teraz ukázali na webovej aplikácii s autami.

V budúcej lekcii, Zlé spôsoby odovzdávania závislostí - Statika , sa budeme konečne venovať odovzdávanie závislostí. Ukážeme si, čo sa stane, keď závislosti nebudeme odovzdávať vôbec, ale budeme tvoriť stále nové inštancie služieb. Ďalej si ukážeme antipatterny ako odovzdávanie statickými atribúty, návrhovým vzorom Singleton, vzorom ServiceLocator a rôznymi variáciami.

Ak vám MVC robí problémy alebo vás naopak zaujalo, pozrite sa na náš samostatný kurz k tejto architektúre v PHP - Jednoduchý redakčný systém v PHP objektovo (MVC) alebo na všeobecný článok popisujúci túto architektúru - MVC architektúra.

Mal si s čímkoľvek problém? Stiahni si vzorovú aplikáciu nižšie a porovnaj ju so svojím projektom, chybu tak ľahko nájdeš.