Lean Mapper – tenké ORM nad dibi

Prosim o ukazku jak se pomoci te obalky nad dibi udela toto:

AuthorRepository vrati vsechny autory, kteri spatne oznacili svoje knihy tagy, tzn. vrati takove autory, jejichz 1..n knih ma mene nez 2 tagy. Díky :)

Ad dokumentace, ano ano, je to piplacka, je pekne ze sis pohral :) jeste jdu mkrnout na kod knihovny.

@hrach: To je víceméně taková písemka z SQL :).

<?php

namespace Model\Repository;

class AuthorRepository extends \LeanMapper\Repository
{

    public function findAllIncorrect()
    {
        return $this->createEntities(
            $this->connection->select(......) // zde takové autory vytáhneme normálně pomocí SQL
        );
    }

}
?>

Mám teď možnost být u PC asi už jen dvě minuty, ale večer ten SQL dotaz doplním.

O něco zajímavější by bylo, kdybychom chtěli takovouto kolekci špatných autorů získat třeba z nějaké jiné entity (zkrátka aby existovalo něco jako $institute->incorrectAuthors). I toho je v Lean Mapperu jednoduché docílit – slouží k tomu filtry, které jako jediné teď ještě nejsou zdokumentované…

Večer sem asi napíšu ukázku i tohohle, protože si myslím, že to je v Lean Mapperu mocná věc… Pomocí těch filtrů se dá nejen limitovat a řadit výsledek, ale umožňují například namapovat entitu rozprostřenou přes více tabulek, provádět dost specifické restrikce (třeba takovou, o jaké jsi psal) atp.

Dokumentace k tomu zatím není z toho důvodu, že zatím teprve ladím, za jaký konec dokumentaci téhle části uchopit a nejlépe vše vysvětlit.

Editoval Tharos (4. 6. 2013 23:19)

V Lean Mapperu strikně platí, že entity neumějí samy sebe persistovat – potřebují k tomu repositáře. V následující ukázce se uloží pozměněný název knihy, ale už ne pozměněný název autora:

$book = $bookRepository->find(1);
$book->name = 'New book name';
$author = $book->author;
$author->name = 'New author name';
$bookRepository->persist($author); // ???

Nemělo by tam být spíše $bookRepository->persist($book); nebo si mám poposednout a přečíst si to celé ještě jednou?? :)

Diky, samozrejme neslo presne o ten kod, jen spis o ukazku prace se slozitejsimi vazbami.

Pěkný – nikdy jsem si pořádně nezvykl na NDB, takže ORM nad dibi je fajn.

Mám pár otázek:

1. Lze pomocí anotací nadefinovat jiný název DB tabulky nebo sloupce?

Např. abch měl entitu OrderDetail ale db tabulku order_detail + analogicky pro sloupce, abych mohl mít sloupec name_first ale vlastnost entity NameFirst?
(zatím jsem si ničeho podobnýho v kódu ani dokumentaci nevšiml a dost by se mi to hodilo)

2. Už dlouho se snažím vyřešit problém s výcejazyčnými tabulkami, moje představa je mít dvě tabulky, např.

pages (id, status, date_created)
pages_translation (page_id, lang, text)
ale mít jen jednu entitu se kterou budu pracovat, tedy Pages s prvky id, status, date_created, text (případně lang).

Dalo by se toho docílit pomocí filtru? Pro čtení asi ano, ale potřeboval bych to i pro zápis s tím, že nastavení aktuálního jazyka by bylo nějak předáno filtru/entitě nebo by bylo rovnou součástí entity.

(s tou vícejazyčností se peru už hodně dlouho a zatím jsem to nedokázal uspokojivě vyřešit – Doctrine se mi líbí, ale Gedmo mi nesedí a spravovat vícejazyčný entity jen pomocí vazem je neskutečná práce. Ani nemůžu data jednoduše předat do formuláře).

Díky.

@Jan Tvrdík: Díky za kladné zhodnocení. :)

Podporu pro enum přidám rád. Přiznám se, že sám typ enum v databázích příliš nepoužívám, a tak si chci dobře rozmyslet API a pak bych sem stejně asi ještě dal nějaké RFC… Píšu si to do roadmap do řady 1.4.

Rád bych v horizontu několika dní dal roadmap na web (a spolu s ním i changelog). Do verze 1.4 mám mimo jiné na programu usnadnění persistence jednoduchých M:N vazeb, aby fungovalo následující:

$book->addTag($tag1);
$book->removeTag($tag2);
$bookRepository->persist($book);

Samozřejmě s tím, aby se tagy insertovaly a mazaly inteligentně (tj. nikoliv, aby se vymazaly všechny staré a do db nasypaly nové a podobné ošklivosti…).

Až bude ten roadmap připravený, dám sem avízo.

@Filip111: Oba problémy by měly být už ve verzi 1.3 řešitelné. Sám si ale pohraji s optimálním řešením, tj. takovým, aby ses neupsal. To je asi největší záludnost… Nedodržení konvencí v Lean Mapperu v první řadě znamená psaní navíc a často má více řešení.

Stay tunned, rád si s tím pohraju a pošlu sem resumé. :)

@uestla: četl jsem – repository jsem asi přeskočil, řešení jsem čekal v entitě pomocí anotace
Tharos: díky, těším se

@Filip111: Tak snad Tě potěším – oba Tvé problémy mají v Lean Mapperu vcelku přímočaré řešení. :)

Aby sis nemusel překopírovávat kódy tady z fóra, připravil jsem Ti balíček s řešením ke stažení (používá SQLite databázi, která je jeho součástí, takže fakt stačí rozbalit a spustit).

Dám sem jen schéma databáze, ke kterému se můj text tady bude vztahovat:

Na úvod už snad jen upozorním, že jsem pro usnadnění řešení prvního problému kód Lean Mapperu lehce rozšířil, takže co teď budu psát platí pro poslední commit v develop branchi na GitHubu (přičemž z této branche se zanedlouho vyklube verze 1.4.0).

Definice jiného názvu tabulky nebo sloupce

Jak jsem již naznačil, v Lean Mapperu 1.3.0 lze snadno upravit názvy sloupců a tabulek souvisejících s vazbami mezi entitami (takové ty m:hasMany(sloupce a tabulky) příznaky). Ty se definují v entitách. Upozorňuji, že entita neví, do jaké tabulky ona sama patří a je to v pořádku – na nic to nepotřebuje vědět. Lean Mapper vychází z Data mapper vzoru a v něm entity o žádných tabulkách vůbec nic neví. Jediné odchýlení od Data mapper vzoru spočívá v tom, že entita si sama dokáže načíst související entity. A k tomu potřebuje vědět, kam se pro ně do databáze podívat.

Tabulku a třídu entity lze doladit v anotaci nad repositářem, protože to, do jaké tabulky pro entitu sáhnout a co za entitu vlastně vytvořit, je zodpovědnost repositáře. To jen tak na úvod a jako reakce na: repository jsem asi přeskočil, řešení jsem čekal v entitě pomocí anotace.

Nicméně pro namapování ostatních sloupců jsem přidal podporu v develop větvi. Ono by to ve verzi 1.3.0 šlo, ale položky by se musely definovat skrze metody a s tím je o řád více psaní…

Tvé zadání (které jsem si dovolil ještě trochu rozšířit, viz dále) lze vyřešit následovně:

<?php

namespace Model\Entity;

/**
* @property int $id
* @property Product[] $products m:hasMany(order_detail_id:order_entry:product_id)
* @property string $firstName (name_first)
* @property string $lastName (name_last)
*/
class OrderDetail extends \LeanMapper\Entity
{
}

/**
* @property int $id
* @property string $productName (product_name)
*/
class Product extends \LeanMapper\Entity
{
}
?>

<?php

namespace Model\Repository;

/**
 * @table order_detail
 */
class OrderDetailRepository extends Repository
{
}
?>

Domyslel jsem si ještě entitu Product a vazební tabulku (schválně pojmenované dost nekonvenčně), abych to trochu okořenil a ukázal, jak se mapují sloupce v položkách reprezentujících vazbu. Abstraktní třída Model\Repository odpovídá té v quick startu.

Pak lze provádět následující operace:

$orderDetails = $orderDetailRepository->findAll();

foreach ($orderDetails as $orderDetail) {
    write('Jméno: ' . $orderDetail->firstName);
    write('Příjení: ' . $orderDetail->lastName);

    write('Objednané položky:');
    foreach ($orderDetail->products as $product) {
        write($product->productName, 3);
    }

    separate();
}

Řešení tabulky s překlady

Vše, co potřebuješ, řeší následující třídy:

<?php

namespace Model\Entity;

/**
* @property int $id
* @property string $dateCreated (date_created)
* @property string $status
* @property string $lang
* @property string $text
*/
class Page extends \LeanMapper\Entity
{
}
?>

<?php

namespace Model\Filter;

use DibiFluent;

class PageFilter
{

    public static function joinTranslation(DibiFluent $statement, $lang)
    {
        $statement->leftJoin('page_translation')
            ->on('[page_translation.page_id] = [page.id]')
            ->where('[lang] = %s', $lang);
    }

}
?>

A trochu upovídanější (ale principiálně jednoduché) repository:

<?php

namespace Model\Repository;

use LeanMapper\Entity;
use Model\Filter\PageFilter;

class PageRepository extends \LeanMapper\Repository
{

    public function find($id, $lang)
    {
        $statement = $this->connection->select('*')
            ->from($this->getTable())
            ->where('id = %i', $id);

        PageFilter::joinTranslation($statement, $lang);
        $row = $statement->fetch();

        if ($row === false) {
            throw new \Exception('Page was not found.');
        }
        return $this->createEntity($row);
    }

    public function persist(Entity $entity) // $entity instanceof Page
    {
        if ($entity->isModified()) {
            $values = $entity->getModifiedData();
            if ($entity->isDetached()) {

                $this->connection->insert(
                    $this->getTable(),
                    array_intersect_key($values, array_flip(array('id', 'date_created', 'status')))
                )->execute();

                $id = $this->connection->getInsertId();
                $this->connection->insert(
                    'page_translation',
                    array_intersect_key($values, array_flip(array('lang', 'text'))) + array('page_id' => $id)
                )->execute();

                $entity->markAsCreated($id, $this->getTable(), $this->connection);
                return $id;
            } else {
                $pageTableValues = array_intersect_key($values, array_flip(array('date_created', 'status')));
                if (!empty($pageTableValues)) {
                    $this->connection->update($this->getTable(), $pageTableValues)
                            ->where('[id] = %i', $entity->id)
                            ->execute();
                }
                $pageTranslationTableValues = array_intersect_key($values, array_flip(array('lang', 'text')));
                if (!empty($pageTranslationTableValues)) {
                    $this->connection->update('page_translation', $pageTranslationTableValues)
                            ->where('[page_id] = %i AND [lang] = %s', $entity->id, $entity->lang)
                            ->execute();
                }
                $entity->markAsUpdated();
            }
        }
    }

}
?>

Všimni si, že až na repositář, který prostě musí rozhodnout co kam sypat a odkud co načítat, je vše triviální.

Třídy pak můžeš používat následovně:

$page = $pageRepository->find(1, 'cs');

write($page->id);
write($page->lang);
write($page->text);

separate();

$page = $pageRepository->find(1, 'en');

write($page->id);
write($page->lang);
write($page->text);

V ukázce, kterou máš ode mě v archivu (i s daty), dostaneš výpis:

1
cs
český text úvodní stránky

-----

1
en
english content of homepage

No a samozřejmě funguje i persistence:

$page = new Page;

$page->dateCreated = '2012-01-01 12:00:00';
$page->status = 'created';
$page->lang = 'sk';
$page->text = 'slovenský obsah stránky';

$pageRepository->persist($page);

$page->text = 'upravený slovenský obsah stránky';

$pageRepository->persist($page);

write($page->id);
write($page->text); // vypíše "upravený slovenský obsah stránky"

separate();

$page = $pageRepository->find($page->id, 'sk');

write($page->id);
write($page->text); // vypíše "upravený slovenský obsah stránky"

K ideálnímu porozumění tomu, co to vypíše, je vhodné mít vedle i výchozí stav databáze, takže určitě se na to podívej v tom archivu.

Tak doufám, že jsem správně pochopil zadání a má řešení jsou trefná. Upřímně řečeno, v tom mapování entit rozlezlých přes více tabulek mi přijde Lean Mapper jako úžasně silný nástroj.

Jinak všimni si, že ten vyrobený filtr by šel recyklovat i jinde v aplikaci. Na stránky by například mohli odkazovat autoři:

<?php

namespace Model\Entity;

use Model\Filter\PageFilter;

/**
* @property int $id
* @property Page[] $pages m:hasMany m:filter(PageFilter::joinTranslation)
* @property string $name
*/
class Author extends \LeanMapper\Entity
{
}
?>

A používalo by se to pak následovně:

$author = $authorRepository->find(12);

foreach ($author->getPages('cs') as $page) {
    write($page->id);
    write($page->text);
}

Editoval Tharos (4. 6. 2013 22:47)

skus

$products = $orderDetail->products;
$products[] = $p;
$orderDetail->products = $products;

Editoval bazo (4. 6. 2013 15:12)

Tharos wrote: Jsem otevřen jakýmkoliv nápadům.

Jen pro inspiraci (pokud jsi to ještě neviděl) jak to řeší ORM od PetrP – property $products není typu Product[] ale typu Orm\ManyToMany (která je díky implementaci IteratorAggregate iterovatelná) a na ní se pak volají metody add($order), remove($order) a has($order).

@Tharos: Co se týče návrhu LeanMapperu tak mě zaujaly (přijdou divné) tři věci:

1. Relace definované pomocí anotací na entitě se odkazují na tabulku v databázi místo na jiný repositář (který ví na kterou tabulku se mapuje).
2. Chybějící identity map (částečně to spolu souvisí s předchozím bodem.)
3. LeanMapper\Repository::$defaultEntityNamespace – globální magie je zlo, pokud to někdo potřebuje, ať si přepíše getEntityClass ve svém BaseRepository

Editoval Jan Tvrdík (4. 6. 2013 18:10)

Ještě je tu možnost uvést oba typy zároveň, tj. @property Product[]|\LeanMapper\ManyToMany $products. Vypadá to škaredě, ale napovídat by to díky tomu mělo správně. Preferoval bych současný kompaktní zápis, ale umožnil bych i uvést oba typy pro případ, že někdo bude chtít funkční napovídání a časem to umožní i výměnu implementace, bude-li to k něčemu potřeba.

Btw. jaktože tu ještě nikdo neprudí, že téma nesouvisí s Nette? :-)

Není pravda, web Lean Mapperu běží na Nette :) A hlavně moderátoři jsou rozumní.

@Tharos:

Vím, že je to spíše filozofický problém, ale neměla by si metoda persist a delete v repository kontrolovat, jestli opravdu dostává Entitu, která jí náleží?? Něco třeba na způsob:

public function persist(Entity $entity)
{
    $entityClass = $this->getEntityClass();
    if(!($entity instanceof $entityClass)){
        throw new \Exception('...');
    }
    if ($entity->isModified()) {
        $values = $entity->getModifiedData();
        if ($entity->isDetached()) {
            $this->connection->insert($this->getTable(), $values)
                ->execute(); // dibi::IDENTIFIER would lead to exception when there is no column with AUTO_INCREMENT
            $id = isset($values['id']) ? $values['id'] : $this->connection->getInsertId();
            $entity->markAsCreated($id, $this->getTable(), $this->connection);
            return $id;
        } else {
            $result = $this->connection->update($this->getTable(), $values)
                ->where('[id] = %i', $entity->id)
                ->execute();
            $entity->markAsUpdated();
            return $result;
        }
    }
}

V současné implementaci totiž může klidně projít následující:

$magazineRepository = new \Model\Repository\MagazineRepository($connection);

$book = new \Model\Entity\Book();
$book->title = 'foo';

$magazineRepository->persist($book);

Pokud entita Book nebude mít definovanou nějakou property, kterou nemá entita Magazine, tak kód výše normálně projde a entita Book bude uložena zcela jinam než by měla být.

U metody delete mi pak tato ‚vlastnost‘ přijde ještě „nebezpečnější“:

$magazineRepository = new \Model\Repository\MagazineRepository($connection);
$bookRepository = new \Model\Repository\BookRepository($connection);

$book = $bookRepository->find(123);

$magazineRepository->delete($book);

Místo upozornění, že se snažím repository nacpat špatnou entitu, to bez milosti smaže časopis s příslušným ID entity Book.

Editoval Etch (8. 6. 2013 9:27)

@Etch: Díky za cenné připomínky.

Ad 1) Tohle je jasný logický bug. Opravu zahrnu do verze 1.3.1, kterou bych rád vypustil nějak začátkem příštího týdne…

Ad 2) Případ použití, který jsi uvedl, dává smysl a rád tedy podporu pro @property-read zahrnu. Ono kdysi už pro něj v Lean Mapperu podpora byla, ale pak jsem chvíli měl entity read only (rozmýšlel jsem, za jaký konec uchopit persistenci) a když jsem pak persistenci dodělával, @property-read už jsem zpátky nezavedl.

Trochu záměrně, protože co jsem například u YetORM viděl, @property-read svádí k použití u ID entity, což je ale poměrně nešikovné. Minimálně to znemožňuje vložit záznam do tabulky, která nemá nad ID auto increment.

Zahrnul bych to taky do verze 1.3.1, protože žádnou zpětnou nekompatibilitu to nezpůsobí.

Díky za inspiraci! :)

P.S.: Filtry umí pracovat s use statementy. Namísto:

/**
 * @property Comment[] $commentsWithRatings m:belongsToMany m:filter(\Model\Expansion\Comment::withRatings)
 */

můžeš mít IMHO o něco přehlednější:

use Model\Expansion\Comment;

/**
 * @property Comment[] $commentsWithRatings m:belongsToMany m:filter(Comment::withRatings)
 */

Editoval Tharos (8. 6. 2013 21:23)

@Tharos:

Ad 1) Tohle je jasný logický bug.

Po té, co jsem před nějakou dobou otevřel jednu třídu, jejíž otvírání mi na 20 vteřin zaseklo NetBeans abych posléze zjistil, že má 47 metod, její délka je 3243 (slovy třitisícedvěstěčtyřicettři) řádků, že type hinting autor zřejmě považoval za nadbytečné psaní, method a property visibility zřejmě také (= všechno public [ poravdě property tam existovala jenom jedna a třída jí používala úplně na všechno ]), řádky dlouhé běžně 350 znaků, $GLOBALS bylo na každém pátém řádku, atd atd, už téměř všechno považuji za filozofický problém. :D

Filtry umí pracovat s use statementy.

Hezké. Dobré vědět. Ono já si zatím s těma filtrama jen tak hraji, protože vzhledem k tomu, že k filtrům ještě nemáš dopsanou dokumentaci a já jsem logicky líný nějak hlouběji zkoumat zdrojáky, tak se do „větších akcí“ s filtry radši nepouštím. :D

Editoval Etch (8. 6. 2013 22:52)

Mám taková dvě RFC k API…

Usnadnění persistence jednoduchých M:N vazeb

Jak moc praktické by vám přišlo následující API?

<?php

/**
 * @property int $id
 * @property Tag[] $tags m:hasMany
 * @property string $name
 */
class Book extends LeanMapper\Entity
{
}

/**
 * @property int $id
 * @property string $name
 */
class Tag extends LeanMapper\Entity
{
}

//////////

$book = $bookRepository->find(1);
$tag = $tagRepository->find(1);

// Nejstručnější (preferovaná) varianta:

$book->tags[] = $tag; // přidání
unset($book->tags[$tag]); // odebrání

// Upovídanější varianta

$book->tags->add($tag); // přidání
$book->tags->remove($tag); // odebrání

// Fungovalo by samozřejmě i následující:

$tags = $book->tags;

$tags[] = $tag;
unset($tags[$tag]);

$tags->add($tag);
$tags->remove($tag);

// A IMHO by bylo praktické mít podporu i pro:

$tagId = 1;

$book->tags[] = $tagId; // přidání
unset($book->tags[$tagId]); // odebrání

$book->tags->add($tagId); // přidání
$book->tags->remove($tagId); // odebrání

$tags = $book->tags;

$tags[] = $tagId;
unset($tags[$tagId]);

$tags->add($tagId);
$tags->remove($tagId);
?>

Když už by se zavedlo tohle, co pak třeba umožnit i následující?

$tag = $book->tags[1];

Tohle by ale zůstala zapovězená činnost:

$book->tags[1] = $tag;

Dává smysl proč? Nebo je to neintuitivní/magické?

Samozřejmě by pak po takovýchto operacích šlo jednoduše zavolat:

$bookRepository->persist($book); // vše se uloží

Výčtový typ

Napadlo mě zavést nový příznak (m:match), který by mohl obsahovat regulární výraz, který musí hodnota položky matchnout. Samozřejmě by šel použít pouze u non-object & non-array typů. Pomocí jej by šel výčet pohodlně vyjádřit a navíc by měl ještě širší užití.

<?php
/**
 * @property int $id
 * @property string $status m:match(#^(active|inactive|deleted)$#)
 * @property int $count m:match(#^[1-5]$#)
 */
class Book extends LeanMapper\Entity
{
}
?>

Přišlo by vám to praktické?

Předem díky za reakce. :)

Edit: Opraven název příznaku m:match…

Editoval Tharos (10. 6. 2013 9:23)

+1.

Jen bych dodal ještě podporu pro zjištění, jestli kolekce daný prvek již obsahuje.

Např.

isset($tags[$tag]);
$tags->has($tag);

isset($tags[$tagId]);
$tags->has($tagId);

Ahoj,

vydal jsem verzi 1.3.1 a při té příležitosti jsem také umístil na web changelog a roadmap.

Ve verzi 1.3.1 byly opraveny všechny známé chyby a nově přidané funkce nezpůsobují žádný BC break.

Jak je patrné z roadmapy, většina novinek, které plánuji do verze 1.4.0, je již hotová v develop větvi na GitHubu. Do verze 1.3.1 jsem je ale nezahrnoval, protože obsahují drobné BC breaky. V každém případě verzi 1.4.0 bych chtěl vydat velice brzy. A pak bych se zaměřil na dopsání dokumentace, nějakých pokročilejších ukázek a taky testů…

Editoval Tharos (10. 6. 2013 19:47)

@Jan Tvrdík: Hezký, vymyslel jsi asi po všech směrech lepší řešení. :)

m:match bych do verze 1.4.0 stejně naimplementoval, vidím v něm velký potenciál, ale na výčet bude Tebou navržený příznak m:enum rozhodně lepší. Takže to píšu do roadmapy.

Za tohle navedení vážně díky.

Budu to brát postupně. :) Právě jsem pushnul na GitHub podporu pro zápis, který jsi zmínil zde. Jak to v praxi funguje je vidět v testech.

Pokusil jsem se pohrát si s tím, aby to rozumělo výrazům self::, static::, parent::, SomeClass::… a aby to respektovalo i use statement (když už ten parser mám, že…). Věřím, že chování je teď intuitivní.

Všechny Tebou navržené další verze mi přijdou užitečné. Jen bych je ale asi neimplementoval vzápětí, protože teď mi třeba přijde aktuálnější ta podpora správy a persistence M:N vazeb (minimálně já už bych jí docela ocenil :–P).

Časem ale rád naimplementuji i ty další Tebou navržené varianty, nebude to nic složitého.

Entity se mi zdají trochu nedomyšlené :-). Určitě by bylo od věci anotace jednotlivých sloupců psát aspoň ke geterům nebo opravdu mapovat jednotlivé Columm jako privátní proměnné (Doctrine2 to má celkem pěkně zmáklé).

@jablon: Každou entitu, kterou zde uvádíme, lze přepsat do podoby bez jediné anotace. Jenom je s tím děsně psaní, takže doporučený způsob je použít anotace všude tam, kde to je možné.

V Lean Mapperu má entita jasně dané veřejné API (a zvenčí je nenarušitelná) a @property (respektive @property-read) anotace se v něm do veřejného API započítávají. Tohle není myslím nic troufalého, takhle se k tomu, co je veřejné API, staví už snad všechna nejpoužívanější IDE (která pak napovídají).

Přepsat položky na třídní proměnné a pak psát anotace k nim (jak se to dělá v Doctrine 2) neplánuji, protože to je to samé v bledě modrém, jen dokonce mírně upovídanější.

V první řadě díky za názor.

Přiznám se, že Tvé výhrady jsem pochopil až po přečtení poslední věty (řekněme částečně – výtka k logičnosti referenced/referencing mi i nadále přijde lichá). Z té jsem totiž pochopil, že v jádru problému smýšlíme jinak. A to je dobře! To činí svět podobných knihoven pestrý a je z čeho vybírat. :)

hrach napsal(a):

abstrakce do entit je prave to, co me ma odstrihnout co nejvice od SQL

Situace se má tak, že já si za cíl odstřižení od SQL prostě nekladu. Pro mě nemají entity ten přínos, že vše je dokonale abstraktní a když budu potřebovat, zítra vyměním mapper.

Pro mě mají entity ten přínos, že představují nějaký zapouzdřený nenarušitelný celek s jasným API a že mám možnost umístit do nich (spolu s repositáři) business logiku, která by se mi v samotné databázi vyjadřovala nepohodlně (například že autor může být autorem maximálně pěti knih; někdo si může půjčit kolik chce knih, ale pouze od tří různých autorů…). Pokud v takovém zadání nemám entity (a repositáře), musím řešit, kam s touhle logikou. Nezřídka kdy se pak roztrousí všemožně po aplikaci (někdy přeteče až do šablon!), začne se opakovat… Samozřejmě jsou i jiné vzory, jak tohle řešit (třeba takový Table Module), ale prostě entity tohle řeší zdaleka nejelegantněji.

Následně pro mě mají entity ještě ten přínos, že skrze ně mohu data upravit a pomocí nějakého repositáře pak i persistovat (plus vytvořit a smazat).

To, že mě nějak odstíní od SQL nebo mi umožní jednoduše vyměnit mapper, má pro mě osobně význam o řád menší. V tomhle mi bohatě stačí, že pod pokličkou je DBAL, takže například přechod z MySQL na PostreSQL by byl snadno proveditelný.

Inspirován komentářem od Honzy Tvrdíka jsem v neveřejné větvi začal přepisovat Lean Mapper tak, aby byl plně kompatibilní s Data Mapper vzorem. Tuhle větev už jsem ale opustil, protože s postupujícím návrhem (k implementaci jsem se pořádně ani nedostal) bylo zjevné, jak ORM nakyne, a co hůř, o co kostrbatěji se v něm bude mapovat. Až se zdálo, že řada problémů pak nepůjde nějak snadno vyřešit vůbec.

Editoval Tharos (28. 1. 2014 16:34)

Proto taky ty příznaky m:hasMany a m:belongsTo(One|Many) v Lean Mapperu jsou (a taky m:hasOne).

Díky za názor. Neztotožňuji se s ním, ale beru ho na vědomí. Pokud se ozve víc lidí, že je tohle pro ně složité, budu nad tím přemýšlet. Myslím, že je v tomhle vlákně vidět, že se snažím uživatelům naslouchat a na vše reagovat. Prioritně pak řeším konkrétní dotazy, protože ty abstraktní bývá někdy problém zodpovědět („nemá to žádnou logiku“ – opravdu žádnou?; „to bylo to nejhorsi, cos z tohoi mohl vzit“ – proč?).

Bude skvělé, když své myšlenky naimplementuješ v Nextras\ORM. Zase bude větší výběr ORM a ti, kterým jedno přijde složité, budou snadno moci přejít k jinému.