Jak propojit MVP a kešování aplikace?

_Martin_

Ahoj, rád bych implementoval do své aplikace kešování, ale narazil jsem na rozpor s architekturou MVP. Chtěl bych kešovat rendrovanou stránku, neboť, dle mého subjektivního názoru, rendrování zabere nejvíce času. Chování aplikace při požadavku na stránku je takové:

je-li stránka v keši platná, pošlu ji spolu s $presenter->lastModified(…) a ukončím aplikaci
je-li crc dat aktuálních shodné s crc dat použitých pro poslední rendrování keše, označím keš za platnou, pošlu ji spolu s $presenter->lastModified(…) a ukončím aplikaci
rendruji stránku do keše, pošlu ji spolu s $presenter->lastModified(…) a ukončím aplikaci

V čem je onen rozpor? Předpokládám, že presenter jsou všechny metody presenteru vyjma metod beforeRender, renderXYZ a afterRender – ty patří spolu s šablonou pohledu. Pokud budu uvažovat, že kešování renderu spadá do kompetence pohledu, nebudu moci kontrolovat platnost keše před načtením dat z databáze – data se totiž nemohou načítat v pohledu. Nebo ano?

Jsem z toho zmatený, šlo by nějak zachovat tento postup kešování (kontrola keše, kontrola dat, rendrování) a zároveň neporušit MVP? Pokud MVP chápu špatně, tak mě prosím opravte.

Villem

Chápu tvůj problém dobře?

Pokud chceš provádět krok 1 ještě před načtením dat z DB musí toto probíhat v metodách beforeRender, a render. Což je rozpor, který ti nesedí k MVP?

V tom případě je takovýto postup nemožný. Musíš se pro kešování ve view vzdát kroku jedna. A nebo přenecháš kešování presenteru, čímž ho ještě více svážeš s kontrétními view. V tomto případě nevidím jednoduché řešení jak toto obejít pokud metody beforeRender,… považuješ za součást šablony.

Já osobně považuji za view pouze vlastní šablonu a template za rozhraní mezi ní a presenterem. Vycházím přitom z této filosofie. Úkolem šablony je zobrazovat uživatelské rozhraní a data. Úkolem presenteru je zpracovat požadavky uživatele, zvolit správnou šablonu a připravit data pro šablonu. Potom kešuješ v presenteru.

Další legitimní filosofií je použít presenter pro pouze pro volbu šablony a parametrizaci a nechat samotnou šablonu, aby získala potřebná data. Pak můžeš bez problémů použít kešování tak jak jsi o tom mluvil (a pak je naprosto vpořádku šahat do modelu ve view).

Obě filosofie ti umožní použít tvůj postup kešování. Záleží jen na tom co si zvolíš. Neexistuje žádný „správný“ postup.

_Martin_

Ano, chápeš to správně. Dříve jsem za pohled považoval také jen šablonu, ale při volání $httpResponse->setContentType('application/xhtml+xml', strtolower(Environment::getVariable('encoding'))); v presenteru jsem začal váhat. Následně jsem četl článek Jakuba Tichého a Davidovi komentáře a začal jsem se řídit myšlenkou, že jakákoliv část z trojice MVP by měla jít kdykoliv vyměnit za jinou implementaci bez narušení funkčnosti – což mě vedlo k tomu, začít považovat volání této funkce (a tedy i metody render) za součást pohledu (pokud bych chtěl export do PDF, hlavičky i šablonu změním v pohledu).

V Nette začínám vidět větší provázanost presenteru a pohledu a mám problém si vybrat nějakou konkrétní filozofii, neb se bojím, zda později mi ona filozofie nebude na překážku právě kvůli této provázanosti dvou zcela odlišných částí. Neměl by mít návrhový vzor filozofii jasně danou, aby nevznikaly podobné nepředvídatelné situace?

Napadá mě, že kdybych použil líné dotazy do databáze, mohl bych se nejprve dotázat modelu, ale až v pohledu by se dotaz ve skutečnosti provedl. Což bude funkční, ale budu muset překousnout, že se spoléhám na konkrétní implementaci modelu – což taky není zrovna dobře.

Villem

_Martin_ napsal(a):

Ano, chápeš to správně. Dříve jsem za pohled považoval také jen šablonu, ale při volání $httpResponse->setContentType('application/xhtml+xml', strtolower(Environment::getVariable('encoding'))); v presenteru jsem začal váhat.

Tak tohle tě zmátlo? No určitě máš pravdu v tom, že to patří do pohledu. Ale já bych se nebál používání modelu v pohledu. Jenom si pak musíš stanovit úkoly presenteru a ty pak dodržovat. Něco ve stylu, že presenter bude pouze nastavovat pohled a ten si data z modelu vydoluje sám.

Co jsem měl možnost zjistit, tak MVP/C nedefinuje přesně, kde vede dělící čára mezi modelem, presenterem a pohledem. Jenom příká, že to rozdělení má být takové aby bylo možné jednotlivé části měnit při zachování stejného rozhraní. No a tvým úkolem je potom zvolit taková rozhraní, která jsou pro tvou aplikaci nejvhodnější.

Editoval Villem (17. 1. 2009 11:45)