Hyperrow – vlastní row/selection třídy podle tabulky

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
filsedla
Člen | 101
+
+2
-

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
+
0
-

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)