Vzájemné vztahy objektů Article, ArticleMapper a ArticleRelation (pokus o DDD)

Trochu mi chybí informace, co má každá z těch tří tříd za odpovědnosti. Osobně bych to navrhl asi nějak takto na první dobrou.

DAO objekt by měl řešit veškerou komunikaci, která řeším objekty daného typu. Tedy asi to, co je v kódu jako Mapper.

Mapper by měl mít jen schopnost mapovat databázové záznamy do objektu a ne je načítat.

Relation a Article jsou samy o sobě zodpovědně za svoje načtení, ale na přesné mapování by se měly vždy zeptat Mapperu. Respektive Relation jde ještě dál a deleguje toto načítání na Article.

Nicméně otázkou také je, k jakému účelu chceš předchozí (resp. následující) článek. Pokud potřebuješ jen ID, tak bych si udělal přímo v DAO metodu s jednoduchým SELECTem přímo do databáze, případně ID předchozího (resp. následujícího) článku přidal přímo do třídy Article.

Čistě objektově bez jakéhokoli SQL by to mělo být (IMHO) tak, že Relation umí vrátit předchozí (resp. následující) článek. Pokud je tahle funkcionalita často potřeba, mohlo by to být rovnou jen v Article, ale objektová čistota by zase trochu klesla. Samozřejmě taková metoda by musela vracet instanci stejné třídy. Tak by se však měla načítat až v případě volání metody getPrevious(). Příklad kódu by asi pomohl:

// Čistě
$article = $articleDao->get($articleId); // ArticleRelation
$previousArticle = $article->getPrevious(); // ArticleRelation

// Méně tříd
$article = $articleDao->get($articleId); // Article
$previousArticle = $article->getPrevious(); // Article

Bohužel se nedá udělat dokonalý objektový návrh, který současně bude perfektně výkonný. Záleží na konkrétním projektu a preferencích, zda jít cestou více objektové čistoty nebo lepšího výkonu.

Rovnou k dotazům:

1. Ano, jedná se o kompozit. Přidané metody pro Relation jsou getNext() a getPrevious(). Pokud bychom se na to měli koukat jako v tvém příkladu s lidmi, byla by tato metoda v DAO. Je to také možné, ale takto postavený kompozit nám ale umožní projít (sice neefektivně z pohledu SQL) jakékoli množství předchozích (resp. následujících) článků. V případě, že by ta metoda byla v DAO bychom tuto závislost museli řešit dříve než v šabloně. Pokud by se tedy změnil výpis, museli bychom zasahovat i do Presenteru. Takto stačí udělat o jedno volání metody getPrevious() (resp. getNext()) více. V příkladu lidí je opět jednodušší se ptát přímo člověka, jaké má děti. A těch případně zase na jejich děti :-)
2. Mapper může být z mého pohledu použit dvěma způsoby. Může pouze obsahovat mapování názvů atributů třídy Article na názvy sloupců v databázi, které jsou do SQL dotazu dále seskládány dle potřeby. Druhou možností je, že obsahuje samotné SQL dotazy, které volá na konkrétní databázové vrstvě (aktualizoval jsem diagram). Druhá možnost se může při více dotazech hůře spravovat. V každém případě třída Article by podle mě měla mít na starost jen a pouze práci s atributy, volání metod na Mapperu a případně by měla implementovat metody, které nemají co do činění s databází. Jako příklad budiž metoda getUserFullName(), která vrací jméno i příjmení uživatele (autora článku), přičemž třída obsahuje jen atributy křestní jméno a příjmení. Další podobné „výpočetní“ metody si asi každý domyslí :-)

Na závěr musím souhlasit, že DAO je vlastně služba pro danou doménu. Z výše napsaného by mělo plynout, že pro data do databáze sahá Mapper, který je po načtení dat nastaví hodnoty atributům třídy Article podle mapování, které zná jen Mapper.

PS: Ještě mě napadá, že Mapper by klidně mohl jen nastavovat správné aliasy sloupečkům z databáze, aby si to Article po načtení správně rozestrkal po atributech. Mapper by se tak stal zdánlivě nepoužitý. Přesto ale zastávám výše uvedený postup, protože s ním má každá třída jednu zodpovědnost. Třída Article by totiž neměla mít zodpovědnost za načítání data a zároveň za jejich uchování v paměti, ukládání změn a případně další dopočty s nimi. Stačí když má zodpovědnost jen za uchování v paměti a paměťové operace s atributy.

V zásadě je to správně, podle mého. A souhlasím i s tím, že je to kanón na vrabce v případě, že chceš jen a pouze načítat články, případně jejich sousedy. Ovšem jakmile to začneš používat ve větší aplikaci, kde jednotlivé domény mohou jakkoli souviset, začne to být takhle jednodušší pro další správu. Zkrátka a dobře, pokud si budu dělat „blog“ s výpisem článků, které budu zadávat přímo do databáze, vystačím si s dibi nebo \Nette\Database bez dalších objektů kolem.

Dovolím si jen drobně upravit tvoji ukázku kódu:

class ArticleDAO
{
    private $articleMapper;

    public function __construct($articleMapper)
    {
        $this->articleMapper = $articleMapper;
    }

    public function get($id)
    {
        $article = new Article($this->articleMapper);
	$article->setId($id);
        $article->load();

        return $article;
    }
}

class Article
{
    private $articleMapper;

    // Atributy - ať už jednotlivě nebo v poli

    public function __construct($articleMapper)
    {
        $this->articleMapper = $articleMapper;
    }

    public function load()
    {
        // Tady načítám data z Mapperu a vkládám do atributů třídy
        // Např.:
        $this->articleMapper->load($this); // Díky Setterům naplní data, díky Getterům ví jaký řádek vybrat
    }

    // Settery a Gettery na atributy
}

$articleDao->get($articleId);

Article chce vždy nějaká data, i kdyby to mělo být prázdné pole. Navíc Mapper chce použít nejen při načítání, ale i při ukládání. Tudíž by měla mít každá instance referenci na instanci Mapperu. Navíc použitím DI pro DAO zajistíme, že v jednom systému načítáme z databáze (ať už je tam jakákoli knihovna) nebo klidně i ze souboru, případně webové služby.

Když se na to tak dívám, je to trochu podobné továrničkám :-)