Hyperrow – vlastní row/selection třídy podle tabulky
- filsedla
- Člen | 101
Ahoj, chtěl bych se podělit o svoji knihovnu pro vylepšení práce s Nette database.
Myšlenka vznikla, když jsem přibližně před rokem a půl v projektu kvůli pár vlastním metodám musel psát další vrstvu entit, do kterých se z ActiveRow kopírovala data. Napadlo mě, že by bylo fajn, kdybych mohl celou vrstvu entit vypustit, protože ve většině případů se pouze kopírovaly properties a nic dalšího se s nimi nedělalo, a přidávat vlastní metody přímo do ActiveRow.
Pamatuji si, že mě inspirovaly ndab, fabik/database, ale chtěl jsem to udělat po svém, aby to nebylo ORM a šlo to opravdu použít. A tak jsem začal psát wrappery.
Základní myšlenkou je, že používám Nette database skrz obalující třídy úplně stejně jako dřív. Akorát místo Selection a ActiveRow dostávám různé třídy závislé na tom, z které tabulky dotaz pochází.
Ty třídy musím dodat (mohou být také generované). Pak si mohu např. do UserRow přidat metodu
public function getFormattedName()
{
return "{$this->name} {$this->surname}";
}
Tím si zkrátím kód v šabloně: $user->formattedName.
Velkou výhodou je našeptávání sloupců podle anotací (ručně přidaných nebo generovaných).
Specifické jsou i třídy selection. Např. ve výpisu článků si do ArticleSelection přidám metodu
public function withVisible()
{
return $this->where('article.state', ArticleRow::STATE_ACTIVE)
->where('article.deleted', FALSE)
->where('article.expireAt IS NULL OR article.expireAt >= ?', new DateTime())
...
}
Na rozdíl od $articleRepository->findVisible()
má metoda
výhodu, že ji mohu použít i ve volání
$author->relatedArticle->withVisible()
apod.
Nemám žádné plány pro další vývoj, naopak bych rád, aby to zůstalo jednoduché, jak to je. V současném stavu jsem knihovnu použil už na jednom projektu a hodně to zpříjemnilo práci.
Editoval filsedla (29. 6. 2017 13:18)
- GEpic
- Člen | 566
Vytvořili jsme něco velice podobného pro modely, kde stačí pro vytvoření funkční tabulky v databázi tento zápis:
class PageModel extends BaseModel
{
}
a podle namespace automaticky vydedukujeme jméno modelu a tabulky, v tomto
případě tedy content_page
a o víc se člověk starat nemusí,
pokud člověk něco v tomto modelu chce, dopíše si vlastní metody. Ale
BaseModel
již mnoho funkcí obsahuje.
Popř stačí použít traitu:
class PageModel extends BaseModel
{
use CachedModel;
}
A opět se navíc celý model cachuje a podle práce s modelem data invalidují – a opět podle modulu / jména třídy se dedukuje jméno pro filestorage kvůli konfliktům.
Editoval GEpic (16. 7. 2016 21:54)