Model pro jeden záznam/skupinu záznamů
- Aleš
- Člen | 30
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
- Moderator | 4668
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
- Člen | 378
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
- Člen | 2635
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ší.
- Aleš
- Člen | 30
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