Jak správně psát modely / jak správně pracovat s daty?

wodCZ

Ahoj,
v Nette už jsem něco napsal, a vždy jsem si nějak poradil, ale nemám pocit, že to dělám správně.
V Quickstartu je o modelu pouze zmínka, s databází se dále pracuje jen v presenteru.

S NDB pracovat umím, a líbí se mi, jen mi chybí nastavení vlastní třídy pro záznam. Ale nechci kvůli tomu tahat Doctrine, i když je to bez pochyby užitečná knihovna. Chci se naučit psát modely s pomocí NDB. Samozřejmě, si ale nechám poradit od zkušenějších – pokud je na modely lepší něco jiného, sem s tím.

Popošťouchli by jste mě, prosím, jakým směrem se vydat?

Prozatím funguji nějak takto:
vytvořím v databázi (MySQL) strukturu. to mi nevadí, rád si to naklikám.
vytvořím BooksRepository (pochytil jsem v průběhu verzí, nějaká jednoduchá třída od F. Procházky, od které dědím). Tam si občas frknu nějakou metodu jako findActive, markAsUnread, apod.
Občas tam vykouzlím i nějaké obstrukce do jiných tabulek. Třeba do nějakých menších, nepodstatnějších/číselníkových tabulek, protože vytvářet nový repozitář, registrovat v configu, injectnout do presenteru a do modelu je prostě zdlouhavé, tak mi vznikají prasácké repository.
Občas volám update nad řádkem z databáze přímo v presenteru, občas na to mám metodu v repository.
No je to děs, není to konzistentní a je to špatně.

Prosím tedy o nějaké články, nebo ukázky, návrhové vzory, cokoliv, čeho bych se měl držet, aby práce s daty a celá jejich logika byla jednoduchá, čistá a nemělo to pasti, které bych leností obcházel.

K tomu/té Doctrine – příjde mi to obrovské, a nědokážu si představit, že by jsem dokázal vše používat správně a efektivně. Pokud máte nějaký článek/návod, který by se mi v mé situaci mohl hodit, budu vděčný, když se podělíte.

Díky.

thunderbuff

Obecný návod asi neexistuje, každý to dělá po svém a trochu jinak. Tady je v bodech, jak to dělám já. Neříkám, že je to zcela správné, ale zatím se mi to osvědčilo:

Repository

Repository pracují přímo s ndb a primárně s jednou tabulkou. Vyšší vrstvy aplikace k ndb nepřistupují.
Řeší (skoro) jen základní CRUD operace nad entitami
Každé pravidlo lze porušit, pokud vím, proč to dělám. Občas se v repozitáři krom CRUD najde nějaká jiná metoda – třeba hromadné updaty kvůli omezení počtu db dotazů. Repository taky vůbec nemusí pracovat s jednou tabulkou, klidně ať čte a zapisuje data z více tabulek – jen to musí mít rozumný důvod, nesmí se to dít jen z pohodlnosti.

Fasády

Nad repositáři stavím fasády (M:N). Je to mezivrstva mezi repozitářem a zbytkem aplikace. Vše, co nemusí nutně sahat přímo na NDB přesouvám do fasád. Jednak do nich deleguji spoustu metod z repozitáře a zpřehledňuji tak kód, druhak krásně řeší cyklické závislosti (jeden repozitář potřebuje druhý a naopak). Prostě oba repozitáře předám jako závislosti fasádě a problém pak řeším v ní. Mimo repozitáře mohou mít fasády mezi závislostmi libovolné jiné služby.
Pokud zpracovávám formulář, jako závislost mu nepředávám repozitář, ale obslužnou fasádu. Aktualizace entit se děje ve fasádě a je tak pěkně oddělena od vlastního formuláře.
Pokud potřebuji updatovat něco přímo z presenteru, předám mu jako závislost fasádu a zavolám metodu ve fasádě.

<?php

// místo této hrůzy v presenteru nebo ve formuláři....
$article = $this->repository->find($id);

if (!$article || $article->published === 1) {
	return false;
}
$article->published = 1;
$article->publishDate = new DateTime();

$this->repository->update($article);




// ... přesunu logiku do fasády, tu pak volám a ona si vše udělá v pozadí.
//     Zápis je jasný, přehledný a znovupoužitelný

$this->articleFacade->publish($id);


?>

Editoval thunderbuff (20. 8. 2014 17:23)

Šaman

Velmi jednoduchý model bez fasád mám tady.

wodCZ

Šaman: Ano, takto nějak to u mě vypadá na začátku projektu. Dokud nepřidám M:N, pak to začínám prasit.

thunderbuff: Díky za posunutí meze znalostí o fasády. To pravděpodobně řeší to prasení M:N v repository. Věřím, že to funguje, ale pořád z toho nemám takový ten Aha! pocit.

Dochází mi, že mým hlavním problémem je neznalost patternů.

Za další se pokouším využít NDB na co není stavěné.

Dotaz ale stále platí. Pokud někdo poradí, jak se správně píšou modely pro netriviální aplikace, nějaký pattern, nebo knihovnu, článek, ukázečku, … – budu vděčný a koupím mu pivo.

Editoval Inkode (20. 8. 2014 20:37)

Šaman

Já používám ORM LeanMapper. Jede nad Dibi, ale na objektové straně je stejně poměně jedno, na jakém jede enginu. Ale existují i nějaká ORM pro NDb. Možná to je co hledáš – není to tak velké, jako Doctrine a přitom to umí vytvářet plnohodnotné entity a zrovna na ty m:n a ostatní běžné vazby mají často připravené metody.

Editoval Šaman (20. 8. 2014 22:28)