Jiné (zjednodušené) přístupy k MVC

Předpokládám, že jste se již seznámili s tím, jak funguje Jet MVC. Avšak v jiných kapitolách zmiňuji, tak to není jediná cesta jak MVC řešit. Ano, plné nasazení Jet MVC se hodí pro klasický komplexní projekt online aplikace. Hodí se to jako základ potálu, e-shopu, nebo vašeho CMS. K tomu je to určené a nový projekt bych bez toho nezačínal. Ale pokud děláte jednoduchý jednoúčelový nástroj, tak to vše může být kanón na vrabce.

A přímo v balíčku ukázkové aplikace takové praktické příklady najdete. Je to instalátor (~/_installer/), výstup profileru (~/_profiler/) a Jet Studio (~/_tools/studio/). Všechny uvedené mikroaplikace jsou vlastně samostatné subprojekty. I to je důvod, proč nejsou plně postavené na Jet MVC. Každá tato malá aplikace má svůj přesně daný účel. A všechny jsou také MVC, ale každá trochu jinak. A na nich si ukážeme jak lze k MVC také přitupovat, nemít žádné báze a stránky a přes to mít MVC aplikaci postavenou na Jet a to dokonce modulární.

Místo dlouhého teoretizování pojďme rovnou na praktické příklady.

1. příklad - instalátor

Co je podstatou instalátoru? Je to vlastně jednostránková aplikace. Je to jedna stránka, která se mění na základě stavu. Tedy kroku ve kterém se uživatel zrovna nachází. To znamená že nic jako báze a stránky pro chod instalátoru nepotřebujeme.

Dále je důležitý fakt, že instalátor tvoří jednotlivé kroky. Ty kroky jsou vlastně další mikroaplikace. Kroky jsou vlastně moduly. A kroky můžeme přidávat, odebírat, dokonce řešit primitivně závislosti.

Celý instalátor používá formuláře a UI prvky - budeme tedy potřebovat obecné view skripty.

Instalátor má nějaké základní rozložení UI. Pravda, jedno společné pro všechny kroky. Sice jen jedno, ale je společné. To znamená, že potřebujeme layout.

Každý krok samozřejmě potřebuje zobrazovat své UI a své výstupy. Tedy každý krok musí mít své view.

A pochopitelně si každý krok nějak musí řídit svou aplikační logiku. To tedy znamená, že krok musí mít svůj kontroler

Celý instalátor musí mít také inicializaci.

A nad tím vším musí být něco jako router, který ale nehlídá a neřeší aktuální stránku, ale aktuální krok instalace.

Tak a máme tu MVC aplikaci postavenou na Jet. A moment ... Kde že je ten Model? Model je pro instalátor Jet samotný a především nastavení aplikace. Tedy konfigurace aplikace je model, MVC báze instalovaná aplikace jsou model a tak dále.

Instalátor má i své třídy (~/_installer/Classes/), své slovníky (~/_installer/dictionaries/) a hlavně své moduly - tedy zde přesněji kroky (~/_installer/Step/)

Instalátor sice nepoužívá žádné báze a stránky sám pro sebe, ale používá Jet\MVC_View a Jet\MVC_Layout, které mohou být a jsou používány samostatně.

A dál už prosím nahlédněte do zdrojáků instalátoru ;-)

2. příklad - výstup profileru

Výstup z profileru je ta nejprimitivnější aplikace.Co má dělat?

  • Inicializovat Jet Profiler
  • Uložit protokol běhu
  • Zobrazit na stránce stavovou lištu
  • Zobrazit detailní informace o běhu
Nic víc ... Na to není třeba ani modularita. Ba naopak má to být minimalistické, aby to moc nezasahovalo do běhu vyvíjeného projektu. Tedy modularitu si škrtneme, tu nepotřebujeme.

Model je jasný. Roli modelu plní Jet Profiler a hlavně jím sestavené záznamy o běhu aplikace.

Co Layout? Ne ... Není třeba. Pro stavový proužek určitě není třeba a detail o běhu aplikaci je jeden výstup.

A View? To rozhodně ano. View je možné použít zcela samostatně, bez layoutu, ale stále jsou to tytéž view skripty jako u všeho ostatního. Jsou v adresáři ~/_profiler/views/.

A co kontroler? Ano, jistě, ten potřebujeme. Ale není třeba nic složitého. Vlastně bohatě stačí jedna anonymní třída, kterou najdete v ~/_profiler/views/Controller.php

Opět tu máme MVC aplikaci postavenou na Jet a dokonce pro Jet důležitou. Naprosto minimalistickou a titěrnou, nemodulární, jednoúčelovou, ale stále to má Model, View a Controller.

3. příklad - Jet Studio

Jet Studio je opačný případ. To je již docela rozsáhlá aplikace. Ovšem už ze své podstaty nemůže využívat plné Jet MVC, protože je to aplikace, která umí definovat a nastavovat báze, vytvářet a plně spravovat stránky, operovat s moduly a moduly dokonce vytvářet. Studio sice s Jet pracuje a plně využívá, ale zároveň to musí stát tak říkajíc stranou.

Pro Jet Studio platí vše co bylo řečeno o instalátoru. S tím zásadním rozdílem, že se nejedná o jednoúčelovou jednostránkovou aplikaci. Ne, Jet Studio tvoří několik částí. A máme tu vlastně opět modularitu.

A ony části je nutné nějak rozlišit. Proto v Jet Studiu najdete konvenční vstupní skripty, pro každou část Jet Studia samostatný. Ale řekněme to jednoduše. Prostě tam najdete ~/_tools/studio/bases.php pro správu bází, ~/_tools/studio/pages.php pro správu stránek a tak dále.

To sice připomíná "starou klasiku", ale ve skutečnosti opět narazíte na kontrolery... Tedy trochu jiná písnička na stále stejné téma.

Závěrem ...

Účelem této kapitoly nebylo do šroubku rozebrat zmíněné mikroaplikace. Ne, cílem bylo vám ukázat že opravdu není jeden jediný správný přístup a že to má své logické důvody. Podrobný průzkum zdrojáků již nechávám na vás.

Jádro celé myšlenky je to, že na daný problém má být použito správné řešení. Ne to řešení, které je tlačeno dogmatem, ale to řešení, které je technicky a pragmaticky správné.

Vás jistě napadne další problém a další řešení, další možnosti. Co je však společné je to, že rozdělit aplikaci na M-V-C je opravdu dobrý nápad a to by mělo být zachováno vždy. A účelem Jet je vám v tom pomáhat, ale ne vás omezovat.

Předchozí kapitola
Keš / Cache
Další kapitola
Aplikační moduly