Návrh modelu produktu, který načítá z databáze cenu dle vnějšího kontextu

No je pravda, že přímo toto řešení mě nenapadlo a je skutečně jednoduché. Problém je, že bych potom musel do každé šablony dávat k dispozici model a uživatele a pokaždé volat tuto metodu. Nette ještě moc dobře neznám a asi by se to dalo usnadnit nějakým Helperem, ale i tak je to věc, na kterou by bylo potřeba pamatovat a to naprosto pokaždé.

Kdybych měl problém zobecnit, tak bych řekl, že potřebuji, aby mi model vracel místo hloupých ActiveRows nějaké chytřejší objekty. Tedy abych kdykoliv mohl zavolat$product->getPrice()a dostal aktuální platnou cenu. Či ještě navíc $product->getPriceWithCurrency(), která by vrátila cenu i s uživatelsky preferovanou měnou. To je možná záležitost zobrazení a šablony, nicméně cenu takto zase potřebuji použít úplně všude, a proto by mi přišlo vhodné si formát zobrazování ceny nadefinovat na jednom místě a pak všude jinde už se jen odkazovat.

Model zatím není implementovaný nijak. Zkoumal jsem různá řešení, testoval, ale reálný kód zatím není. Hledám, jestli existuje nějaký univerzální doporučovaný koncept, jsem připraven na cokoliv :-)

Každopádně v mém případě to asi nakonec stejně bude nutné implementovat už do dotazů do databáze, protože podle uživatelské ceny budu potřebovat řadit. Tady se mi líbí dibi::dataSource. Bych si mohl nadefinovat základní dotaz, který by mi vybral správnou cenu, a na ostatních místech aplikace bych už jen dotaz modifikoval. Škoda, že toto neumí přímo Nette Database, resp. aspoň co jsem koukal, tak Selection, které podobný lazy loading umožňuje, nelze vygenerovat na základě vlastního dotazu, je ho nutné postavit pomocí $connection->table() a tam už jsou zase dost omezené možnosti při stavění dotazu. Či se mýlím?

@tobice > ano injektovat by jsi to tam musel, ale repository budes mit jako sluzbu a vzdycky si ji muzes injektnout do BasePresenteru danyho modulu. Pripadne se poohlednout treba po YetORM doplnku, ktery (podle vseho, sam sem ho zatim videl jen z vlaku) umoznuje mit inteligentrni entity, ktere by ty zminovany metody mohly implementovat. Nebo se mrknout po necem jinym nebo implmentovat neco vlastniho (Nette samo o sobe model primo neresi).

@Tabetha: Takže když vybereš z databáze seznam produktů, tak všechny ty řádky v modelu převedeš na danou entitu a vrátíš pole entit?

@hAssassin: Díky za návrhy. Mě zajímalo, jak model řeší lidé používající Nette :)

@hAssassin: Díky za návrhy. Mě zajímalo, jak model řeší lidé používající Nette :)

To je prave problem, protoze kazdy pouziva neco jinyho. Jelikoz Nette samo model primo neresi (coz je jedine dobre), je to ciste vec programatora, takze nekdo si vystaci s NDb, nekdo sahne po cistym Dibi, nekdo po Doctrine, NotORM nebo YetORM. A nebo si napise neco vlastniho. Dokonce i obyc PHP a jeho mysql_* metody se daji pouzit :-)

… pokud to dobře chápu, si ActiveRow převádí na vlastní entitu, což je v terminologii onoho článku fasáda …

Ne, bohuzel to dobre nechapes. Entita je entita, ktera reprezentuje nejaky objekt at uz s DB nebo z realnyho sveta (na to se nahlizet ruzne, ale zjednodusene to je obraz DB tabulky). Mapper se stara o nacitani a ukladani dat (a mazani) a pracuje primo s ulozistem (at uz s DB nebo file systemem). Obecne kdyz vymenis treba DB mapper za FS mapper nebo se rozhodnes data ukladat do Memcache, melo by stacit prepsat pouze mapper. Sama entita ale s mapperem nepracuje (pak by to bylo neco jako ActiveRecord – neplest s NDb, je to navrhovy vzor), ale s mapperem pracuje prave repozitar, ktery muze i vytvaret entity po nacteni dat z mapperu, nebo je ukladat (zde by mela byt nejaka prevodni logika/funkce, ktera mapuje nazvy sloupecku v DB na property entity – nemelo by to byt totiz 1:1).

No a nad tim vsim muze nebo nemusi byt facada, ktera to cely zastresuje. Striktne by totiz repositor nemel moc komunikovat s dalsimi repozitory, takze to je jedna cinnost o kterou se fasada muze starat. A dalsi je treba to ukladani, pokud je dost slozity, je lepsi ho presunout prave do fasady nez se s tim babrat v Presenteru (navic to pak muzes volat z vic mist/ruznych presenteru). No a konecne zde muzou byt i ty slozity pocetni metody. A pokud tu cenu potrebujes nejak pocitat z DB tak to jde, pouze jen propojis fasadu s mapperem pres nejakou metodu repositor, predas si do mappery IDcka uzivatele a produktu a uz si tahas a joinujes jak potrebujes (nepsal sem to uz nahodou?).

Tot asi vse. Nevim jestli sem ti vubec na neco odpovedel, asi ne. Ale co uz, mazat se mit o nechce :-P

@hAssasin: No tady došlo asi k drobnému zmatení pojmů :-) Jsem se odkazoval na příspěvek Tabethy, který „entitou“ nazývá něco jiného, přičemž to něco, se mi zdá, se nejvíce blíží fasádě.

Jinak děkuji za spoustu podnětného materiálu. YetORM vypadá velice zajímavě. Evidentní je, že řešení je spousta a je potřeba zvolit to správné vzhledem k problému.