Předzpracování dat z databáze

Rike

Chtěl bych se zeptat, co je dle vás správnější a víc „Nette“. Mám komponentu, která pracuje nad dvěma modelama. Při svém vykreslení v pohledu (foreach) zjišťuje, zda je hodnota v jedná tabulce nižší než nejvyšší údaj ve druhé. Dá se to celkem krásně vmastit do pohledu, ale není to dle mého názoru zrovna čisté. Co doporučíte? Vytvořit si kolekci dat v komponentně a pak předat k iteraci pohledu? Nebo vytvořit model, který bude obsluhovat dvojici databázových tabulek a bude vracet rovnou správnou kolekci?

A drobná podotázka – v Latte není jiný způsob, jak vnutit null hodnotám nějakou defaultní, než {$serie->note?:"chybí"|stripTags|trim}?
A ještě jedna – kam v adresářové struktuře patří třídy, které nemají ambici být knihovnou, ale konkrétní aplikace je potřebuje všude možně?

Rike

Nikdo nic? Pokud jsem to napsal nesrozumitelně, tak se ptejte…

Ot@s

No nevím, co Ti na pohledu přijde nečisté. Já osobně co lze, tak deleguju na db server (od toho tam je). Takže vyrobit pohled, resp. metodu, která ho načte/zpracuje a šoupnout ji do třídy modelu, která tomu významově odpovídá (většinou máš závislé data v nějaké hierarchii/vztahu, takže logicky podle toho). Komponenta pak bude méně závislá (jeden objekt modelu místo dvou) a primární logiku zpracování budeš mít v modelu (primární zpracování/vyhodnocování dat by se nemělo odehrávat v komponentě/jejím pohledu).

Co se týče „neknihovních“ tříd, které mají globální charakter, tak do libs a příslušného podadresáře. Principem je to knihovna. Nebo si to dej kam chceš, pokud to proháníš přes robotloader, tak je to v konečném důsledku úplně jedno. Hlavně si dobře zvol namespace. To se na rozdíl od fyzického umístění souborů mění hůře. :-)

David Ďurika

Rike napsal(a):

Nebo vytvořit model, který bude obsluhovat dvojici databázových tabulek a bude vracet rovnou správnou kolekci?

som za toto riesenie

BlueSpirit

Odkdy nesmí model pracovat s více než jednou tabulkou?

leninzprahy

To podle mě dost záleží na tom, o jaká data a jakou aplikaci jde, ale zrovna tuto situaci asi bude lepší řešit v modelu (model nejsou jen tabulky z databáze), ostatně by to šlo zjišťovat už dotazem na úrovni databáze (SELECT ..., (value < (SELECT MAX(value) FROM table2)) AS lower FROM table1 ....) a v aplikaci neřešit…
Třeba vlastní helper

$template->registerHelper('default', function($value, $default) {
	return empty($value) ? $default : $value;
});

pak můžeš používat

{$serie->note|default:'chybí'|stripTags|trim}

3. Třeba app/libs, ale záleží to jen na tobě :)

Rike

Ot@s napsal(a):

No nevím, co Ti na pohledu přijde nečisté…

Co jsem kdy četl o MVC, tak tam důsledně trvali na tom, aby pohled nijak nemanipuloval s daty (ve smyslu hledání maxima apod.), jinými slovy, má být hloupý a jen zobrazovat.

BlueSpirit napsal(a):

Odkdy nesmí model pracovat s více než jednou tabulkou?

Pochopitelně může, otázkou je, zda není lepší udělat další vrstvu modelu, která se bude bavit s těmi základními, jež reprezentují konkrétní jednu tabulku. Nevím, možná…

leninzprahy napsal(a):

1. To podle mě dost záleží na tom, o jaká data a jakou aplikaci jde, ale zrovna tuto situaci asi bude lepší řešit v modelu (model nejsou jen tabulky z databáze), ostatně by to šlo zjišťovat už dotazem na úrovni databáze (SELECT ..., (value < (SELECT MAX(value) FROM table2)) AS lower FROM table1 ....) a v aplikaci neřešit…

No, mnohdy vyžaduje databáze přístup, že se vytahá všechno, co jde, z její kompetence, aby vůbec byla schopná odezvy v nějakém rozumném čase:-)
Ani nevím, proč jsem pojal podezření, že model = tabulka, ale začala se mi teď zamlouvat ta výše popsaná varianta udělat další modelovou vrstvu a nechat opravdu ty nejnižší modely vázané s tabulkou.

leninzprahy napsal(a):
2. Třeba vlastní helper…

Díky, samozřejmě mi došlo, že si to můžu udělat sám, spíš jsem pátral po tom, proč to není v Latte rovnou. Celkem obvyklá věc, stejně jako typické return isset($array[$key]) ? $array[$key] : null, případně v Nette tuším volání Utils\Array::get().
Ale nabízí se další otázka – co si vytvořit vlastní BasePresenter jako základ pro všechny další aplikace, pěkně ho opentlit vlastníma helperama a dalšíma záležitostma a z něj pak dědit ten aplikační BasePresenter. Jinými slovy tam vmáčknout mezivrstvu. Kam s takovým počinem? To už opravdu není adept na app/lib, je přímo závislý na Nette.

JuniorJR

Rike napsal(a):

Ot@s napsal(a):

No nevím, co Ti na pohledu přijde nečisté…

Co jsem kdy četl o MVC, tak tam důsledně trvali na tom, aby pohled nijak nemanipuloval s daty (ve smyslu hledání maxima apod.), jinými slovy, má být hloupý a jen zobrazovat.

Ot@s píše o voze a ty o koze. Pohledem má na mysli database view, nikoli view vrstvu aplikace jako takovou.

leninzprahy napsal(a):
2. Třeba vlastní helper…

Díky, samozřejmě mi došlo, že si to můžu udělat sám, spíš jsem pátral po tom, proč to není v Latte rovnou. Celkem obvyklá věc, stejně jako typické return isset($array[$key]) ? $array[$key] : null, případně v Nette tuším volání Utils\Array::get().
Ale nabízí se další otázka – co si vytvořit vlastní BasePresenter jako základ pro všechny další aplikace, pěkně ho opentlit vlastníma helperama a dalšíma záležitostma a z něj pak dědit ten aplikační BasePresenter. Jinými slovy tam vmáčknout mezivrstvu. Kam s takovým počinem? To už opravdu není adept na app/lib, je přímo závislý na Nette.

Opět už to bylo řečeno – na fyzickém umístění „nesejde“, důležité je zvolit vhodně namespace, čili si můžeš vytvořit vlastní knihovnu, do které můžeš umístit vše, co např. rozšiřuje nějakou existující knihovnu nebo se hodí pro více projektů.

Ot@s

Rike napsal(a):

Ot@s napsal(a):

No nevím, co Ti na pohledu přijde nečisté…

Co jsem kdy četl o MVC, tak tam důsledně trvali na tom, aby pohled nijak nemanipuloval s daty (ve smyslu hledání maxima apod.), jinými slovy, má být hloupý a jen zobrazovat.

Asi si nerozumíme. Tys použil větu „Dá se to celkem krásně vmastit do pohledu“ a já to pochopil jako pohled databázový (CREATE VIEW AS …). Nikde jsem Ti přece nedoporučoval zpracovávat data v POHLEDU APLIKACE (naopak, přečti si kontext celého příspěvku). Tj. moje rada byla delegovat zpracování dat po ose db server a model (v uvedeném pořadí). Tím, že neuvedeš více informací, se nedá víc poradit…

Rike

Aha, tak mě zase nenapadlo, že tu může být řeč o databázových pohledech:-)

Ot@s napsal(a):
Tím, že neuvedeš více informací, se nedá víc poradit…

Principielně je to snadné – dvě DB tabulky a ke každé položce jedné potřebuješ zobrazit i výstup vyplývající z druhé. A nemusí to být zrovna něco, co lze získat spojením do jednoho dotazu. Taková je situace.
Druhá podobná je v tom, že potřebuješ data před zobrazením přefiltrovat. Opět by se to dalo dokázat ve view (MVC), kde iteruješ tak jako tak, ale není to dle mého názoru správné řešení. Jenže jakýmkoli jiným řešením si do procesu přidáš jeden „zbytečný“ cyklus, ale zase je to čistší MVC.