Architektura aplikace
Architektura je podle [35] všeobecné označení určující celkovou strukturu a základní konstrukci částí nebo kompletního počítačového systému. V našem speciálním případě architektury aplikace se jedná o způsob rozdělení aplikace, aplikačních dat, procesů i datových toků do logických celků, stanovení struktury těchto komponent, vzájemných vztahů a interakcí mezi nimi, a to na dostatečně obecné úrovni. Je zřejmé, že se k návrhu a volbě architektury musí přistupovat na samém počátku vývoje jakékoliv aplikace, a to s velkou opatrností a rozmyslem. Jakékoliv její pozdější změny jsou totiž velmi komplikované nebo téměř nemožné.
V literatuře zabývající se platformou J2EE se v souvislosti s architekturou aplikace často objevují termíny „Model 1“ a „Model 2“. Původně pocházejí z prvních návrhů specifikace JSP. Z finálních verzí byla sice tato označení odstraněna, přesto se v praxi dodnes běžně používají. Rozdíl mezi těmito dvěma základními přístupy, které se dají snadno zobecnit na jakýkoliv programovací jazyk či platformu, popisuje například [27]:
Model 1 je taková architektura, kdy prohlížeč přistupuje k jednotlivým stránkám přímo, otevírá je z URL, na kterém se skutečně nacházejí. Následující stránka k otevření je pak zpravidla určena pevnými odkazy umístěnými přímo v dokumentu. Řízení aplikace založené na Modelu 1 je decentralizované, protože aktuální stránka již definitivně určuje následující otevíranou stránku. Každá stránka samostatně zpracovává své vstupy zaslané od klienta v parametrech GET nebo POST.
Model 1
Model 2 zavádí tzv. Controller, který se v procesu zpracování dotazu nachází mezi prohlížečem a otevíranými skripty či stránkami. Controller centralizuje logiku vyhodnocování zaslaného dotazu. Na základě klientova požadavku, otevíraného URL, vstupních parametrů i aktuálního stavu aplikace provádí příslušné akce a vybírá další stránku, která se v prohlížeči zobrazí. Jednotný Controller také poskytuje ideální místo pro implementaci takových funkcí, jako je centralizované logování či řízení přístupových práv.
Model 2
Model 1 je vhodný pro statické webové prezentace, nanejvýš pro velmi jednoduché aplikace. Ty jsou omezeny jednoduchými a pevně danými přechody mezi stránkami, decentralizovaným logováním událostí a nízkou kontrolou přístupu, obtížnou rozšiřitelností kdykoliv v budoucnu. Struktura aplikace zpravidla odpovídá adresářové struktuře jednotlivých stránek.
Pro většinu interaktivních aplikací proto [27] doporučuje používat Model 2. Jeho implementaci výrazně usnadňuje přístup nazvaný Model–View–Controller (MVC).
Model–View–Controller
Model–View–Controller [27], [28], [29], [1] je velmi oblíbený způsob návrhu aplikace. Své kořeny má ve Smalltalku, kde se původně používal pro zakomponování tradičního postupu vstup–zpracování–výstup do GUI programů. Neméně vhodný je ale i pro použití ve vícevrstvých webových aplikacích. Rozšířil se zejména v oblasti jazyka Java a souvisejících technologií, jeho obecná definice jej ale umožňuje používat i v jakémkoliv jiném programovacím jazyce.
MVC rozděluje aplikaci na tři logické části: Model, View a Controller. Pro každou z nich přesně definuje, za co je v rámci aplikace odpovědná.
Model
Model je funkčním a datovým základem celé aplikace. Poskytuje prostředky jak pro přístup k datové základně a stavům aplikace, tak pro jejich ukládání a aktualizaci. Hovoří se o něm jako o softwarovém obrazu procesů reálného světa. Měl by být jako celek zapouzdřený a pro View a Controller nabízet přesně definované rozhraní.
Nejčastěji je implementován pomocí objektových tříd, lze jej však (v přístupech odlišných od OOP) realizovat například i běžnými funkcemi. Na své nižší vrstvě je samozřejmě tvořen nějakou formou úložiště dat.
View
View zobrazuje obsah Modelu, zajišťuje grafický či jiný výstup aplikace. Přes Model přistupuje k datům a stavům aplikace a specifikuje, jak mají být prezentovány.
Při změně stavu Modelu aktualizuje zobrazení. Změny v Modelu získává buď push přístupem, kde se jenom zaregistruje u Modelu a ten pak sám posílá View notifikace o změnách. Nebo pull přístupem, kdy se View obrací samo na Model vždy, když potřebuje získat nejaktuálnější data.
V případě stand-alone aplikace zajišťuje View zpravidla průběžné překreslování a aktualizaci obsahu zobrazených oken. U webových aplikací generuje View příslušný HTML kód, který je odeslán prohlížeči jako odpověď na požadavek.
Jestliže slouží zobrazený výstup zároveň jako oblast pro zachytávání událostí od uživatele (například kliknutí myší do vykresleného okna), předává View tyto události Controlleru.
Controller
Controller definuje chování aplikace. Zpracovává veškeré vstupy a události pocházející od uživatele. Na jejich základě volá příslušné procesy Modelu, mění jeho stav apod. Podle událostí přijatých od uživatele i podle výsledků akcí v Modelu pak vybírá Controller vhodné View pro další zobrazení.
U stand-alone aplikací je takovou událostí například kliknutí myší nebo vybrání položky menu. Pro webové aplikace jsou hlavním vstupem HTTP GET nebo POST požadavky odeslané uživatelovým prohlížečem.
Vztahy mezi jednotlivými částmi Model–View–Controller podle [28]
Výhody MVC
Podle [27], [29] a [1] mezi hlavní výhody MVC patří:
Snadné zpřístupnění pro různé druhy klientů. Pro zavedení podpory dalšího klienta je nutné nadefinovat pouze nové View, v případě zcela rozdílných vstupních událostí i speciální Controller. Nicméně Model jako klíčová část aplikace zůstává stále stejný.
Minimalizace duplicitního kódu. Souvisí částečně s předchozím bodem. Například bez oddělení a zapozdření Modelu by se pro každé nové View musela znovu progamovat celá aplikační logika. Ale i v rámci jednoho typu klienta je často jedna akce volána z několika různých míst aplikace.
Rozdělení vývojářských rolí. Jedotlivé části mohou být vyvíjeny samostatně, jen se znalostí předem určených rozhraní mezi nimi. Minimalizuje se dopad modifikací, změny jsou většinou prováděny jen v dané vrstvě.
Znovupoužitelnost kódu. Jako Model lze ve vlastní aplikaci použít standardní knihovny či třídy. Existují také univerzálně pojaté Controllery.
Vysoká komplexnost návrhu a snadná budoucí rozšiřitelost aplikace, efektivní modularita.
V případě centralizovaného Front Controlleru, který zpracovává všechny přicházející požadavky, výhody vyplývající z centralizace, například možnost jednotné kontroly přítupových práv, logování apod.
A v neposlední řadě i čistota designu, způsob přemýšlení programátora nad aplikací, jejím návrhem a architekturou. [1]
V rámci MVC se dále rozlišuje mnoho strategií, jak výslednou aplikaci koncipovat. Liší se například počtem Controllerů a rozdělením úkolů mezi nimi, použitím či nepoužitím šablon v rámci View, jednotným zapouzdřeným voláním datových zdrojů apod. [28]
MVC v praxi
MVC je velice rozšířený a oblíbený přístup k návrhu aplikace. Jak již bylo řečeno, používá se zejména v oblasti jazyka Java. Zde je Model obvykle realizován třídami definovanými v JavaBeans komponentách. View jsou generovány pomocí JavaServer Pages. Controller pak bývá implementován jako skupina servletů, místo mnoha různých servletů může být jeden hlavní servlet jako Front Controller. Nejrozšířenějšími frameworky poskytujícími vlastní Controller jsou Apache Struts a J2EE BluePrints Web Application Framework.
Co se týká jazyka PHP, vzniklo během času mnoho různých frameworků, které poskytují vlastní Controller a množinu rozšiřujících funkcí. Příkladem mohou být Phrame, Mojavi nebo i phpBASE. Všechny uvedené frameworky jsou postaveny na MVC architektuře. Liší se od sebe mírou využití objektově orientovaného programování, rozsahem poskytovaných funkcí apod. V této souvislosti se také často hovoří o projektech PHP Base Library a zejména PEAR. Ty však nelze považovat za provázané frameworky, ale pouze za repository jednotlivých knihoven, jejichž třídy lze v aplikaci případně použít ve funkci Modelu.
Navigace
Související odkazy
Zápatí
Obsah stránek vyjadřuje osobní názory, postoje a zkušenosti autora. Copyright © 2004–2010 Jan Tichý.