Model pro jeden záznam/skupinu záznamů

Aleš

Zdravím,
mám teď filozofické dilema jak pořešit přístup do DB přes model. Nechci teď řešit 5 úrovňový model a podobně, ale čistě jenom teorii která třída zodpovídá za co.

Řešení, které jsem používal do příchodu DI bylo, že jsem měl jednu třídu pro jeden typ položek. Statické metody poskytovaly hledání, sumy atp – prostě práci nad celou množinou položek – a její instance nad jednou položkou.

S příchodem DI se ale statické třídy odsouvají na vedlejší kolej a je potřeba pro oba typy použít a) 2 objekty nebo za b) jeden společný objekt. Oboje má své výhody a nevýhody.

Zajímali by mě tedy názory ostatních, co se vám osvědčilo v praxi a co ne. Obzvlášť pokud někdo řeší/il dynamické oprávnění ve spojení s modelama popřípadě zajímavé špeky/netriviality.

Filip Procházka

Pro začátek můžeš odstranit slovíčko static ze třídy, zaregistrovat ji do DI Containeru, opravit, co přestane fungovat a předávat si ji kam potřebuješ.

Na jeden typ budeš mít stále jednu třídu, ale bude to řádově čistější :)

Nox

Pokud už máš nějakou nadstavbu nad oběma případy (momentálně v jednom), tj. jsou to vyloženě objekty a není to třeba jen array (nebo jen čistý g/setter), pak bych to asi rozdělil (když se ptáš, tak předpokládám že sám nějak uvažuješ o úpravách)

Díky jednotnějšímu konceptu třídy pak IMHO budeš moct lépe použít předky atd.

V první fázi můžeš to co píše HosipLan

Editoval Nox (5. 2. 2012 18:43)

Šaman

Mně se na to co popisuješ osvědčily dva objekty – jeden reprezentuje entitu a druhý kolekci. Entita je jasná a kolekce umí řazení, hledání apod. Kolekce zároveň podporuje ArrayAccess pro jednotlivé položky.
Nevýhoda je v tom, že pokud si skutečně vytvoříš celou kolekci, tak je to dost paméťově náročné. Dá se to obejít tím, že kolekce funguje nad Dibi datasourcem a objekty se fetchují, s tím jsou zase spojené jiné problémy. Ale dva objekty si myslím že jsou čistější.

Tomáš Votruba

Možná ti dá něco inspirace jednoduchý model z Kuchařky.

Aleš

ad HosipLan odstranění static, jednoduchá třída: tak to mám v současný chvíli, ale nedoporučuju aby se někdo vydával podobnou cestou, model pak musí být schopný při konstrukci přijmout buď tabulku(pokud má reprezentovat kolekci) nebo řádek/ky (pokud reprezentuje entitu)

při oddělení statické třídy a objektu je hezky vidět co se stará o co, ale při jedno objektové implementaci se např array_access mění na noční můru, sumasumárum – je to napsatelné ale ne udržitelné

ad Nox, Šaman dva objekty: ač nerad (jsem rozmazlenej jednou třídou) asi použiju vámi nabízené řešení. Zavede se pár závislostí navíc, obzvlášť pro univerzální model a děsím se té správy paměti, ale bude to nutné (např pro použití IResource pro entitu)

ad Schmutzka jednoduchý model: to popisuje jenom magii metod, nicméně vracené záznamy jsou pořád nad notORM, takže jakákoli rozšíření (onDelete na entitě) nepřipadají v úvahu