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)