Lean Mapper – EntityFactory RFC

Za mě palec nahoru. Jen bude potřeba trocha edukační činnosti, aby někdo nezkoušel do entity cpát věci, které do ní evidentně nepatří. Ale zatím u mě LM překonal očekávání :)

<offtopic>jsem slavný</offtopic>

Šaman napsal(a):

Nemá cenu tu argumentovat pro a proti – LM, nebo NDb, nebo NotORM, nebo Dibi, nebo Doctrine2.
Pro mě je důležité, že se mi LM používá dobře a stále má rezervy v tom, co bych mohl udělat, kdybych potřeboval nějakou optimalizaci.

Klíčové bude dotáhnout dokumentaci, spoustu možností jsem zjistil až z videa. A máš někde ukázku toho QueryObjectu? I podle komentů u ukázkové aplikace bych ho měl co nejdříve nasadit.

https://github.com/…er/app/Model

@llook: Díky za samé dobré přípomínky.

Ad předávání EntityFactory) Pozor, ten parametr v Repository je povinný, nelze jej zapomenout. Neplatí, že by se v případě nepředání EntityFactory automaticky použila DefaultEntityFactory.

Vím, že čistě teoreticky lze každému repositáři předat jinou EntityFactory, ale myslím si, že tenhle omyl snad nemůže nikdo udělat ani v dobré víře. Stejně to funguje i s mapperem, který se předává v podstatě identicky. Také lze čistě teoreticky různým repositářům předat různé mappery, ale nedokážu si představit, jak by se tohle někomu svéprávnému omylem povedlo. Ale možná se pletu?

Ad „hlavní objekt“: To je právě otázka. Už jsem nad tím také uvažoval – takový objekt by mohl poskytovat Connection, IMapper a IEntityFactory. Předávání by pak byla jedna báseň. Jenomže mně na tomhle vadí hned několik věcí:

1. Netvrdím, že by to byl nějaký God object, on by jen zpřístupňoval zapouzdřené služby, ale cítím v tom jistý nádech… jekéhosi service locatoru, viz dále.
2. Skrývá to závislosti. Když vím, že Repository je závislé na Connection, IMapper a IEntityFactory, vím vše. Dokonce si dokážu snadno domyslet, co k čemu potřebuje – Connection k načítání dat z databáze, IMapper pro detaily O/R mapování a IEntityFactory pro vyrábění instancí entit. Zatímco když vím, že závisí na nějakém LeanMapper\Manager nebo na něčem podobném, musím zkoumat kód, abych se dozvěděl, co Repository skutečně potřebuje.

Mně osobně třeba EntityManager z Doctrine až tak neoslnil… Jako spousta jiných managerů. Skoro mi přijde, že jakmile název třídy obsahuje slovo manager, tak už zavání. :)

3. Nezabrání to vzniku nekonzistence napříč mappery, továrnami na entity… Když budu chtít, stejně do repository „A“ předám jiný LeanMapper\Manager (rozuměj s jiným obsahem) než do repository „B“. Otázkou samozřejmě je, proč bych to dělal. Tady myslím k vysvětlení nestačí ani ten dobrý úmysl. :)

Proto se mi prostě současné předávání závislostí líbí víc (je plně v duchu DI). Ale třeba se ještě někdo ozve a převáží mé argumenty, jsem naprosto otevřen diskuzi.

Ad Query Object: Máš naprostou pravdu, vím, že nejsem s Fowlerem kompatibilní (vlastně už jsem to tu na fóru někde i psal). Proto ten svůj Query zatím nikde až ten neventiluji, protože jej nechávám dozrát. Název Criteria by asi lépe vystihoval podstatu věci.

Aby to byl Query Object ala Fowler, musel by se sám umět přeložit do… čehosi. Zde asi do sekvence volání nad DibiFluent. To by neměl být až takový problém, ale řešení, kdy ten objekt nese jenom objektovou reprezentaci nějakých restrikcí, mi přijde „stravitelnější“. Je to jako SQL samotné: já píšu SQL kód, který interpretuje databáze. Zde nastavuji nějaká kritéria, která interpretuje repositář.

Jaké jsou přesně ty důvody, proč je tohle špatně? Kdy se s tímhle dá narazit? Tohle téma mě vážně zajímá, předem díky za rozvinutí diskuze. :)

Proč je to špatně:

• Repository získává novou odpovědnost, interpretaci kritérií. Když budeš chtít přidat třeba range restriction, tak budeš měnit jednak tu třídu Query, ale i Repository. Kdybych to dělal já, tak bych si přitom připadal, jako kdybych do jedné třídy dával jenom vlastnosti a do druhé jenom metody pro práci nad nimi.
• Vždycky budou dotazy, které budeš chtít položit, ale ten interpreter na ně bude krátký. Jak na ně? Budeš kombinovat přístup přes criteria objekty s findByBlabla metodami?
• A potom bych měl problém s univerzálními metodami typu restrict('column', 'value'), protože znemožňují statickou analýzu a ztěžují refaktoring, otevírají prostor pro překlepy atd. Ale to se netýká principu „repository jako query object“, ale spíš obecných query objektů vůbec. K tomu se ještě vrátím.

Query Object, jak ho představuje Fowler, je objekt, který umí na základě nějakého svého nastavení vygenerovat dotaz. Jestli to nastavení představují nějaké high-level Criteria objekty, jako v tom jeho diagramu, nebo třeba obyčejné PHP array, na tom tak dalece nesejde. Různé query objekty to můžou mít různě složité, podle potřeby.

Mě dává smysl, aby repository pouze hloupě vracelo entity na základě SQL dotazu. Sestavení toho SQL dotazu, to ať dělá někdo jiný, query object:

public function find(IQuery $query)
{
    return $this->createEntities(
        $this->connection->query(
            $query->createQuery($this->mapper)
        )
    );
}

Může existovat i nějaký obecný query objekt pro prototypování. To by byl třeba ten tvůj Query, kdybys mu přidal metodu createQuery().

Obecný query objekt má ale jednu velkou nevýhodu – nemá jasně dané rozhranní. Není zřejmé, že umí restrict('foo'), ale neumí restrict('bar'), to zjistíš až za běhu. Taky to ztěžuje refaktoring. Třeba budeš chtít smazat nepotřebný sloupec, ale jak zjistíš, že je opravdu nepotřebný? Že v nějakém zapadlém zákoutí aplikace podle něj něco nefiltruješ/neřadíš?

Pokud vím, tak tím si kdysi prošlo i PetrP/Orm – úplně magické metody findByColumn byly ze začátku strašně pohodlné, časem se ale stávaly přítěží a kvůli tomu se zavedla povinnost každou takovou metodu přidat přes anotaci, jinak se k ní __call nezná.

Já jsem příznivcem toho, čemu říkám konkrétní query objekt. Typicky u jednoduchých aplikací bys měl jednu query třídu ke každému repository. Používalo by se to nějak takto:

$lastTenAuthorsArticles = $articles->find(
    new Query\Articles\All()
        ->restrictAuthor($author)
        ->orderDescByCreatedAt()
        ->limit(10)
);

Jak by aplikace rostla, tak by se vyčleňovaly opakující se dotazy do samostatných tříd, např.:

$lastTenAuthorsArticles = $articles->find(
    new Query\Articles\LastByAuthor($author)
);

...
namespace Query\Articles {
    class LastByAuthor extends All
    {
        public function __construct(Author $author, $limit = 10)
        {
            parent::__construct()
                ->restrictAuthor($author)
                ->orderDescByCreatedAt()
                ->limit($limit);
        }
    }
}

Hlavní rozdíl je ten, že tohle má API. Můžeš v IDE zjistit, jestli se nějaká restrikce skutečně používá, můžeš snáz přejmenovávat, máš code-completion apod.

Takové základní věci, jako omezení podle sloupce nebo řazení by mohly být vyčleněné do nějakého společného předka a do konkrétních query tříd by se přidávaly nejsnáz asi anotacemi:

/**
 * @method static restrictAuthor(Author $author)
 * @method static restrictCategory($category)
 * @method static orderDescByCreatedAt()
 * atd...
 */
class Articles extends Query
{
}

Takže ani toho psaní by nebylo nějak moc. Během parsování těch anotací by se navíc dalo kontrolovat, že nenabízí filtrování podle sloupce, který neexistuje.

To 1% dotazů, které je nutné psát ručně, by se zapouzdřovalo nějak takto (už nikdy bys nemusel na repository přidávat žádnou findByNěco() metodu):

class SomethingSpecial implements IQuery
{
    public function createQuery(IMapper $mapper)
    {
        return array('SELECT * FROM %n', 'table', ' atd...');
    }
}

Tak tohle je ve stručnosti :-) moje představa o query objektech.

1. Query není na repository nijak závislé.
2. Může to vracet cokoli, s čím si poradí DibiConnection::query(), což Fluent splňuje.

Já moc velký příznivec DibiFluent nejsem, radši píšu SQL přímo. Složitější dotazy píšu v Database Console, kde je hned vyzkouším a odladím. Přepisovat je pak z SQL do DibiFluent je práce navíc.

Napadá mě, že by query objekt kromě mapperu dostával ještě ten základní DibiFluent. Tím by se trochu omezily možnosti query objektů, ale je fakt, že většinu případů užití by to zjednodušilo. Nějaké konflikty při kombinaci více query nebo filtrů dohromady (ambiguous column apod.) by snad nastávaly málokdy:

interface IQuery
{
    function createQuery(DibiFluent $baseQuery, Mapper $mapper);
}

Ale co s těmi případy, kdy si fakt chci celý dotaz napsat ručně? Takový query objekt by mohl ignorovat parametr $baseQuery, ale to by bylo dost matoucí. Nebo by místo názvu tabulky mohl použít poddotaz ('FROM (%sql) t', $baseQuery), to je zase trochu prasácký.

Ještě nad tím zkusím popřemýšlet.