Dvou vrstvá architektura (SOA)
Dvouvrstvá architektura se často používá u API serverů nebo služeb obecně. Občas se také setkáme s pojmem SOA (Service-Oriented Architecture), který kromě softwarové architektury zahrnuje i tu logickou na serveru, typicky klient-server. Dvouvrstvé aplikace se vyznačují tím, že neprezentují data uživateli. Obvykle komunikují s nějakou další aplikací, přijímají od ní požadavky, zpracovávají je a vracejí výsledná surová data.
Nyní se dostáváme ke slíbeným architektonickým návrhovým vzorům. Jsou to:
Indirection - Pomocí prostředníků můžeme zjednodušit vazby mezi objekty a zpřehlednit aplikaci. Pokud do aplikace tedy paradoxně přidáme umělou vrstvu, která bude zprostředkovávat komunikaci mezi 2 skupinami objektů, bude aplikace jednodušší než bez této vrstvy. Někdy o těchto třídách hovoříme jako o servisních, neplést se službami (services).
Controller - Návrhový vzor Controller hovoří o Indirection ještě přesněji a věnuje se aplikacím, které komunikují s uživatelem (a to dělá naprostá většina aplikací). Říká, že veškerá komunikace s uživatelem by měla být soustředěna v oddělených objektech k tomu určeným, tzv. kontrolerech. Ty poté tvoří kontrolní vrstvu aplikace, v některých modifikacích se jí může říkat vrstva prezentační. Naopak třídy obsahující logické operace by měly být od komunikace s uživatelem úplně odstíněny. Takovým třídám s obchodní logikou se poté říká Modely, někdy je podle konkrétní implementace nazýváme entitními třídami, manažery (česky také správci) nebo repositáři.
V dvouvrstvé aplikaci tedy máme 2 skupiny objektů - Kontrolery a Modely.
Třívrstvá architektura
Dostáváme se opět k tématu, které padá na většině pracovaních pohovorů. Otázku "Co je to třívrstvá architektura?" určitě zaslechnete. Jelikož jsme si již vysvětlili architekturu dvouvrstvou, nečeká nás toho příliš nového. Ona třetí vrstva zprostředkovává právě zobrazení výsledku uživateli, což jsme mohli u dvouvrstvé aplikace zanedbat, jelikož posílala jen JSON kód pro stroj.
Vrstvy aplikace budou:
Modely - Logika, typicky SQL dotazy
Views (pohledy) - Šablony, typicky HTML soubory
Controllers – Prostředníci, se kterými komunikuje uživatel a kteří komunikují s modely a pohledy. Právě prostředník umožňuje plné oddělení logiky a zobrazení. O toto se v každé aplikaci snažíme. Jestli si máte něco zapamatovat, tak že architektury většinou oddělují logiku a zobrazení.
Všimněte si, že počáteční písmena vrstev dávají dohromady "MVC", což je označení nejznámější třívrstvé architektury. Další třívrstvé architektury jsou např.:
Model-View-ViewModel (MVVM) - Architektura MVVM přináší další vrstvu. Pro lepší předávání dat mezi šablonou a kontrolerem a opačně používáme minimalistické modely určené pro šablony, tzv. ViewModely. V praxi zde funguje binding, což je poměrně sofistikovaný nástroj. Umožňuje nám navázat ViewModel na šablonu tak, že se jakákoli změna např. hodnoty ve formuláři šablony okamžitě projeví změnou této vlastnosti ve ViewModelu a naopak. Pouhým vytvořením ViewModelu jsme tedy schopní číst a zapisovat data v šabloně.
Model-View-Presenter (MVP) - Architektura MVP je v našich končinách propagována zejména populárním PHP frameworkem Nette. Funguje v podstatě stejně jako MVC, někdy je chápána jako implementace MVC. MVC i MVP může být chápáno a implementováno v různých aplikacích různým způsobem, mezi konkrétními vzory tedy existují malé rozdíly. V MVP je často umožněno volání z view na presenter. Někdy je uváděno, že view přebírá samotné řízení aplikace a vytváří si presenter, kterým si tahá data z logiky. Nutně tak ovšem fungovat nemusí. Pokud jste se v MVC a MVP zamotali, je to bohužel správně, protože jejich specifikace je matoucí. Doporučuji se řídit spíše dříve uvedeným MVC.
Dependency Injection
Inversion of Control
Dostáváme se do situace, kterou popisuje rodina návrhových vzorů Inversion of Control (IoC), česky obrácené řízení. Naše objekty si již neřídí své závislosti samy a nevytahují si je z nějaké statiky, Singletonů nebo lokátorů. Situaci jsme otočili. Naše objekty jsou řízeny nějakým vyšším automatickým mechanismem, který jim jejich závislosti předává a o kterém nevědí. Závislosti si tedy nezískávají, ale jsou jim předávány zvenčí a to automaticky.
Dependency Injection
Dependency Injection, česky asi injekce závislostí, je konkrétní implementace principu IoC. Sestává se tedy z kontejneru, mechanismu, který závislosti předává, a variantě, kterou si o závislosti objekty říkají.
Varianty DI
DI je obvykle implementováno jako Constructor injection, Property injection, Setter injection nebo jejich kombinace.
Comments