Model-View-Presenter (MVP)
V poslední době se neustále mluví o návrhovém vzoru MVC (Model-View-Controller). Co to vlastně je? A k čemu je to dobré? MVC je spíše než návrhový vzor softwarová architektura, která rozděluje aplikaci do tří vrstev: na datový model, uživatelské rozhraní a řídicí logiku. Přičemž modifikace některé z nich má pouze minimální vliv na ostatní.
Když se nad tím zamyslíte, každá část kódu webových aplikací skutečně spadá do jedné z těchto kategorií. MVC však říká, že tyto části je nutné oddělit do samostatných komponent nebo modulů. V praxi se ukázalo, že jde o velmi užitečný přístup. Vývojáři si ověřili, že tato separace je nezbytná pro udržení přehledného kódu – obzvláště v případech, kdy na jedné aplikaci pracuje více lidí.
MVC dále určuje vztah jednotlivých
komponent, který je znázorněn na obrázku:
- Model zajišťuje přístup k datům a manipulaci s nimi.
- View (pohled) převádí data reprezentovaná modelem do podoby vhodné k prezentaci uživateli.
- Controller (řadič) reaguje na události pocházející od uživatele a zajišťuje změny v modelu nebo v pohledu.
Tento princip poprvé popsal Trygve Reenskaug v roce 1979. Dnes je velmi populární právě u webových aplikací, jenže často jde o tvrzení pramenící z jeho pochopení. Ve své původní podobně jej vlastně nepoužívá nikdo. Role a vztahy jednotlivých vrstev se často chápou velmi volně. To je také důvod, proč se Nette Framework hlásí k MVC jen jako k duševně spřízněné architektuře.
Logice Nette Frameworku daleko lépe odpovídá nepříliš známý vzor MVP, tedy Model-View-Presenter. Zjednodušeně tak můžeme říct, že presenter v Nette je totéž, co controller v jiných frameworcích. Pokud máte zájem se o MVP dozvědět více, doporučuji vám přečíst MVP: Model-View-Presenter od Mika Potela.
Zjednodušeně:
- model nemá vědět o tom, že nějaké view a presentery existují
- view o modelu vědět také nemusí (pasivní view), nebo naopak může data tahat přímo z něj, dle zvolené koncepce
- presenter seznámí view s modelem (ne naopak) a realizuje uživatelské
akce. Ty patří do tří kategorií
- změna view (nejčastější)
- změna stavu (interakce v rámci aktuálního view)
- příkaz pro model
Ideální je, aby se
- činnosti modelů omezily jen na získávání dat čili práci s databází
- logika v šablonách omezila na iterace, if, else.
- logika v presenteru omezila na
- plnění šablon a registraci helperů a filtrů
- sestavení stromu komponent
- úkolování tříd z modelu
Model ve většině případů bude tvořit více tříd. Jedna z nich se může starat právě o zapouzdření připojení k DB, které využijí jiné třídy modelu. Ale z pohledu celé aplikace je to chápáno jako jeden celek, jeden model.
Z pohledu jednotlivých vizuálních komponent i tyto mohou mít svůj vlastní malý model. Dal by se nazývat třeba komponentový model. Propojení těchto modelů s hlavním modelem pak opět zajistí presenter. Z pohledu celé aplikace se tyto modely budou spíš považovat za součást prezentační logiky, než součást modelu.
Viz také:
- Seriál MVC a další prezentační vzory na serveru Zdroják
- MVC paradox a jak jej rešit
