Vícevrstvý model best practice

Oli

Ahoj,
koukal jsem se a nikde není žádná aktuální best practice pro práci s modelem. Mám na mysli 3 nebo 5 vrstvý model. Zkoušel jsem to napsat podle staršího článku Filipa Procházky. Tohle řešení má ale tu vadu, že tím ztratím reference na propojený tabulky.Je to vubec možný s Nette database?

Další věc, jak a kde kešovat? Koukal jsem, že context přijíma storage. Pokud mu předám cacheStorage, tak si to Context sám kešuje a už to nemusím řešit jestli mě vrací selection z db nebo z cache?

Mesiah

Ahoj,
osobně používám a taky se mi líbí práce s Modelem, jak popisuje Aleš Roubíček a Filip Procházka s tím, že používám ORM LeanMapper – máš nějaké ORM, nebo vše řešíš přes Nette database svépomocí?
U mě v projektu je Presenter, ten komunikuje s Orchestration vrstvou, ta řeší jednotlivá use-case a k tomu využívá Query object + repository a pokud jde o složitější operaci, tak jiné Orchestration.
Zvažoval jsem, že z Orchestrace nebudu vracet entity, ale jejich DTO – nakonec jsem to ale zavrhl, je to pro mě „předčasná optimalizace“ bo jde o one-man-show projekt.
A ohledně kešování, tak to jsem zatím neřešil, ale předběžně jsem si říkal, že pokud budu potřebovat kešovat, tak nejspíš na úrovni repository.
Ale asi tu budou lidi, co mají více vychytanou architekturu aplikace, tohle ber jen jako jeden z přístupů…

Oli

Díky, s dao od Filipa si hraju sám ve vlastních projektech, ale s kolegou teď migrujeme na 2.1 a používali jsme v podstatě jen jednoúrovňovou vrstvu, kdy presenter volal model a ten rovnou šahal do databáze. Pro malý weby v pohodě, ale přijde mě, že to není škálovatelný a těžko by se tam přidávala třeba ta cache. Prostě se mě to moc nelíbí. Tak jsem se koukal jaký je nejlepší řešení a jestli je něco takovýho možný i s nette database. Moc jsem toho právě nenašel, takže jsem rád za každej podmět.

Když už jsi to nakousl, tak dodatečná otázka, jaké výhody má ORM? A od kdy (rozuměj velikost projektu) je výhodné se ORM zabývat? Sám jsem si teprve nedávno začal hrát s Kdyby/Doctrine a líbí se mi to, ale nejsem schopnej dát relevantní argumenty, proč přepisovat jednovrstej model (když funguje) do ORM. Proti ORM jsou v podstatě jen peníze (přepsání už hotové funkcionality + vůbec samotné učení).

Mesiah

Pro mě byl důvod použít ORM to, že v aplikaci chci pracovat s třídami, v podstatě jsem chtěl v maximální míře zapomenou na to, že někde je nějaká persistace dat, i když úplně na to zapomenout nejde a taky to nemám ideálně zapracované – k ideálnímu stavu mi chybí Unit of work (ten je defaultně v Doctrine2, ale v LM je potřeba si jej napsat – zatím to je pro mě nice-to-have; je pro mě důležitější rozjet aplikaci do použitelného stavu i za cenu ne-dokonalého kódu). To je v podstatě i odpověď, jaké jsou pro mě výhody ORM, další je právě to kešování – teoreticky bych měl být schopný přidat cache bez toho abych dělal nějaké změny na vyšší vrstvě aplikace, což jsou pro mě orchestrace. (Edit: promiň napsal jsem nesmysl, tohle vůbec nesouvisí s tím, jestli použiješ ORM nebo ne, tohle je spíše otázka architektury aplikace.)
A velikost projekt – nemyslím si, že velikost projektu má vliv na to jestli použít ORM nebo ne, výkonnostní pálka je myslím v případě LM zanedbatelná – Tharos dělal test, kde porovnával Nette Database, Dibi, NotORM (ale musím upozornit, že šlo o jednu z předchozích verzí Nette Database, nyní je situace jiná) a LM se vedl velmi velmi dobře, myslím, že dopadl 1. nebo 2. v rychlosti, a v prostorové náročnosti taky na tom nebyl vůbec zle.
Použít ORM je prostě fajn, hezky se mi píší aplikace a to je, aspoň zatím, pro mě nejdůležitější argument.

Editoval Mesiah (26. 1. 2014 19:25)