Čekal jsem, až bude série článků ukončena, abych poznal, jak Borek pojímá MVC.

Musím říci, že ale ani po přečtení celé série nejsem moudřejší.
Než se začít dohadovat nad "vysokoúrovňovými" věcmi, vždy se rád nejdříve shodnu na tzv. myšlenkových a implementačních trivialitách, protože na nich se pozná, jak člověk přemýšlí. Epochálním a letmo načrtnutým megalomanským "architektonickým" stavbám se těžko oponuje, protože žijí ve světě svých nezpochybnitelných a vždy při nárazu kritických připomínek rychle upravitelných předpokladů.:)

Citace:
"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."

Zde se míchá několik věcí dohromady:

Nemělo by spíš zaznít.
Autonomous View v sobě kombinuje veškerou logiku, která se týká správy a udržování stavu uživatelského rozhraní. Tedy autonomous view přebírá role, které jsou při separaci různých odpovědností souvisejících s řízením uživatelského rozhraní rolemi samostatných tříd controller-presenter. To je téma tohoto článku.

Další (odstrašující, fakt jsm se lekl :) ) příklad už nesouvisí s probíraným vzorem (vzory). Můžete mít autonomní pohled, který jako podkladový model používá běžný business model, nebo anemický business model, anebo jen sadu transakčních skriptů, či rovnou přistupuje do SQL databáze. I M v MVC model může být označením pro transakční skript nebo jen sadu metod, které vracejí po předání SQL "resultset-recordset".

Příklad s PHP tedy představuje extrém a atypické použití autonomního view.

Přijde mi to ale jako hezký návod pro vývojáře, kteří píšou špagetový kód bez jakéhokoli rozvrstvení aplikace, aby mohli na pohovorech na otázku:"Jak píšete typicky webové aplikace", odpovědět jinak než "seberu data z databáte a pak už je pěkně v cyklu vypíšu, jaké komplikace woe". Nyní mohou rafinovaně říci : "Pro své jednoduché aplikace jsem namísto typického bastlení použil zjednodušenou a velmi efektivní variantu VZORU autonomní pohled. Mou domněnku potvrdil autoritativní zdroj, samotný velký Zdroják!" :)

Citace:
"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)."

Tady už je to na mě příliš a univerzální zaklínadlo Single responsibility principle, kterým se tlučou po hlavě všichni předpokládaní heretici, k mé duševní pohodě nepřispívá.

Tedy servisní vrstva: Co přesně označuje?
Zkusme vyjít ze dvou příkladů v článku.
1) Zákazník a jeho uložení dat na disk.

Pokud vyjdeme z klasického vícevrstvého modelu, tak naším zájmem by mělo být, aby za ukládání zákazníka odpovídala perzistentní vrstva, kterou používají další (vyšší-např. business vrstva) vrstvy aplikace. Ano – ze zákazníka (business vrstva-tedy Model) určitě vydělíme odpovědnost za ukládání svých dat, vytvoříme nějaké společné rozhraní, které realizuje objekt v db vrstvě a v okamžiku, kdy má dojít k uložení dat, objekt zákazník po zavolání jeho metody UložSe může zavolat metodu z databázové vrsty Ulož, které předá svoje data. Samozřejmě nechceme-li mít delegující metodu UložSe přímo v objektu zákazník, nic nám nebrání vytvořit v Modelu další (podpůrné) objekty typu Data Mapper, které interně volají metody databázové vrstvy a objekt Objednávka nemá ve svém veřejném rozhraní žádné Kainovo znamení (metodu UlozSe)signalizující – jsem SW objekt a proto podporuji perzistenci, což by někteří dogmatici mohli považovat za porušení 11. přikázání (pardon, vlastně jen ončas užitečného SRP doporučení).
Důležité je, že Controller, tak jak je naznačeno v článku, NEPOUŽÍVÁ žádné servisní objekty pro uložení, ale pracuje s business modelem a poté, co potřebuje uložit data, zavolá příslušnou metodu business objektu, data mapperu apod, a poté je volání přeneseno na perzistenční vrstvu.

Servisní vrstva, o které je řeč v článku, připomíná spíš právě vrstvu složenou z repozitáře objektů a data mapperů, ale je popsána na zavádějících příkladech a podpírána (alespoň) nevyslovenými předpoklady – možná.:)

Citace:
"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í."

Základní otázka zní – k čemu controller, jehož odpovědností je ve všech možných inkarnacích zprostředkovávat komunikaci mezi View a modelem, jak nám bylo v článku několikrát naznačováno, najednou potřebuje emailové služby? Je to chlapík ten controller, všichni ostatní participanti jsou chudáčci, kterým musí odlehčovat v jejich odpovědnostech, ale tady si na svá tajemná, ale beze všech pochybností mohutná a altruistická záda naložil sadu dalších odpovědností.

Není to tak, že pravidla, kdy mají být odeslány emaily(emailové notifikace), je součást business pravidel? A je tedy odpovědností samotných objektů "modelu" (např. v objektu, který implementuje stavový automat pro objednávku), že poté, co uživatel dá příkaz ve View (kliknutí na tlačítko, submit) ke stornování objednávky, controller tento příkaz přenese do stavového automatu, ve stavovém automatu dojde k přechodu do stavu Storno a současně se spustí akce, která přes speciální servisní vrstvu pro odesílání emailu (IEmailService) odešle notifikaci.
Ano – controller může chtít odesílat také emaily (např. informaci o nějaké chybě/logovací informace) a pak může využít také služby objektu skrytého za rozhraním IMessagingService. Ale jak to souvisí s tímto vzorem a s vazbou controlleru na model a servisní vrstvy na business model?

Co by ale mělo platit:
Implementace rozhraní IMessagingService patří do nízkoúrovňových vrstev aplikace, rozhraní IMessagingService nemá žádné předpoklady, tedy nevidí v žádném případě jejich rozhraní, ani o objektech z business vrstvy, natož z controlleru. Je to služba s jasně vymezenou jednou odpovědností, voila, ani jsme se nemuseli opakovat magicou říkanku SRP.

IMessagingService
{
bool Config(Map configValues)
void SendMessage(string message, string subject, int priority …)
}

Nejlepší rozhodnutí jsou ne ta, která vás při návrhu baví, ale která vyplynou z požadavků. :)

Dovedu si představit služby využívané přímo controllerem, které mají přímo vazby na třídy v "Modelu". Například jde o fasády, které realizují uživatelské scénáře a ještě více izolují controller od modelu. Ale to je téma spíš na celý článek.

Už teď je můj komentář příliš dlouhý – snažil jsem se ukázat, v čem mi přijde článek spíše matoucí, než že by byl tím kýženým světlem, které nám, zneuživaným ovečkám, co podlehly krysařům vyluzujícím falešné MV*tóny, po desetiletích tápání ukáže tu pravou cestu, kde nebudeme hhlavně řešit tím, že si pleteme presenter a controller. Ta naznačená distinkce mezi controllerem a presenterem je totiž také zvláštní.

I v desktopové aplikaci se dá běžně použít (a já běžně používám) Front Controller a sada controllerů-presenterů v pozadí.

Např. (i v MDI) aplikaci tlačitka, položky v toolbaru a položky menu se po svém stisku pošlou do controlleru svůj "identifikátor-klíč", front controller podle klíče vyzvedné controller (realzovaný většinou vzorem Command) pro danou "akci", zavolá jeho metodu Execute a controller si uloží do seznamu provedených akcí, aby mohl např. akci odvolat. Pak je zajímavé řešit, jak může controller pomoci při realizaci undo-redo scénáře, jak si poradit ve webových a desktopových aplikacích s controllery, které udržují-neudržují vlastní stav. To je přímo na sérii článků.

Články mají za mě několik dobrých a kvalitních odstavců, ale z valné vštšiny jde spíše o kompiláty názorů z Domain Driven Designu, postupů v ASP.NET MVC, Silverlightu, něco předpokládaného z Dependency injection apod. Slovo kompilát není míněno nijak pejorativně, naopak dobrý kompilát by se v češtině určitě hodil, ale vadí mi Borku, že své vlastní termíny a předpoklady moc nevysvětluješ. Navíc, třeba Domain Driven Design má své vlastní problémy, na které člověk narazí při prvním pokusu o implementaci. Ale to je už opravdu zcela jiné téma.

Dík za pěkné články. Myslím, že jsem si v těch třípísmenných
zkratkách udělal výrazně větší pořádek než jsem měl před jejich
přečtením.

Ještě mi však nedá nepřidat ještě jednu zkratku. Nedávno jsem četl
o DCI a přišlo
mi to jako rozumná kritika MVC s pěkným návrhem jak z toho ven. Možná se
to někomu bude při navrhování hodit.