2. diel - Monolitická a dvojvrstvová architektúra

V minulej lekcii, Úvod do softvérových architektúr , sme si vysvetlili pojem závislosť v objektovo orientovanom programovaní a na odstrašujúcich príkladoch si ukázali prečo je dobré programovať práve objektovo. Ako je aplikácia z objektov poskladaná nám udáva jej architektúra. O rôznych architektúrach bude pojednávať dnešnej tutoriál.

Programovanie aplikácií si môžeme predstaviť ako stavbu výškové budovy. Pokiaľ ju architekt zle nevrhol, od určitej výšky nám spadne. Musia mať pevnú chrbticovej štruktúru. Neustále dopisovanie kódu po celej aplikácii je denným chlebom programátorov, jej konštrukcia musí byť preto na toľko kvalitný, aby to umožňovala. Pojmom "kvalitný" rozumejme samozrejme tak dobré rozdelenie zodpovednosti objektov, že aj pri stovkách tried budeme vždy vedieť kam siahnuť a celý projekt bude 100% prehľadný. Že sa to zdá nemožné? Ale kdeže. Asi vás neprekvapí, že opäť vytiahneme ďalšie návrhové vzory. Zoberme to však postupne, aby ste mali naozaj detailný prehľad o rôznych architektúrach.

Architektúry

Teraz sa budeme baviť o tzv. Logických architektúrach. Tie si nemýlime s architektúrami fyzickými, ktoré udávajú ako je usporiadaný hardvér, napr. Fyzická architektúra klient-server. Nás v tomto kurze zaujíma usporiadanie kódu v objektoch.

Monolitická architektúra

V tejto architektúre celá aplikácia funguje len ako jedna vrstva. Vrstvou myslíme jednu skupinu objektov. Týmto spôsobom sú často písané menšie aplikácie. Monolitická architektúra je skôr antipattern au väčších aplikácií by sme ju nemali používať. Na niečom sa ale samozrejme začať musí

Rúry a filtre

Skôr pre získavanie si spomeňme ešte architektúru trubiek (pipes), ktorú používajú UNIXové operačné systémy. Funkcionalita je rozdelená do veľkého množstva malých samostatných programov, ktoré sa navzájom prevolávajú a odovzdávajú si dáta. Možno viete v Linuxe pomocou rúrok odovzdávať údaje medzi rôznymi príkazmi. Linux je tiež ukážka toho, že systém môže dobre fungovať, keď ho zostavíte zo stoviek malých programov, kde každý robí dobre svoju malú časť práce.

Dvojvrstvová architektúra

Dvojvrstvová architektúra sa často používa u API serverov alebo služieb všeobecne. Občas sa tiež stretneme s pojmom SOA (Service-Oriented Architecture), ktorý okrem softvérovej architektúry zahŕňa aj tú logickú na serveri, typicky klient-server. Dvojvrstvové aplikácie sa vyznačujú tým, že neprezentujú dáta užívateľovi. Obvykle komunikujú s nejakou ďalšou aplikáciou, prijímajú od nej požiadavky, spracúvajú ich a vracajú výsledná surové dáta.

Teraz sa dostávame sľúbené architektonickým návrhovým vzorom. Sú to:

• InDirection - Pomocou prostredníkov môžeme zjednodušiť väzby medzi objektmi a sprehľadniť aplikáciu. Pokiaľ do aplikácie teda paradoxne pridáme umelú vrstvu, ktorá bude sprostredkovávať komunikáciu medzi 2 skupinami objektov, bude aplikácia jednoduchšie ako bez tejto vrstvy. Niekedy o týchto triedach hovoríme ako o servisných, nepliesť so službami (services).
• Controller - Návrhový vzor controller hovorí o inDirection ešte presnejšie a venuje sa aplikáciám, ktoré komunikujú s užívateľom (a to robí úplná väčšina aplikácií). Hovorí, že všetka komunikácia s užívateľom by mala byť sústredená v oddelených objektoch na to určeným, tzv. Kontroler. Tie potom tvorí kontrolný vrstvu aplikácie, v niektorých modifikáciách sa jej môže hovoriť vrstva prezentačné. Naopak triedy obsahujúce logické operácie by mali byť od komunikácie s užívateľom úplne odtienené. Takým triedam s obchodnou logikou sa potom hovorí Modely, niekedy je podľa konkrétnej implementácie nazývame entitnom triedami, manažérov (slovensky tiež správcovi) alebo úložisku.

V dvojvrstvové aplikácii teda máme 2 skupiny objektov - Kontrolery a Modely.

Ak by sme programovali API server, ktorého by sme sa pýtali na všetky autá v databáze a on nám ich poslal späť v nejakom výmennom formáte (teda nie ako HTML stránku, ale ako dáta pre ďalšie strojové spracovanie, napr. V JSON), vyzeral by zdrojový kód aplikácia takto:

Aplikáciu rozdelíme na 2 zložky - Modely a Kontrolery.

Modely / SpravceAut.php

Správca áut poskytuje logiku pre prácu s autami. To je jeho zodpovednosť. Podobne by napr. Logika pre užívateľa by bola sústredená v triede SpravceUzivatelu a tak ďalej. Závislosť $databaze objektu odovzdáme v konstruktoru.

class SpravceAut
{

    private $databaze;

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

    public function vratAuta()
    {
        return $this->databaze->query("SELECT * FROM auta")->fetchAll(PDO::FETCH_ASSOC);
    }

    // Další metody pro práci s auty, např. přidávání nových aut, vyhledávání aut, mazání aut, editace aut...

}

Modely vôbec nerieši komunikáciu s užívateľom, iba poskytujú logické operácie v rámci svojej zodpovednosti.

Kontrolery / AutaKontroler.php

Kontrolér bude prijímať požiadavky od užívateľa, v našom prípade bude užívateľom síce opäť stroj, ktorý volá náš API server, ale aj ten sa stále počíta ako užívateľ. Na základe prijatých požiadaviek zavolá kontrolér príslušné modely a vráti výsledok ich práce. Jeho zmyslom je len sprostredkovanie komunikácie medzi užívateľom a modelovú / logickú vrstvou aplikácie. Typicky sa kontrolery snažíme písať čo najkratšie a slúži len ako "drôty" medzi užívateľom a logikou.

class AutaKontroler
{

    private $spravceAut;
    private $databaze;

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

    public function vsechna()
    {
        echo(json_encode($this->spravceAut->vratAuta()));
    }

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

}

Kód by mal byť zrozumiteľný. Na kontroleru je zavolaná akcia, ktorá sa má vykonať. Kontrolér získa dáta od modelu, ktorý vôbec nevie o nejakom užívateľovi alebo požiadavky, stará sa len o dáta v rámci svojej zodpovednosti, teda o dáta aut. Kontrolér sa naopak vôbec nestará o dáta, tá si nechá poslať a stará sa o to aké dáta užívateľ chce a ako mu ich pošle. Následne tieto dáta pošle užívateľovi pomocou funkcie json_encode(). V reáli by sme funkciu odovzdali ešte nejaké ďalšie parametre a kontrolér by asi dedil od nejakého predka, ale tým sa teraz nezaťažujme.

Keďže je na ITnetwork zvykom predkladať kompletné riešenie, ukážme si aj ako by systém vnútorne kontrolér podľa požiadavky zavolal. Ide o veľmi zjednodušenú ukážku, ak vás zaujme, nižšie je uvedený odkaz na kompletnú implementáciu a ďalšie informácie.

Index.php

Po prechode na index.php sa prvýkrát registruje autoloader, hľadajúci triedy najprv v priečinku Kontrolery/ a potom v priečinku Modely/. Inteligentnejší implementácia pozri ďalšie PHP kurzy. Ak programujete v inom jazyku ako v PHP, potom sa vaše triedy pravdepodobne načítajú plne automaticky a je jedno v akej sú priečinku / balíčka.

Predstavme si, že sa nachádzame na adrese:

localhost/index.php?kontroler=Auta&akce=vsechna

Z toho potrebujeme poznať, že sa má vytvoriť AutaKontroler a na ňom zavolať metóda vsechna(). Kód by mal mať aspoň intuitívne zrozumiteľný, pridal som do neho tiež komentáre.

<?php

// Jednoduchý autoloader
// Pro jiné programovací jazyky ignorujte
spl_autoload_register(function($nazevTridy) {
    if (file_exists("Kontrolery/$nazevTridy.php"))
        require("Kontrolery/$nazevTridy.php");
    else
        require("Modely/$nazevTridy.php");
});

// Vytvoření instance databázové třídy
$databaze = new PDO('mysql:host=localhost;dbname=testdb;charset=utf8', 'root', '');
// Vytvoření příslušného kontroleru podle URL adresy
$nazevKontroleru = $_GET['kontroler'] . "Kontroler";
$kontroler = new $nazevKontroleru($databaze);
// Zavolání metody podle URL adresy na konroleru
$kontroler->$_GET['akce']();

Pre získanie všetkých áut od servera by sme teda otvorili túto adresu:

localhost/index.php?kontroler=Auta&akce=vsechna

A staré by sa k nám dostal nejaký takýto JSON:

[
    {
        "auta_id":"1",
        "barva":"modra",
        "spz":"123ABC"
    },
    {
        "auta_id":"2",
        "barva":"cervena",
        "spz":"456DEF"
    },
    {
        "auta_id":"3",
        "barva":"cerna",
        "spz":"789GHI"
    }
]

Akcia samozrejme môžu mať ešte parametre a typicky používame tzv. Pretty URL. URL adresa dvojvrstvové aplikácie by teda mohla vyzerať aj napr. Nasledovne:

aplikace.cz/clanky/vyhledej/php

Podľa nej by sa zavolal ClankyKontroler, na ňom metóda vyhledej() s parametrom "php". Časti webové aplikácie, ktorá podľa URL adresy volá príslušné kontrolery, sa hovorí Router. V ukážke vyššie bol veľa minimalistický. Router, ktorý by vedel odovzdávať aj parametre metódam, podporoval pretty URL a vedel napr. Chybové stránky, by bol o chlp dlhší. Môžete sa na neho pozrieť v kurze Jednoduchý redakčný systém v PHP objektovo (MVC). Funkčná aplikácia je k stiahnutiu v prílohe ako u všetkých našich lekcií.

V budúcej lekcii, Trojvrstvová architektúra a ďalšie viacvrstvové architektúry , si vysvetlíme trojvrstvovú architektúru, opäť vrátane funkčného príklade.

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š.