Alternativy k MVC a závěrečné poznámky

Zatímco předchozí dva díly byly zaměřené na architekturu a vzory z rodiny MVC, dnes se budeme věnovat „věcem okolo“. Především to budou alternativní prezentační vzory, podíváme se na úlohu servisní vrstvy a několika poznámkami celou minisérii uzavřeme.

Seriál: MVC a další prezentační vzory (3 díly)

  1. Úvod do architektury MVC 7.5.2009
  2. Prezentační vzory z rodiny MVC 11.5.2009
  3. Alternativy k MVC a závěrečné poznámky 15.5.2009

Alternativy k MVC

K architektuře MVC dnes existují dvě rozšířené alternativy:

  1. Autonomous View
  2. Presentation Model (jinak zvaný Model-View-ViewModel)

Autonomous View

Komponenta chovající se jako Autonomous View v sobě kombinuje uživatelské rozhraní a další logiku, ať už prezentační, aplikační, doménovou, nebo jejich mix. V PHP budiž příkladem skript, který na začátku načte data z MySQL databáze a pak je pomocí různých podmínek a cyklů vypíše do HTML. Ve widgetových systémech zase aplikace s Autonomous View často vznikají při „drag&drop vývoji“.

Samozřejmě, pokud jste sérii o MVC dočetli až sem, nemáte patrně o „vzor“ Autonomous View zájem nebo se od něj naopak snažíte oprostit, ale přesto za zmínku stojí, protože:

  • Je zdaleka nejrozšířenějším modelem vývoje aplikací (podle Programátorovy statistické ročenky)
  • Je výchozím modelem většiny technologií
  • U malých aplikací nebo v jiných specifických případech může být praktičtější než MVC

Věnujte prosím pozornost poslednímu bodu: opravdu nemá cenu snažit se MVC aplikovat vždy a všude, příkladem budiž drobná prezentační logika na klientovi v lehkých AJAX aplikacích. Ale nebojte se, poslední větou, kterou si o Autonomous View přečtete, bude samozřejmě doporučení se mu pokud možno vyvarovat u jakékoliv netriviální aplikace – vyhnete se mnoha jeho problémům, mezi které patří obtížná až nemožná testovatelnost aplikace a téměř žádná dělba zodpovědností vedoucí k horší udržovatelnosti, menší flexibilitě a dalším nepěkným věcem.

Presentation Model (Model-View-ViewModel)

Vzor Presentation Model (PM), někdy nazývaný Model-View-ViewModel (M-V-VM), se obvykle zařazuje mimo MVC/MVP, nicméně i on patří mezi „dobré“ prezentační vzory, které se řídí podobnými principy jako MVC.

Vzor PM se většinou zobrazuje následovně:

Vzor MVVM

Hlavní rozdíl je, že View již nepřistupuje k Modelu přímo, nýbrž přes mezivrstvu, kterou je prezentační model. Tato mezivrstva je dále zajímavá tím, že je jakousi kombinací Modelu a Presenteru.

Asi právě kvůli tomu se PM často popisuje jako vzor odlišný od MVP, nicméně zkusme se na diagram podívat jinak. V reálné aplikaci je úplně klidně možné, že komponenta prezentačního modelu bude realizována ne jedním, ale několika objekty, když např. budeme chtít oddělit chování a stav. Ve chvíli, kdy to uděláme, se diagram velmi přiblíží modelu MVP – chování bude uloženo v Presenteru a stav v Prezentačním Modelu. Protože zde PM implementuje návrhový vzor Adapter, někdy se mu říká Model Adapter, což je koncept z některých MVP implementací známý. Jak tedy vidíte, rozdíl mezi PM a MVP není tak velký, jak se může na první pohled zdát.

Servisní vrstva

Jestliže je MVC architekturou prezentační vrstvy aplikace, možná se ptáte, jak aplikace komunikuje s okolním světem. Musí přece nějak data do modelu načíst, ať už z lokálního disku nebo třeba z databáze. Často přece potřebuje komunikovat s nějakou webovou službou nebo něco na ten způsob. Kde tedy žije tato funkcionalita?

Umístit ji do modelu je možné, ale nešikovné. Například třída, která implementuje zákazníka a současně dokáže jeho data uložit na disk, porušuje Single Responsibility Principle. Odpovědí je tedy oddělení čtvrté části aplikace, které se říká servisní vrstva (Service Layer).

Servisní vrstva má s Modelem společné to, že nijak nesouvisí s konkrétní prezentací a byla by tedy chyba, kdyby se přímo odkazovala na objekty View nebo Controlleru. Pokud do diagramu MVC přidáme servisní vrstvu, bude vypadat následovně:

Servisní vrstva

Tento model, někdy nazývaný „MVCS“, zachycuje kompletní architekturu aplikace, která dělá vše, co se od prezentační vrstvy očekává: umí data načíst, zobrazit, upravit a uložit.

U servisní vrstvy si všimněte pár věcí:

  • Servisní vrstva může, ale nemusí mít přímou referenci na Model. Obvykle se taková reference považuje za přijatelnou, i když obecně platí, že čím volnější vazba mezi komponentami, tím lépe.
  • Objekty servisní vrstvy jsou typicky schované za rozhraním, aby šel Controller testovat a nemusely se přitom používat reálné externí systémy, které mohou být pomalé nebo způsobovat jiné problémy. Pokud mám tedy např. v aplikaci službu EmailService, schovám ji za rozhraní IEmailService (nebo ještě lépe IMessagingService) a controlleru během testování předám FakeEmailService, která text jen uloží do souboru nebo třeba neudělá vůbec nic. Testování tohoto typu dále usnadňují tzv. mock frameworky, které se dají nalézt pro většinu dnešních technologií.

Poslední velká složitost MVC

Pokud jste pochopili základní principy MVC i rozdíly mezi jednotlivými variacemi, gratuluji, pravděpodobně nyní o MVC víte více než 95 % vašich vývojářských kolegů po celém světě (opět převzato z Programátorovy statistické ročenky; zmatení kolem MVC bohužel stále drtivě poráží jeho pochopení).

Přesto je ještě jedna věc, která stojí mezi vámi a dokonale napsanou aplikací: konkrétní technologie. Ono na diagramu se třemi obdélníčky a pár šipkami vypadá vše jednoduše, ale v reálu existuje v aplikaci „MVC triád“ hodně a zařídit, aby mezi sebou komunikovaly bez vytváření pevných závislostí, není vůbec jednoduché. Každá technologie má svůj vlastní „nejlepší způsob“, který bude záviset na věcech jako:

  • jakým způsobem se načítá aplikace a instanciují objekty
  • zda má technologie podporu pro data binding
  • jestli jsou metody pro přístup k datům synchronní nebo asynchronní

a podobně. Co bude krásně fungovat v technologii A, nemusí být v technologii B vůbec použitelné nebo minimálně může existovat daleko lepší způsob. Klišé na tomto místě je, že kdo zná principy, snadno si poradí, ale toho jsem si v praxi bohužel nevšiml. Znovu se vrátím k tomu, co jsem psal už v prvním díle: znalost obecných architektonických principů je užitečná, ale ne vždy dá konkrétní odpovědi na otázky, které potřebuje vývojář znát. Chápat MVC v jeho principu a umět vytvořit kvalitní aplikaci v konkrétní technologii je asi podobné jako chápat, že na kytaru se hraje mačkáním strun a brnkáním, a pak umět zahrát Bacha.

MVC: vzor, architektura nebo princip?

Série o MVC by nebyla kompletní, kdybych se aspoň na chvíli nezastavil u toho, co to vlastně MVC je. Možná vám připadá zvláštní, že tato kapitolka je zařazena na úplný konec místo na začátek, ale pro praxi není zase tolik důležitá a její umístění tomu odpovídá.

S jakými názvy se tedy v souvislosti s MVC setkáte?

  • Když někdo o MVC mluví jako návrhovém vzoru, tak buďto dělá chybu, nebo pojmem „návrh“ myslí něco jiného, než je zvykem (patrně myslí architekturu). Vztah návrhových vzorů a MVC je takový, že MVC je realizováno pomocí návrhových vzorů – např. notifikace změn v modelu může implementovat vzor Observer, Presenter může být pro View Strategií a podobně. Někdy se proto MVC označuje za „vzor (složený ze) vzorů“.
  • Označit MVC za architektonický vzor je nejvhodnější, pokud je řeč o konkrétní variaci. S tímto označením se setkáte velmi často.
  • MVC jako architektura se zase používá, když o MVC mluvíme zhruba na úrovni prvního článku této série, kdy rozdíly mezi MVC a MVP ještě nejsou tolik podstatné.
  • Někdy se pak v souvislosti s MVC slyší pojem princip nebo přístup. Druhý zmíněný je asi lepší, protože slovo „princip“ má ve světě objektového návrhu konkrétní význam – patří sem principy jako Single Responsibility Principle, Open/Closed Principle a podobně.
  • Ve světě konkrétních technologií dále často narazíte na pojem MVC framework, což je označení pro konkrétní implementaci nějaké variace MVC/MVP. Zde si dejte pozor na to, že za MVC se často označují i variace vzoru MVP, což je buď z neznalosti autorů (a pak se frameworku radši vyhněte), nebo z marketingových důvodů („C“ má větší marketingový potenciál než „P“).
  • Poslední pojem, který se v souvislosti s MVC používá, je triáda. Často se tím myslí konkrétní trojice objektů realizujících třídy v modelu MVC. Toto označení je užitečné, když se o triádách mluví v množném čísle (triád je v aplikaci typicky mnoho).

Závěr

Pokud jste se prokousali až sem, gratuluji, nechybělo moc a byli jste lepší než autor. :) Přemýšlím, co by měla být hlavní věc, kterou si z této série odnesete, a je to asi toto:

Problematika MVC a souvisejících prezentačních vzorů je velmi složitá, ale určitě stojí za to se jí věnovat. Znalost architektonických vzorů vede k tvorbě kvalitnějších aplikací a dělá z běžných programátorů skutečné vývojáře.


Zdroje

Zdrojů o problematice MVC/MVP najdete mnoho, jejich kvalita však značně kolísá (například Wikipedia je v této oblasti bohužel plná polopravd, zavádějících tvrzení i vyložených omylů). Zde jsou některé materiály, které přímo nebo nepřímo souvisí s problematikou MVC a považuji je za přínosné:

Věděli jste, že nám můžete zasílat zprávičky? (Jen pro přihlášené.)

Komentáře: 43

Přehled komentářů

ava rocenka
Mirek.Charvat příklad auta
Mirek.Charvat Re: příklad auta
Rene Stein Re: příklad auta
Mirek.Charvat Re: příklad auta
Rene Stein Re: příklad auta
Mirek.Charvat Re: příklad auta
Aleš Roubíček Re: příklad auta
Mirek.Charvat Re: příklad auta
Aleš Roubíček Re: příklad auta
Mirek.Charvat Re: příklad auta
Borek Bernard Re: příklad auta
Mirek.Charvat Re: příklad auta
smilelover RE: Alternativy k MVC a závěrečné poznámky
bh3 RE: Alternativy k MVC a závěrečné poznámky
smilelover RE: Alternativy k MVC a závěrečné poznámky
Borek Bernard RE: Alternativy k MVC a závěrečné poznámky
Rene Stein Můj mozkový controller (některé) názory této série odmítá :)
Borek Bernard Re: Můj mozkový controller (některé) názory této série odmítá :)
Rene Stein Re: Můj mozkový controller (některé) názory této série odmítá :)
Martin Hassman Re: Můj mozkový controller (některé) názory této série odmítá :)
Borek Bernard Re: Můj mozkový controller (některé) názory této série odmítá :)
David Grudl Re: Můj mozkový controller (některé) názory této série odmítá :)
YF houstone - mame problem ....
v6ak Servisní vrstva trochu přesněji
Luk83 Re: Servisní vrstva trochu přesněji
Borek Bernard Re: Servisní vrstva trochu přesněji
v6ak Re: Servisní vrstva trochu přesněji
Aleš Roubíček Re: Servisní vrstva trochu přesněji
Borek Bernard Re: Servisní vrstva trochu přesněji
muz.Payne UI Delegate
Borek Bernard Re: UI Delegate
uf Re: UI Delegate
Borek Bernard RE: Alternativy k MVC a závěrečné poznámky
Mirek.Charvat MVC(P) vs. černá skříňka
Borek Bernard Re: MVC(P) vs. černá skříňka
Mirek.Charvat Re: MVC(P) vs. černá skříňka
Mirek.Charvat Re: MVC(P) vs. černá skříňka
Borek Bernard Re: MVC(P) vs. černá skříňka
uf pekne
uf Re: pekne
Jaroslav Tulach Co po MVC? DCI!
Steve K tomu nepochopení MVC
Zdroj: https://www.zdrojak.cz/?p=3009