předávání dat mezi modelem a aplikací
- BigCharlie
- Člen | 283
Ahoj,
snažím se trochu si pohrát se svou miniaplikací v Nette a při refactoringu jsem narazil na následující problém. Hledám cosi jako Best practice pro způsob přenášení dat mezi modelem a zbytkem aplikace. Hledal jsem i tady na fóru, kde jsem dohledal jedno nosné téma.
O co mi jde – model by měl pospojovat a zapouzdřit všechny logicky související záležitosti (alespoň tak jsem to pochopil). Navenek by měl poskytovat pouze pevná rozhraní. Když se podívám do examples v distribuci Nette nebo do výše uvedeného topicu, data pro přidání či pro úpravy se předávají v asociativním poli. Nevynáším tím logiku modelu z modelu ven? Chápu jednoduchost a eleganci, ale není to zároveň problém? Chápu to u jednoduché aplikace, ale použijete totéž u něčeho většího, kde očekáváte větší robustnost?
Pokud udělám pevné rozhraní, představuji si to u jedné funkce nějak takhle (vycházím z původního topicu, pomiňte reálnost příkladu):
function editBanner($id, $name, $filename)
{
$args = array(
'id' => $id,
'name' => $name,
'filename' => $filename,
);
return dibi::query('UPDATE [Banners] SET', $args);
}Rozhraní je pevně dané. Ale přibyla práce (volání metody z aplikace je „nabobtnalé“, opětovná práce s parametry, obzvlášť v případě větších tabulek). Může někdo objasnit výhody? Nebo odkázat na dobrý článek s příklady, který to objasní? Hledal jsem po internetu, ale marně. Nebo spíš blbě :-(
V tom vlákně phx zmiňuje mezivrstvu, která vrací objekty – nebyl by, prosím, k dispozici příklad, z kterého bych to pochopil?
A nemáte někdo v rukávu nějaké další Best practicies, týkající se předání dat, které by stály za úvahu? Ono by se to jistě šiklo i do připravované kuchařky Nette.
- phx
- Člen | 651
Osobne jsem tuto cestu davno zavrhl.
- slabsi vykon
- zbytecna prace s objekty navic
- slozitejsi udrzba
Sice to melo par vyhod, napr v budoucnosti pri zmenach v DB, ale za par let jsem tyto vyhody moc nevyuzil takze jsem tento navrh opustil.
Nedavno David publikoval DataSource, ktery mi prijde idelani (v soucasnosti pouzivam). Mam objekt (nazveme je X) ktery dedi od meho objektu Model (vpodstate vylepseny ArrayObject). V nem jsou metody na insert, update, delete a kompletni praci s daty. Nacitani z DB je reseno pomoci statickych metod, ktere vraceji MyDataSource (podedeny a vylepseny DataSource). Onen MyDataSource vraci pri nacteni radek, ktery je reprezentovany objektem X.
Toto reseni se mi zda idealni. Vykon supr:) Je to lazy. A Vytvoreni noveho objekut pro praci s dalsimi daty je jen otazka 1 objektu s onim verejnym rozhranim. A ne jako jsem to mel driv (DBModel = data v objektu, DBService = metody pro praci s databazi)
Pokud je zajem mohu ukazat obe dve metody.
- Honza Kuchař
- Člen | 1662
phx napsal(a):
Pokud je zajem mohu ukazat obe dve metody.
Taky se rád inspiruju. :)
Editoval honzakuchar (26. 4. 2009 17:44)
- phx
- Člen | 651
Takze jsme pro vas pripravil nefunkcni zdrojaky pro praci s tabulkou account.
Jsou tam 2 varianty:
OLD
- models – datove obejkty z reprezentujici tabulku
(pohled) v DB
- tables – jednotlive tabulky dediti od DBModel, dokaze se naplnit z asoc. pole, ma definovane atribury a do jsem pripradne dodelaval gettry pro ruzne formaty atributu.
- services – slozby pro komunikaci s DB prostrednictvim
DB objektu
- base – zakladni tridy (predkove) s obecnou zakladni funkcnosti, insert, update, delete, select, …
- SAccount – sprava tabulky account, uklada, nacita, upravuje data v DB, data se predavaji ve forme objektu (viz adresar models)
- – pomalé (hodně rezije okolo)
- – mnoho souboru kolem 1 tabulky, slozite vytvareni
- – bez podpory vice PK
- + podpora zmeny nazvu v DB (zmena transformArray)
NEW
- models
- Account – datovy objekt BEZ urcenych parametru, pouze urcene PK, umi se ulozit/upravit do DB, ma metody pro ziskani MyDataSource dane tabulky
- Model – predek s obecnymi metodami
- MyDataSource – upraveny DS s tim, ze muze vracet misto DibiRow objekt, ktery urcim (potomek Model)
- + podpora vice PK (neni dokonceno)
- + lazy
- + malo kodu → mala rezije
- + libi se mi:)