Je správné rozšířit model (Table\Selection) o další metody?

mkoubik napsal(a):

Model neznamená jedna tabulka v db = jedna třída, obvykle je to celá vrstva aplikace o jejímž návrhu stojí za to se trochu víc zamyslet.

Já si nemyslím, že db = model. A snad jsem to ani nenapsal. Poznámku o zamyšlení vnímám trochu ofenzivně. Snad to ale bylo myšleno dobře = rychlá klávesnice ;)

Prostě si na to vytvoř další službu (třídu dědící klidně jen \Nette\Object) a pokud potřebuješ při tom výpočtu pracovat i s databází, tak si tam injektni příslušnou Table\Selection.

Jakože bych si založit „prázdnou“ službu Helpers například. A volal metody, kterým bych předával co potřebují? Je na to služba vhodná?

Konkrétně mám 4 funkce.

• jedna dělá nějaké operace nad daty jedné databáze a pak je zapisuje do jiné databáze.
• druhá počítá nějakou hodnotu z různých dat
• další generuje fakturu z různých dat
• čtvrtá se připojuje k mail serveru a transformuje maily a zapisuje do db

Tzn. udělat z nich 4 třídy s jednou metodou, přičemž konstruktoru předám modely a metodě jen doplňující parametry, které konstruktoru kvůli dynamické povaze dát nemůžu? Ona asi rozumnější cesta není, pokud nechci prasit, že?

Ještě doplňující otázka, abychom odpověděli na otázku v titulku. Je správné strkat rozšířující metody do modelu Selection?

Např.

class Pecka extends Selection
{
    public function __construct(\Nette\Database\Connection $connection)
    {
        parent::__construct('pecka', $connection);
    }

    public function getHumanReadable($property)
    {
        switch($property) {
            case 'svestka': $property = 'Švestičky ze zahrádky'; break;
            case 'jabko': $property = 'Shnilé jabko'; break;
        }
        return $property;
    }
}

Editoval patriksima (11. 10. 2012 17:21)

enumag napsal(a):

TL;DR

Dávat takové metody do Selection mi připadá jako velmi špatný nápad. Pro tyto účely mám raději vlastní třídu reprezentující tabulku. Selection nereprezentuje tabulku, ale množinu řádků.

https://github.com/fabik/database

Mě se to taky moc nezdá, ale neumím říct proč. Můžeš to více rozvést?

Díky moc! Vyřešeno.

neviem ci poznas https://github.com/fabik/database ale je to zatial (moj nazor) najlepsia nadstavba nad NDB, nie len ze rozsiruje ‚selection‘ ale dokonca mas vlastny active row

@HosipLan ako som pisal ‚nadstavba‘, neviem co presne myslis tym business

achtan napsal(a):

neviem ci poznas https://github.com/fabik/database ale je to zatial (moj nazor) najlepsia nadstavba nad NDB, nie len ze rozsiruje ‚selection‘ ale dokonca mas vlastny active row

Nette\Database má v tuto chvíli nevhodný návrh závislostí, objekty reflection a cache u sebe drží Connection, ačkoliv je používají jiné třídy. Jakmile se tohle nějakým refactoringem vyřeší, fabik/database se (bohužel) rozbije. Což je daň za dědění tříd.

Říkám jen tolik, že vytvářet potomky tříd, které k tomu nejsou explicitně určené, s sebou nese značné riziko. Používej si co chceš.

Já bych to s těmi problémy s refactoringem závislostí neviděl tak černě. Prostě přidám do ModelManageru nové gettery, pak se trochu upraví mechanismus vyrábění Selection, předávání závislostí rodičovské třídě a možná, že i vyrábění ActiveRow.

Z pohledu uživatele knihovny by pak mělo stačit jen aktualizovat na novou verzi knihovny kompatibilní s novou verzí frameworku. Pravděpodobně nebude muset ani sáhnout do kódu aplikace a díky autowiringu snad ani do config.neon.

Proto jsem taky pro refactoring!