mvc vzajomne rozdelenie funkcii (hlavne medzi modelom a presenterom)

lamerko4ever

cavte, pracujem na jednej aplikacii a rozmyslam nad spravnym rozdelenim „prace“ medzi model a prezenter.

konkretne povedzme, ze mam formular na vytvorenie noveho projektu a v metode formSucceeded obdrzim data z tohto formulara. Pri vytvarani projektu sa vklada nielen samotny novy zaznam do tabulky projektov ale pridava sa napriklad vztah aktualneho uzivatela k tomuto projektu (cize vkladanie do dalsej tabulky) plus nejake dalsie veci. Su dva typy riesenia:

riesenie – v presenteri obdrzim data, zakladne data z formulara poslem prislusnemu modelu, ktory ich vlozi do tabulky, dalej si v presenteri poskladam data pre vytvorenie vztahu projekt-user, tie poslem znova modelu, ktory ich vlozi zasa do dalsej tabulky
riesenie – modelu poslem z presentera vsetky potrebne data a v ramci danej metody, ktoru volam, sa vykona volanie dalsich metod na vlozenie projektu, vytvorenie vztahu projekt-user

Ktore riesenie je podla vas lepsie a preco? Ma presenter riesit tieto veci, alebo sa ma starat len o to, ze
si – poziada o data model, nasledne ich vlozi do view
– vytvori komponentu(typicky formular), kde sa moze zasa dozadovat niektorych dat z modelu
– obdrzi data z odoslaneho formulara a posiela ich modelu
– overuje pri akciach, ci aktualne prihlaseny uzivatel ma na danu cinnost prava

Mariocz

já bych to řešil takhle:

formulář by dostal nějaký objekt ProjectManager kterej bude mít přístup k zápisu do obou tabulek (nejspíš přez nějakej injectnutej objekt (třeba dvě repositories). Do metody addProject mu pošlu přímo z formuláře data na přidání.
Presenter bych z toho úplně vynechal. Ten jen vytvoří formulář a předá mu požadovaný služby. když uživatel nemá právo přidávat, vůbec by neměl formulář nebo celé view vidět. to bys měl řešit v presenteru.

Jiří Nápravník

Presenter tady zrovna ma figurovat jenom v tom, ze vytvori tovarnickou fomrular. Formular ma byt idealne v komponente, tam mu i nabindujes callback na zpracovani v pripade uspechu. Tam si pak ziskas ty data z formulare, das je do nejake formy – asi nejlepe nejake pole a to pole posles modelu a ten si tam podle toho dotaha ty potrebne informace a pouklada kam ma co.

Ci-li ty data pro vztah bych resil az v modelu, je to v podstate prace pro model. Predstav si, ze vymenis presenter napriklad za mobilni aplikaci. Take bude pro tebe nejjednodussi vzit data z toho „mobilniho formulare“ pretransformovat na pole, a to pole pak poslat modelu. Mas tak mobilni aplikaci, presenter a oboji vyuziva bez problemu model, ktery to resi na jednom miste a nemusis pak v tom pripade duplikovat kod v appce a presenteru.

Šaman

IMHO tak, jak napsal @Jiří Nápravník.
Ono jedna věc je architektura MVC/MVP a druhá věc je si uvědomit, že v základní Nette aplikaci vůbec nepíšeme tu prezenční část – P.

My napíšeme šablony (patří do V) a do presenterů většinou píšeme hlavně action/render metody, které patří taky hlavně do view – V! Protože v těchto metodách, kromě načtení dat, řešíme především filtrování, řazení a podobné záležitosti, které se IMHO týkají spíš pohledu (ač ne přímo šablon).

To P z MVP a nás dělají 2/3 frameworku. Zpracování requestu, routování, zpracování konfigurace, práce se zdroji (session, cookies, různá úložiště), cachováni, vytvoření response a určitě spousta dalšího. Pokud si neupravujeme tyto rutiny, tak defacto nezasahujeme do P. P je to, co drží aplikaci pohromadě. P je většina Nette frameworku.

No a model je všechno ostatní.

Mimochodem, protože Nette aplikaci chápu jak jsem popsal výše, tak mi přijde nepříliš vhodné oddělovat presentery a šablony do jiných adresářů. Pokud pracuji na pohledu, pracuji na šabloně a odpovídající action/render metodě. Tyhle věci patří k sobě, přesto, že v action/render metodě může být kus P (načtení dat, řešení oprávnění). Nicméně chci-li přidat pohled, musím zasáhnout i do presenteru, což naznačuje, že tyto záležitosti nejsou tak oddělené, jak napovídá adresářová struktura.

lamerko4ever

Jasne, diky za rady, trosku sa mi vsak nepaci skutocnost, ze trebars ten projectModel musim dotiahnut do presenterov, komponent a este aj do datagridu, ktory pouzivam.

UPDATE – datagrid ma pristup k presenteru, cize tie modely ziskam vdaka nemu a nemusim ich posielat ako parametre pri vytvarani

Cize spisem, ako to teda planujem rozdelit:

Sablony(View) – klasika, html kod, praca s objektami, ktore som dostal do template z presenteru
– ziadne priame pristupy k db, praca len s datami, ktore mi doda presenter
Presentery – ziskavanie dat z modelov a ich posielanie sablonam
– vytvaranie formularov cez komponenty
Model – vkladanie dat do databazy, selectovanie dat
– obdrzanie dat z formularov, ich nasledna uprava a patricna akcia – insert, update
Komponenty(hlavne formulare) – vytvorenie, poskladanie z patricnych prvkov
– rules, setRequired, pravidla, kde overujem vlozene hodnoty napr ci uz nie su
v databaze
– do metod formSucceeded – ziskanie hodnot z formulara cez getValues a nasledne
ich odoslanie patricnemu modelu

Este je otazka, ako navrhnut modely:

Projekty – moznost vytvorit projekt, zmenit projekt, pridat pouzivatela k projektu, logovanie zmien
v projekte
Na toto mam spraveny projektModel, otazka je, ci ma riesit aj to logovanie zmien

Kazdy projekt moze mat kategorie, kontakty, weby – pre kazdu z tychto entit je mozne pridat, upravit, (zmazat), – kazdu entitu je mozne priradit naraz k viacerym projektom, kazda akcia sa tiez loguje ako zmena daneho projektu

cize pribudne webModel, categoryModel, contactModel,

cize z toho vyplyvaju dve otazky – spravit logModel a pripadne pridavanie webu, kontaktu a kategorie k projektom riesit v projektModeli, alebo mat len metodu create v danom modeli a tam spravit vlozenie danej entity, zalogovanie a pridanie vztahu k projektom

Trosku som sa rozpisal :-), kazdopadne vdaka za vsetky rady

Editoval lamerko4ever (19. 4. 2014 11:19)

lamerko4ever

Plus situacia je komplikovana preto, ze pri vsetkych logoch si ukladam, ktory uzivatel danu zmenu spravil, to znamena, ze pri zavolani metody konkretneho modelu mu okrem dat z formulara potrebujem poslat aj id aktualne prihlaseneho uzivatela (nakolko predpokladam, ze mat v modeli premennu, ktora si bude to idcko drzat, je kravina) preto je trosku cudne volanie metody $this->webModel->create($values, $this->userId) – aj ked mozno som cudny ja no :D