Třívrstvá architektura v kostce II. — design střední vrstvy

Osobní poznámka na začátek: k sepsání tohoto článku jsem se hotovil nejméně rok a půl. Na určité věci musí mít člověk náladu a chuť, ale že tento článek resp. jeho základ vznikne na koleni v autobuse z Prahy do Písku při pátečním podvečeru, tak to jsem opravdu nečekal.

Pokud jsme se bavili o třívrstvé architektuře, bylo zdůrazněno, že největší pozornosti by se mělo věnovati designu střední vrstvy (někdy též nazývané aplikační vrstvou či middle tier). Střední vrstva by aplikace by měla být horizontálně strukturovaná do takzvaných subvrstev (pro další části článku používám pro subvrstvu označení vrstva).

Vazby mezi jednotlivými vrstvami by měly být na úrovni rozhraní a v budoucnu umožňovat snadnou změnu implementace. Izolace vrstev přináší další výhodou v podobě snazšího testování v rámci jednotkových testů. V podstatě jsou definovány tři základní vrstvy.

UI/RPC vrstva
Service vrstva
DAO vrstva

Konceptuální schéma architektury střední vrstvy

Plná velikost obrázku (29 KB)

UI vrstva/RPC bridge

UI vrstva/RPC bridge je prostředník mezi komunikačním protokolem klienta a vnitřní strukturou aplikace. Přímo používá pouze Service vrstvu a to tak, že převede požadavek na vnitřní volání a získaná data vrátí zpět v patřičném formátu.

UI vrstva

Část určená pro spolupráci s webovým prohlížečem, výsledek požadavku je vrácen jako HTML data. UI vrstva by měla být implementována podle návrhového vzoru MVC (Model-View-Controller).

RPC bridge

Tato vrstva slouží jako prostředník, pro danou implementaci RCP. V podstatě exportuje Service vrstvu pro vzdálené volání například jako webovou službu.

Service vrstva

Service vrstva též nazývaná jako Business vrstva slouží pro implementaci logiky aplikace. V podstatě jsou v ní realizovány jednotlivé aplikační algoritmy. Tato vrstva přímo spolupracuje pouze s nejbližší nižší vrstvou, která poskytuje data.

Data access vrstva

Data access vrstva slouží pouze a jedině k práci s úložištěm dat. Úložiště dat může být například relační databáze, souborový systém a nebo jiný systém. V této vrstvě je tedy pouze naimplementovaná logika pro zacházení s daným datovým zdrojem. V případě relační databáze je tato vrstva implementována pomocí klasického JDBC API a nebo pomocí objektově-relačního API.

Domain model

Lepidlo jednotlivých vrstev je představeno v podobě domain modelu aplikace. Domain model je objektové vyjádření vztahů mezi jednotlivými entitami systému. Na příkladu elektronického obchodu, máme entity jako objednávka, objednávající, zboží, faktura. Tyto entity převedené na objekty představují domain model aplikace.

Všechny vrstvy pracují s domain modelem podle svého určení. DAO vrstva může výsledky dotazu do relační databáze převádět na graf objektů. Service vrstva získaný graf objektů zpracuje například zkontroluje jestli je dané zboží na skladě a odešle email. UI vrstva zobrazí uživateli výsledek požadované akce.

Společné aspekty

Transakce, autorizace, logování to všechno jsou aspekty, které se prolínají přes jednotlivé vrstvy. Není proto vhodné je zakódovat hluboko do střev aplikace. Daleko výhodnější je použití ne invazivních metod jako jsou metadata (anotace, popisné XML) a AOP (Aspektově Orientované Programování).

Transakce

Transakce je možné zadefinovat na úrovní Service vrstvy a nebo DAO vrstvy a propagovat je směrem dolu. Transakce muže být zadefinována programově voláním transakčního API přímo z vlastního kódu a nebo pomocí metadat, tomuto způsobu se říká deklarativní. Deklarativní definice transakce postačuje pro 95% případů, na ten zbytek je možné použít přímo transakční API.

Autorizace

Autorizace na úrovni volání jednotlivých metod je dalším klasickým příkladem aspektu, který lze deklarativně nadefinovat na úrovni metadat, bez nutnosti modifikace vlastního kódu aplikace. Na druhou stranu autorizace na úrovni volání metod nemusí být vždy nutná.

Logování

Logování na úrovni jednotlivých vrstev aplikace je obdobný příklad jako autorizace co do nutnosti. V případě logování na úrovní vrstev (audit logování) lze úspěšně použít AOP. Samozřejmě pro logování na úrovni trasování programu se nikdy nevyhnete zanesení logovacího API do vlastního kódu aplikace.

Volba technologie

Při volbě technologie pro realizaci střední vrstvy by mělo platit základní pravidlo a to, že použitá technologie nesmí v žádném případě diktovat architekturu aplikace. Nechci zde protěžovat nějakou technologii, protože tenhle článek není o konkrétních technologiích, ale o architektuře. Ostatně použitá technologie je jenom implementační detail schovaný za business rozhraním…

11.11.2004 — Dagblog Třívrstvá architektura v kostce I.