Kapitola 1. Vrstevnatá architektura. Vzory softwarové architektury. Mark Richards
Komponenty v rámci vrstveného architektonického modelu jsou organizovány do horizontálních vrstev, z nichž každá plní v aplikaci specifickou roli (například prezentační logiku nebo obchodní logiku).
Ačkoli model vrstvené architektury nedefinuje počet a typy vrstev, které musí v modelu existovat, většina vrstevnatých architektur se skládá ze čtyř standardních vrstev: prezentační vrstvy, vrstvy obchodní logiky, vrstvy pro přístup k datům a vrstvy abstrakce databáze.
V některých případech jsou vrstva obchodní logiky a vrstva přístupu k datům sloučeny do jedné vrstvy obchodní logiky, zejména pokud je logika přístupu k datům (například SQL nebo HSQL) zabudována do komponent obchodní logiky. Malé aplikace tak mohou mít pouze tři vrstvy, zatímco větší a složitější obchodní aplikace mohou obsahovat pět nebo více vrstev.
Každá vrstva vrstveného architektonického vzoru má v aplikaci specifickou roli a odpovědnost. Například prezentační vrstva je zodpovědná za zpracování uživatelského rozhraní a logiku interakce s prohlížečem, zatímco obchodní vrstva bude zodpovědná za provádění specifických obchodních pravidel spojených s požadavkem. Každá vrstva v architektuře tvoří abstrakci kolem práce, kterou je třeba provést k uspokojení konkrétního obchodního požadavku.
Například prezentační vrstva nemusí vědět ani se starat o to, jak získat zákaznická data; stačí, když tyto informace zobrazí na obrazovce v určitém formátu. Stejně tak se vrstva obchodní logiky nemusí starat o to, jak formátovat zákaznická data pro zobrazení na obrazovce, nebo dokonce odkud zákaznická data pocházejí. Potřebuje pouze získat data z vrstvy pro přístup k datům, aplikovat obchodní logiku na základě těchto dat (například výpočet hodnot nebo agregaci dat) a předat tyto informace prezentační vrstvě.
Jednou ze silných stránek vrstvené architektury je oddělení odpovědností mezi komponentami. Komponenty v dané vrstvě se zabývají pouze logikou specifickou pro danou vrstvu. Například komponenty v prezentační vrstvě se zabývají pouze prezentační logikou, zatímco komponenty v obchodní vrstvě se zabývají pouze obchodní logikou. Tato klasifikace komponent zjednodušuje konstrukci efektivních modelů rolí a odpovědností v architektuře a zjednodušuje vývoj, testování, dohled a údržbu aplikací používajících tento architektonický vzor díky dobře definovaným rozhraním komponent a omezeným hranicím komponent.
Všimněte si na obrázku 1-2, že každá vrstva v architektuře je označena jako uzavřenoToto je velmi důležitý koncept vrstvené architektury. Uzavřená vrstva znamená, že když se požadavek přesouvá z vrstvy do vrstvy, musí projít vrstvou přímo pod ní, aby se dostal k další. Například požadavek přicházející z prezentační vrstvy musí nejprve projít vrstvou obchodní logiky, poté vrstvou přístupu k datům, než se konečně dostane k databázové vrstvě.
Obrázek 1-2: Uzavřené úrovně a požadavek na přístup
Proč tedy nedat prezentační vrstvě přímý přístup k vrstvě pro přístup k datům nebo k databázi? Koneckonců, přímý přístup k databázi z prezentační vrstvy je mnohem rychlejší než procházení spousty zbytečných vrstev jen proto, abyste získali nebo uložili informace z databáze. Odpověď na tuto otázku spočívá v klíčovém konceptu vzoru známém jako vrstvy izolace.
Koncept izolovaných vrstev znamená, že změny provedené v jedné vrstvě architektury obvykle neovlivňují komponenty v ostatních vrstvách. Změny jsou izolovány v komponentách v dané vrstvě a případně i v další související vrstvě (například vrstvě pro přístup k datům obsahující SQL). Pokud dáte prezentační vrstvě přímý přístup k vrstvě pro přístup k datům, pak změny provedené v SQL v rámci vrstvy pro přístup k datům ovlivní jak vrstvu obchodní logiky, tak prezentační vrstvu, čímž vznikne velmi úzce propojená aplikace s mnoha vzájemnými závislostmi mezi komponentami. Změna tohoto typu architektury je velmi obtížná a nákladná.
Koncept izolovaných vrstev také znamená, že každá vrstva je nezávislá na ostatních. Má tedy jen málo nebo žádné znalosti o vnitřním fungování ostatních vrstev architektury. Abychom pochopili sílu a důležitost tohoto konceptu, zvažte refaktoringový pokus o převod prezentační struktury z JSP (Java Server Pages) na JSF (Java Server Faces). Za předpokladu, že smlouvy (např. model) použité mezi prezentační vrstvou a vrstvou obchodní logiky zůstanou nezměněny, vrstva obchodní logiky nebude refaktoringem ovlivněna a zůstane zcela nezávislá na typu UI frameworku používaného prezentační vrstvou.
I když uzavřené vrstvy podporují izolaci a pomáhají izolovat změny v architektuře, existují případy, kdy má smysl některé vrstvy zveřejnit. Předpokládejme například, že chcete přidat vrstvu sdílených služeb do architektury, která obsahuje společné komponenty služeb, ke kterým přistupují komponenty ve vrstvě obchodní logiky (například třídy dat a řetězců služeb nebo třídy auditu a protokolování). Vytvoření nové vrstvy „Služby“ je v tomto případě dobrý nápad, protože architektonicky omezuje přístup ke sdíleným službám pouze na vrstvu obchodní logiky (a nikoli na prezentační vrstvu). Bez samostatné vrstvy neexistuje nic, co by architektonicky omezovalo přístup prezentační vrstvy k těmto sdíleným službám, což by toto omezení přístupu ztěžovalo správu.
Ve výše uvedeném příkladu by nová vrstva „služeb“ pravděpodobně byla umístěna pod vrstvou obchodní logiky, aby to signalizovalo, že komponenty této vrstvy služeb nejsou přístupné z prezentační vrstvy. To však vytváří problém, protože požadavek z vrstvy obchodní logiky nyní musí projít vrstvou služeb, aby se dostal k vrstvě přístupu k datům, což je zcela zbytečné. Toto je odvěký problém vrstvené architektury, který se řeší vytvářením exponovaných vrstev v architektuře.
Jak je znázorněno na obrázku 1-3, vrstva služeb je v tomto případě otevřená, což znamená, že požadavky mohou tuto otevřenou vrstvu obejít a přejít přímo na vrstvu níže. V tomto příkladu je vrstva služeb zobrazena jako otevřená, takže vrstva obchodní logiky ji může obejít a přejít přímo na vrstvu pro přístup k datům.
Obrázek 1-3. Otevřené vrstvy a postup provádění dotazů
Použití konceptu otevřených a uzavřených vrstev pomáhá definovat vztah mezi architektonickými vrstvami a toky požadavků a poskytuje návrhářům a vývojářům informace, které potřebují k pochopení různých omezení přístupu k vrstvám v architektuře. Nedostatečná dokumentace nebo správná komunikace o tom, které vrstvy v architektuře jsou otevřené a uzavřené (a proč), obvykle vede k úzce propojeným a křehkým architekturám, které je velmi obtížné testovat, udržovat a nasazovat.
Příklad použití šablony
Pro ilustraci fungování vrstvené architektury si představte požadavek uživatele na načtení informací o konkrétním zákazníkovi, jak je znázorněno na obrázku 1-4. Černé šipky ukazují požadavek směřující do databáze za účelem načtení dat zákazníka. Červené šipky ukazují odpověď, která se vrací zpět na obrazovku uživatele k zobrazení dat. V tomto příkladu informace o zákazníkovi obsahují informace o zákazníkovi a jeho objednávkách.
Obrázek 1-4. Příklad vrstvené architektury
Obrazovka klienta (Zákaznická obrazovka) je zodpovědný za přijetí požadavku a zobrazení informací o klientovi. Obrazovka klienta neví, kde se data nacházejí, jak jsou načítána ani kolik databázových tabulek je třeba dotazovat, aby se data získala.
Když klientská obrazovka obdrží požadavek na načtení informací o klientovi pro konkrétní osobu, předá tento požadavek modulu pro delegování klientů (Zástupce zákazníka).
Tento modul je zodpovědný za to, které moduly ve vrstvě obchodní logiky dokáží tento požadavek zpracovat, a také za to, jak se k tomuto modulu dostat a jaká data potřebuje (smlouvu).
modul“Objekt zákazníka» ve vrstvě obchodní logiky je zodpovědný za shromažďování všech informací potřebných pro obchodní požadavek (v tomto případě k získání informací o klientovi).
Tento modul odkazuje na modul „Zákaznický dao„(DAO: objekt pro přístup k datům, objekt pro přístup k datům) k vrstvě pro přístup k datům pro získání zákaznických dat a také k modulu“Objednat dao» pro informace o objednávce.
Tyto moduly následně spouštějí SQL dotazy pro načtení relevantních dat a jejich předání zpět do objektového modulu Customer ve vrstvě obchodní logiky. Jakmile objektový modul Customer data obdrží, agreguje je a předá informace modulu Customer Delegate, který je následně předává modulu Customer Screen. Výsledkem jsou data zobrazená na obrazovce uživatele.