MVC paradox a jak jej rešit

Paráda, zrovna před pár dny jsem tohle řešil při rozmýšlení nad architekturou jedné menší aplikace využívající krásu a sílu Nette a Dibi 

A ještě k tomu voňavou kávu z Nette automatu, díky 

DibiDataSource je moc pěkná věc.

Jenom se mi špatně píše dataSource->select(...), když je těch sloupečků hodně. Líbilo by se mi nějaké zjednoudušení, že by šlo místo $articles->select(array('url', 'title', 'perex')) psát třeba $articles->select('url,title,perex').

A co na to DGXova britva dobreho mvc konkretne bod 1?

• když změním názvy sloupců v databázové tabulce, bude nutné editovat kód controlleru či view?

Nepremyslis nad tim, jak dostat mezi sablonu a db jeste nejakou nepovinnou mezivrstvu?

Napadl me nasledujici priklad. Mam multijazycny web a chci vypsat titulek produktu v pozadovanem jazyce, nebo pokud neni prelozen tak v defaultnim jazyce.
V sablone potom jenom {$product->getTranslated­Title()}. Super by bylo, kdyby datasource umel prijmout i argument, ve kterem specifikuju tridu ktera se ma vracet (jinou tridu nez DibiRow) (asi implementaci IDibiRow). ? To by bylo si myslim uz potom docela fer.

Hm, vidim to presne naopak. Radek typu

$articles->select(array('url', 'title', 'perex'))->orderBy('title')

nema podle me ve view vubec co delat. Co ma view co vedet o tom, ze se to nejak radi a podle ceho? View ma iterovat pres data a zobrazit je.
Az budete chtit stejna data poslat treba pres webservisu v XML nebo JSONu, budete tuhle logiku vybirani a razeni psat znova a az to budete menit, budete to menit na 2 nebo 3 mistech? Misto toho, abyste jen napsal nove sablony, ktere iteruji a vypisuji dodana data v jinem formatu…

Nehlede na to, ze z toho jeste rovnou cisi, ze pouzitym datastorem je relacni databaze, coz uz je uplne blbe… (i kdyz uznavam, ze to neni jednoznacne)

Stejne tak nechapu to o tom „zamorovani“. Model je vrstva, ktera ma dodat data takova a v takove podobe, jak chce controller (nebo treba view helper). Na metode getArticles(or­derBy, page) nevidim nic spatneho.

Řeším to stejně, jenom používám jinej stavební materiál (ehm… ZF, ehm… Doctrine), akorát si pořád nadávám do různých hospodářských zviřátek, že tím vlastně stěhuju logiku z modelu do controlleru. Ono totiž ve většině případů není nutné mít ani žádnou metodu modelu getArticles(), která by vracela Query object k dalšímu doupřesnění podmínek, ale je kratší si celou query sestavit přímo v controlleru :)

Dibi začíná pomalu LINQovatět :) Dobrá práce.

Asi jsem tu MVC pochopil špatně, ale dokonce i v mé wikipedii je:

As an architectural pattern
(…) and the controller is the code that gathers dynamic data and generates the content within the HTML or XHTML (…)

Podle mě to docela zapadá do toho co je na papíře: Controller není jenom vrstva navíc (ona by jinak nedávala smysl), ale prostře vrstva která reaguje na akce uživatele, „čistí“ je a podle nich komunikuje s modelem.

Model nezajímá, že jsme se rozhodli stránkovat. To zajímá controller, který si taky podle toho řekne o patřičné články (v Djangu by to třeba bylo Articles.objec­ts.all().orde­red_by(‚sloupec‘)[od:do], což by se přeložilo do patřičného querysetu, ale třeba to může být Articles.get(order, from, skip), whatever).

Každopádně v tom pořád nějak nevidím MVC problém (čimž nepolemziju s tim data sourcem ,))

Možná to je trochu OT, ale když tu chválíš ten jeden dotaz, tak řekněme, že chceš je každému článku i jméno autora. V tabulce je pochopitelně jen id, …
O to by měl požádat view nebo controller (oboje má své výhody a nevýhody).
Samozřejmě by to mělo jít přes model, třeba pomocí getUsers().
Dál, hodilo by se umožnit trošku omezit nebo abstrahovat názvy sloupců.
Názvy sloupců by ve viewu být mohly, ale orderBy mi tam moc nevoní.

@v6bak: Pokud to bylo na mne, tak:

– Nechvalim ten jeden dotaz, to byla jen demonstrace. Pointa byla v tom, ze si na to proste vytvorim pristup k modelu.
 – V tabulce ano, ve vystupu v modelu ne, pokud si ho tak naprogramuju. To je pointa: model nejsou jen prelozene tabulky na objekty, model je logika, ktera se chova tak jak chci
 – Ano, abstrahovat by se to melo, na tom co jsem popisoval to nic nemeni
 – To co pisu se dava do controlleru, ne view

Vida, něco jako LINQ v PHP :) Chvályhodný počin, i když teda souhlasím s Danielem, že složitější metody getArticles() v modelu nejsou nutně špatné (nazval bych je jen méně elegantními). A už vůbec bych nešel tak daleko, abych použil výraz „paradox MVC“; s tím marketingem se to zas nesmí tak přehánět :)

#5 Koubas: To jako ze primo v controlleru mastis SQL?..... 

Jednou ze zakladnich myslenek MVC je, ze M, V i C musi byt „pluggable“ (nechce se mi premyslet nad ceskou alternativou ). Tedy v praxi primarne M a V. Model by mel byt v idealnim pripade naprosto nepruhledny, pokud jde o typ backendu. Tzn. vracet asoc. pole, objekty z domenovych trid, cokoliv… ale tak, aby pri zmene zpusobu ulozeni dat nebylo nutne zmenit v C a V ani carku. To taky znamena zadnou vazbu controlleru na konkretni ORM a uz vubec ne psani SQL dotazu v C vrstve… :)

Tim nechci rict, ze se mi nikdy toto nepodarilo porusit nebo ze snad je mozne to vzdy na 100 % dodrzet, jen se snazim toto mit jako svuj cil u kazde aplikace – i kdyz treba u XRX aplikaci je prakticky nemozne toho dosahnout – to je proste koherentni architektura, u niz vymena jedne casti znamena ztratu smyslu celku

#3 Washo: Když změním názvy sloupců v databázové tabulce, nebo dokonce z nějakého sloupce udělám číselník do nové tabulky, tak nemusím měnit API modelu. Jen napíšu SQL příkaz tak, aby generoval stejný výsledek, třeba pomocí aliasů.

Zrovna ten multijazyčný web je nádherný příklad. Model by měl metodu setLang() a SQL by poskládal tak, aby ve sloupci title byl titulek ve správném jazyce, ať už je multijazyčnost v databázi řešena jakkoliv.

Super by bylo, kdyby datasource umel prijmout i argument, ve kterem specifikuju tridu ktera se ma vracet (jinou tridu nez DibiRow)

Ano, to je v plánu. Zatím to jde jen kostrbatě.

#4 Daniel:

Co ma view co vedet o tom, ze se to nejak radi a podle ceho? View ma iterovat pres data a zobrazit je.

A kdo jiný, než právě view, to má vědět? Možná teď jen mícháš pojmy view a šablona. Tenhle článek je o view.

Nehlede na to, ze z toho jeste rovnou cisi, ze pouzitym datastorem je relacni databaze.

Pouze u metody where() (proto také není v IDataSource). Jiný datasource ji nemusí implementovat.

#8 v6ak:

Dál, hodilo by se umožnit trošku omezit nebo abstrahovat názvy sloupců. Názvy sloupců by ve viewu být mohly, ale orderBy mi tam moc nevoní.

Abstrahuj ve své mysli. Názvy sloupců určuje API modelu, někde v dokumentaci metody getArticles() bude jejich výčet. Nikde přitom není řečeno, že stejné názvy sloupců má databáze (ani nemusí).

A pokud už máme názvy sloupců dané, je přeci jedno, jestli je použiju v echo $row->title nebo $articles->orderBy('title')

#6 Aleš Roubíček: #10 Borek: hehe, koukám že Microsoft se mnou stále drží krok (což je marketingově ještě přehnanější nadpis než ten „paradox“!)

#12 David Grudl:

A kdo jiný, než právě view, to má vědět? Možná teď jen mícháš pojmy
view a šablona. Tenhle článek je o view.

No vzdyt ty to ale mas prave v te sablone… Jasne, treba v GUI aplikacich, kde je ve view nejaka tabulkova komponenta zobrazujici data, tam vi View o razeni. Ovsem v klasickem pripadu webove aplikace bez RIA natury ci AJAXu nevidim duvod. View pres HTTP preda controlleru a potazmo modelu pozadavek na razeni a stranku a controller mu zpet preda data z modelu, ne? Proto je dobre pouzivat sablonovaci systemy, kde nelze jen tak jednoduse mastit rovnou PHP (dosadit vlastni oblibeny jazyk)… nehlede na to, ze pak lze pouzit stejnou sablonu na nekolika mistech. Tu sablonu, co tu mas, pouzijes tam, kde chces url, title a perex razene podle title a konec.

#13 David Grudl: Možná jsem se na to špatně podíval. TEď to vapadá ještě zvláštněji. Cože se stane? Dibi zparsuje SQL a pak dělá fluent-like úpravy?
#9 Almad: „V tabulce ano, ve vystupu v modelu ne, pokud si ho tak naprogramuju. To je pointa: model nejsou jen prelozene tabulky na objekty, model je logika, ktera se chova tak jak chci“
E? Na co vlastně odpovídáš? S tou „pointou“ souhlasím.

#12 David Grudl: No tim padem multijazycny web neni zas az tak dobry priklad pro to co jsem jim chtel ilustrovat. :) Slo mi hlavne o to ze pomoci SQL se prave obcas neda uplne vsechno dost pekne vyjadrit a co by slo jednoduse v PHP musi se v SQL delat slozite. Kazdopadne v tom pripade me tesi, ze se pocita s tim, ze Datasource bude umet vracet i jinou tridu nez Row. Super a uz se tesim.

Nezdá se mi, že tento návrh obcházení smyslu MVC je nejlepší řešení virtuálního problému. MVC má mimo jiné za úkol oddělit prezentační vrstvu od aplikační. Zde se tyto vrstvy snažíme promíchat, tedy View musí znát jak jsou do něj data předávána z aplikační vrstvy pomocí DibiDataSource. To je ale popření principu MVC.

#17 Aichi: to přece není návrh na obcházení MVC, právě naopak. Ukázka, jak psát aplikace šikovně rozdělené do tří vrstev (tři ukázky kódu) a vyhnout se promíchání.

Něco víc k MVC.

#18 David Grudl: myslím, že si nerozumíme. Ano MVC rozděluje aplikaci na tři vrstvy. Nicméně v aplikaci máme také vrstvy jiné (aplikační a prezenční). A tyto dvě vrstvy v tomto nešťastném příkladu mícháš a porušuješ Single Responsibility princip.

Proč má View vědět o tom jak se získávají data do modelu? Proč mají umět pracovat s DibiDataSource? Všechna relevantní data mají dostat od modelu, který vizualizují.

#19 Aichi: Myslim ze te matou ty nazvy metod select a orderBy, ktere jsou takove SQLacke. Ja to beru tak, ze v sablone jimi pouze definuji data, ktere budu potrebovat pro vypis. Je to proste jenom chytrejsi volani $article->title, nebo spis dopredu dam vedet co budu potrebovat a vytvoril optimalnejsi iterator. Dalo by se to presunout do modelu ale tim bys snizil pouzitelnost metody Model::getArti­cles(). A docela zbytecne.

#19 Aichi: IDataSource je API modelu. Model má metodu, která vrací IDataSource (stejně jako kdyby vracela řetězec, pole, nebo cokoliv jiného, je to jedno).

View neví, „jak se získávají data do modelu“, nezajímá ho to. On dostane IDataSource, konkrétně jeho implementaci DibiDataSource a s tou pracuje. Nad IDataSource se dá iterovat a vypsat jeho obsah. Iterování lze omezit na určitý rozsah. Dokonce lze data pro iterování nechat setřídit podle nějakého sloupce. Ale rozhodně ho nezajímá, jak je to řešeno uvnitř, jestli se data tahají z SQL databáze a kdy se tahají. Model klidně může vrátit ArrayDataSource, což bude zapouzdření nad statickou tabulkou. Na view to nebude mít dopad.

#3 Washo:

Nepremyslis nad tim, jak dostat mezi sablonu a db jeste nejakou nepovinnou mezivrstvu?
Super by bylo, kdyby datasource umel prijmout i argument, ve kterem specifikuju tridu ktera se ma vracet (jinou tridu nez DibiRow)

#12 David Grudl:

Ano, to je v plánu. Zatím to jde jen kostrbatě.

Neco takoveho jsem uz resilt.

// vycuc
class MyDataSource extends DibiDataSource {

                private $rowClass = null;

                public function __construct($sql, $rowClass = null, DibiConnection $connection = null) {
                        $this->rowClass = $rowClass;
                        if ($connection === null) {
                                $connection = dibi::getConnection();
                        }
                        $sql = $connection->sql($sql);
                        parent::__construct($sql, $connection);
                }

public function getResult($debug=0) {
                        try {
                                $result = parent::getResult();
                        }
                        catch (DibiException $ex) {
                                throw new ModelException(Model::ERROR_DB, Model::ERROR_DB_NUMBER, $ex);
                        }
                        self::printDebug($result, $debug);
                        if ($this->rowClass && $result instanceof DibiResult) {
                                $result->setRowClass($this->rowClass);
                        }
                        return $result;
                }
        }

Takze nakonec kdyz zavolam getReuslt() dostanu DibiResult, ktery bude vracet mnou specifikovany objekt, kde si mohu s daty delat co chci (zprehazet ci prejmenovat sloupecky dle nejakeho ORM)

Aby bylo jeste psani SQL dotazu prijemnejsi vyuzivam:

dibi::setSubstFallBack('dibi_substFallBack');

function dibi_substFallBack($subst) {
                if(!$subst || strpos($subst, '.')===false) return '';

                list($model, $item) = explode('.', $subst);
                switch($item) {
                        case 'table':
                                return dibi::$substs[''] . call_user_func(array($model, 'getTable'));
                        case 'pk':
                                return call_user_func(array($model, 'getDBPK'));
                        default:
                                return call_user_func(array($model, 'getColumn'), $item);
                }
        }

kde se napr dotaz: SELECT * FROM :Clanky.table: prevede na prislusny nazev v DB.

PS: lze nejak pri psani komentare upravit nahled? Mam tu jen moznost Pridat komentar

Výsledkem je ..... neposkvrněná architektura MVC.

Tak o tomto tvrzení silně pochybuji (diskuzi jsem četl).
Čuňáren, kdy volám nějaké funkce ze šablony, se snažím odnaučit. Toto je IMHO krok zpět. A zcela zbytečný, protože totéž mohl zařídit controller a view měl dostat již předchroustaná da­ta.

#11 Daniel: „To jako ze primo v controlleru mastis SQL?..... “
Ne, jelikož použivam Doctrine tak žádné SQL v pravém slova smyslu nemám.

Zezačátku mi to přišlo být podobné, jako je uvedeno v článku – jelikož s Dibi ani Nette jsem ještě nedělal, tak jsem měl pocit, že DataSource je jakýsi náznak ORM. Pokud je ale IDataSource dostatečně univerzální a ne napsaný na míru pouze relačním databázím – jako v případě ORM, tak to beru v rámci PHP jako docela revoluční počin, protože s podobnou implementací jsem se v něm ještě nesetkal, pokud si ale dobře vzpomínám, něco podobného jsem kdysi zahlédl v Delphi.

Každopádně se tímto pro mě stal článek prudce inspirativním :)

@kritici: Tak především si uvědomte, že to je nezávislé na implementaci zdroje dat. Minimálně pro výběr sloupců to je čisté.
Nějaký join by taky měl být čistý, i když nevím, jak na něj.
Co se týče řazení a filtrování, to bych už ale do viewu fakt necpal.

#23 zadluzen: Tak podle mě jde v první řadě o to, jaký koncept (pull/push) šablon používáš. Zda si šablona o data žádá sama, nebo zda jsou do ní data nacpaná…
Žádá-li si sama, proč by mělo být prasárnou zavolat si nějakou modifikační funkci navíc?

Tohle se příčí ne snad přímo MVC, to určit ne, ale spíše mému osobnímu chápání VIEW.

Když bych to měl popsat nějak tak polopaticky – třeba na všem programátorům blízké analogii s pečením – VIEW je jako formička (template) do které se naplní těsto (data), aby to nějak ve výsledku vypadalo. Pokud chci v těstě oříšky nebo kakao, tak je musím přidat na recept (controller) nebo je přihodit když těsto míchám (model).

#21 David Grudl: Zkus IDataSource přejmenovat na IEnumerable nebo IQueryable a přestane to pálit. :)

OT: moc pěkné písmo na nadpisy :p (generuje se nějak „zvláštně“ tím přiloženým js?)

#29 m4tt: http://suewebik.net/index.php?…

vizte Velký problém s DibiDataSource (a MySQL) (na dibi fóru)