LeanMapper – kompletní modelová vrstva a transakce

Ahoj,

jak by se Ti líbilo cca takovéto řešení Tebou uvedeného příkladu?

/**
 * Simple proxy to transactions
 */
class Transaction
{

    /** @var LeanMapper\Connection */
    private $connection;


    /**
     * @param Connection $connection
     */
    public function __construct(Connection $connection)
    {
        $this->connection = $connection;
    }

    /**
     * @param string|null $savepoint
     */
    public function begin($savepoint = null)
    {
        $this->connection->begin($savepoint);
    }

    /**
     * @param string|null $savepoint
     */
    public function commit($savepoint = null)
    {
        $this->connection->commit($savepoint);
    }

    /**
     * @param string|null $savepoint
     */
    public function rollback($savepoint = null)
    {
        $this->connection->rollback($savepoint);
    }

}

class Users
{

    /** @var Transaction */
    private $transaction;

    /** @var UserRepository */
    private $userRepository;

    /** @var UserRoleRepository */
    private $userRoleRepository;


    /**
     * @param Transaction $transaction
     * @param UserRepository $userRepository
     * @param UserRoleRepository $userRoleRepository
     */
    public function __construct(Transaction $transaction, UserRepository $userRepository, UserRoleRepository $userRoleRepository)
    {
        $this->transaction = $transaction;
        $this->userRepository = $userRepository;
        $this->userRoleRepository = $userRoleRepository;
    }

    /**
     * @param User $user
     * @param UserRole[] $userRoles
     */
    public function createUser(User $user, array $userRoles = array())
    {
        $this->transaction->begin();
        try {
            foreach ($userRoles as $userRole) {
                $this->userRoleRepository->persist($userRole);
            }
            $user->addToRoles($userRoles);
            $this->userRepository->persist($user);
            $this->transaction->commit();
        } catch (\Exception $e) {
            $this->transaction->rollback();
            throw $e;
        }
    }

}

Editoval Tharos (31. 12. 2013 10:55)

Filip111 napsal(a):

Třída Transaction se mi líbí – nechtěl jsem používat v presenteru connection, takže tohle je asi ok.
Nemusim mít výčitky, když to použiju v repository nebo i presenteru, protože už je to zapouzdřený.

Třída User je přesně to nad čím si lámu hlavu, jestli používat či nikoliv. Dokud jsem nepoužíval ORM tak jsem podobný objekty používal. S tím jak jsem ale začal používat ORM, tak jsem začal používat entity.

S čím pak pracuješ např. v presenteru/šabloně? S entitou User nebo s objektem User, který jsi uvedl?
(nebo je entita User a objekt User to samé, jen jsi ořezal deklarace properties?)
Jakou zodpovědnost by měla mít třída User? Jen uložení celého pavouka entit souvisejících s uživatelem nebo i jejich čtení a předávání dál?

Občas mi tam právě takhle mezivrstva chybí, ale nevim jestli to zapouzdření nebude už moc přehnaný.
Entita, Repository, Objekt (např. User), Fasáda (pracující někdy s entitou někdy s objektem User) (?)

Vrstvu s fasádou bych chtěl ponechat, protože mi přijde ideální právě na nějaký činnosti, které už nemusí být v transakci a které nějak souvisí s např. vytvořením uživatele. Tedy právě zaslání mailů, případně práci napříč dalšími službami.

Ty to takhle používáš nebo jsi jen vytvořil nějaký příklad?

Díky

Já osobně bych vnitřek třídy Users měl přímo v UserFacade. Nevidím důvod to mít takhle mimo, přeci jen od toho je tu ta fasada aby to cele obalila a v prezenteru si po nějaké akci vyvolal createUser($name, $username,…) a dostal si treba jen true|false jako odpověď pro prezenter.

@Filip111:

Třída Transaction se mi líbí – nechtěl jsem používat v presenteru connection, takže tohle je asi ok.
Nemusim mít výčitky, když to použiju v repository nebo i presenteru, protože už je to zapouzdřený.

Je to klasická proxy třída. Takové se obzvláště hodí při práci s různými god-objekty. :)

Třída User je přesně to nad čím si lámu hlavu, jestli používat či nikoliv. Dokud jsem nepoužíval ORM tak jsem podobný objekty používal. S tím jak jsem ale začal používat ORM, tak jsem začal používat entity.

Pozor, to není User, ale Users. :) To je ta fasáda. Samozřejmě by v reálu obsahovala i další metody podle potřeby, já jsem jen chtěl být ve své ukázce stručný a jít k jádru věci. Já do názvu „fasádních“ tříd slovo Facade nedávám, pojmenovávám je ala Users, Orders, Books atp.

S čím pak pracuješ např. v presenteru/šabloně? S entitou User nebo s objektem User, který jsi uvedl?
(nebo je entita User a objekt User to samé, jen jsi ořezal deklarace properties?)
Jakou zodpovědnost by měla mít třída User? Jen uložení celého pavouka entit souvisejících s uživatelem nebo i jejich čtení a předávání dál?

Přestal jsem používat Nette presentery :–P (bylo by to na delší povídání), ale v té části aplikace, která má na starosti to, k čemu se běžně používají presentery, pracuji s entitami a standardně s těmi „fasádními“ třídami. Je-li aplikace jednoduchá (anebo se mi doménovou logiku podaří elegantně umístit přímo do entit), tu fasádní vrstvu vynechávám a pracuji přímo s konkrétními repositáři. Pokud bych pak potřeboval v takové aplikaci bez fasádní vrstvy vyřešit to, co čem jsi psal, na ten konkrétní úkon bych si nějakou „servisní“ třídu vytvořil. Mé názvosloví (servisní vs. fasádní…) je kompatibilní s tímto článkem.

Ty to takhle používáš nebo jsi jen vytvořil nějaký příklad?

Já se hodně rozhoduji podle konkrétní aplikace. Velmi jednoduché moc neprožívám a pracuji v „presenterech“ přímo s repositáři. Doménovou logiku se vždy snažím mít co nejvíc v entitách (v duchu DDD), model se snažím mít co nejméně „anémický“. To, co se mi ale do entit v takové aplikace nepodaří vměstnat (nebo vhodným způsobem do repositářů), řeším pomocí berliček v podobě servisních tříd.

Je-li aplikace trochu košatější, snažím se zavést plnohodnotnou fasádní vrstvu, jejíž třídy vytvářejí API modelu. Pak už samozřejmě v „presenterech“ nepracuji přímo s repositáři, ale s těmi fasádními třídami. Používám konkrétní repositáře (na rozdíl od například Kdyby\Doctrine) a query objety (hodně podobně, jako Filip v Kdyby\Doctrine, jen s tím logickým rozdílem, že mé query objekty se překládají do sekvence volání nad instancí Fluent).

Proxy třídu pro transakce používám.

Editoval Tharos (2. 1. 2014 9:50)

Ohledně těch presenterů jsem se chtěl taky zeptat, ale pak jsem to neudělal, protože naprosto klíčové k životaschopnosti LM je vytvořit dokumentaci, což může udělat jen Tharos. Takže se zeptám až potom :)

Lehce offtopic: @Tharosi plánuješ přijít na lednovou posobotu? Vypadá to, že bude zajímavá. A ve volném čase bychom mohli nad pivem probrat pár dotazů na LM.

@Šaman, Filip111:

https://forum.nette.org/…ha-25-1-2014#…