Model, zbytnělé funkce pro řazení, limity, …
- tomas.lang
- Člen | 53
Zdravím! Můj problém je následující: jak nejlépe vyřešit vracení dat z modelu do prezenteru.
Konkrétněji: jelikož o řazení výsledků, stránkování, atd. nemá model ani potuchy, měl by o těchto věcech rozhodovat prezenter, k čemuž mi vedou dvě cesty: a) zbytnělé funkce typu getArticles($order,$limit,…), b) model bude vracet data v obálce podobné DibiSource abych mohl o těchto záležitostech rozhodovat později.
Cesta a) pro mě rozhodně není vhodnou cestou, současně u cesty b) je problém se samotným DibiSource o kterém se pan Grudl zmínil již dříve…
Jaké je v tomto případě nejlepší řešení krom x metod typu getAll(), getOrderBy###(),…?
Dala by se případně najít ukázka komplexnějšího webu napsaného v Nette – trochu větší než ukázka CD-collection v examples/?
Strávil jsem již spoustu hodin vyhledáváním vhodných článků a ze všeho mám akorát velkou hlavu… – rád bych používal modelový přístup „tak jak má být“ (tedy opravdu jen jako přístup k mašince která sype data), ale neustále narážím na nové překážky…
Kdyby si někdo našel čas na odpověď, rovnou bych ocenil třeba i radu v tom, jak nejlépe modelově řešit situaci kdy mám např. články a k nim tagy (tedy dvě tabulky v relaci N:M) – konkrétněji řeším to, jak docílit toho, aby se mi v jednom modelu nemotalo zbytečně moc tabulek a model měl tak jasnou strukturu (např. otázka toho jestli je rozumné aby mi model obstarávající tabulku Articles byl schopen vrátit i konkrétní data pro autora článku, nebo jestli to již řešit samostatným dotazem). Vím že je tu cesta přes NotORM, které mi „zjednodušší“ JOINování a vytahování příbuzných dat, z druhé strany při „komplexnějších“ dotazech (subquery, uniony,…) je pro mě cesta přes NotORM dosti nepohodlná…
Předem děkuji za jakékoliv rady! (vím že je to dotaz vlastně v určitých úrovních zbytečně akademický, ale rád budu znát názory lidí kteří se už s těmito problémy zabývali, byť je třeba nakonec hodily za hlavu…)
- bojovyletoun
- Člen | 667
http://hosiplan.kdyby.org/…koviste.html http://www.aceblog.cz/…-dava-smysl/
Doctrine jsem moc nezkoušel, ale třeba se ti to bude líbit
- pawouk
- Člen | 172
No podle mě je právě ta cesta NotORM aka Nette\Database přesně na tohle nejlepší. Na stránkování je přímo jak dělaná, taktéž na tabulky m:n. Jediné co by tě mohlo trápit jsou ty složitější dotazy, tak si ten složitjší dotaz vykonej v modelu pomocí SQL a pak vrat ActiveRow nebo selection a v presenteru a sablone muzes vyuzivat vyhody NotORM…
- Elijen
- Člen | 171
pawouk napsal(a):
tak si ten složitjší dotaz vykonej v modelu pomocí SQL a pak vrat ActiveRow nebo selection a v presenteru a sablone muzes vyuzivat vyhody NotORM…
Nedokazu predstavit, jak by se tohle v praxi realizovalo. (mozna ale jen neznam nejakou z magickych feature \Nette\Database). Mas na mysli pomoci SQL vytahnout pouze primarni klice a ty pak vrazit do NotORM a vytvorit tak selection? To mi neprijde uplne koser (hlavne u slozitejsich dotazu).
- pawouk
- Člen | 172
Jojo tak jsem to myslel, sohlasím že to není ideální a je možné že proběhne nějaký dotraz navíc, ale na druhou stranu by to neměla být žádná tragedie a navíc jak notOrm tak Nette\Database v pozadí také provádějí několik dotazů na místo jednoho mega joinu (to jen na obhajobu toho, že více dotazů nemusí být špatně). Kromě toho je poměrně dost těžké vymyslet takový dotaz, který nejde v NotOrm zapsat, většinou to jen uživatelé neumí zapsat.
- duke
- Člen | 650
Jedním z možných řešení je použít query objekty, tj. objekty do kterých zapouzdříš konkrétní dotaz (včetně např. paginace) a naučíš svůj model, tj. své repositáře vracet data podle těchto query objektů, tj. vykonávat tyto dotazy (čehož součástí bude mj. volání $paginator->setItemCount(…)).
V presenteru pak budeš mít něco jako:
$query = new ArticlesQuery($this['paginator']->getPaginator(), $otherParam, ...);
$this->articles = $articlesRepository->fetchAll($query);
- tomas.lang
- Člen | 53
Díky za možnosti :-) Nakonec jsem se ještě jednou zaměřil na Nette\Database, ale vypadá to, že stejně budu muset oprojít i všechny ostatní možnosti, neboť ve ve všem to stačí…
- Jan Suchánek
- Člen | 404
Pěkný večer a nelze to pouze zapsat?
$this->database->query("SELECT col FROM table WHERE ....");
- Jan Suchánek
- Člen | 404
Napadlo mě ještě máš konkrétní příklad, který ti v Nette/Database
nefunguje,
nebo nevíš jak by si ho zapsal? Taky jsem to ze začátku dost řešil :)
- Jan Suchánek
- Člen | 404
pawouk napsal(a):
@janicek: Jasně že to jde zapsat ‚SELCT FROM …‘ ale to nevraci Table\Selection ani ActiveRow ale PDOSelection, což zase neumí fukce typu ->page, ->order() apod…
@pabouku: :) to máš pravdu, máš nějaký příklad co se blbě v Nette/Database zapíše klasickým způsobem?
Editoval jenicek (7. 12. 2011 22:04)
- Jan Suchánek
- Člen | 404
Join:
$db->table("albums")->select("albums.title")->where("autor.name","Jméno");
Subselect:
$db->table("albums")->select("title")->where("autor_id",
$db->table("autor")->select("id")->where("name","Jméno");
);
je to takto správně?
jen mě nenapadá ten UNION.
Chtělo by to napsat ten komplexnější dotaz.
Editoval jenicek (7. 12. 2011 22:20)
- pawouk
- Člen | 172
No příklad by se asi vymyslet dal, ale takových podobných vláken které řeší NoteORM → SQL a anaopak už tady pár je ne? https://forum.nette.org/…nette-dotazy nebo https://forum.nette.org/…-predstaveni