Ting : Datamapper

[srm]

Bonjour,

Le datamapper que j'ai fait pour ma société avec l'aide de Xavier Leune et maintenant open source.
Il est bien plus rapide et consomme beaucoup moins de mémoire que Doctrine.

Description : Un datamapper permet de transformer un résultat venant d'une base de données en objet PHP et vise et versa

Documentation : http://tech.ccmbg.com/ting/doc/fr/index.html
Packagist : https://packagist.org/packages/ccmbenchmark/ting
Source : https://bitbucket.org/ccmbenchmark/ting
Quelques info sur la version 3 : https://bitbucket.org/ccmbenchmark/ting/...ual-column

[Xenos]

Salut,

j'aurai bien aimé voir une petite présentation de ce que c'est (genre, question benette: "un datamapper, c'est quoi?"). J'ai survolé la doc, et de ce que j'en comprends c'est une couche intermédiaire entre PHP et MySQL/PostGre. Ce serait sympa d'en avoir rapidement les éléments clefs (mais bon, perso, moi, je ne compte pas me servir de ce genre de lib donc ne fais pas une présentation juste pour moi ).

[srm]

Je l'ai comparé à Doctrine donc je pense que tu devines ce que c'est non ?

[niahoo]

Hello, intéressant mais dès les premières lignes de la doc, je tique : « Pure PHP implementation (no PDO, no XML) ». Vous avez vraiment implémenté des pilotes MySQL et PostgreSQL en pur PHP ?

[Xenos]

Tu l'as comparé à Doctrine, ok, mais là pour moi, je ne vois pas la différence avec, par exemple, PDO.
Alors en lisant la doc, je comprends que "SELECT ... FROM t1 LEFT JOIN t2" va générer une liste de couples d'objets [{t1,t2}] (perso, cela me semble problématique puisque t1 est répété autant de fois qu'il y a de lignes alors que c'est censé être le même objet pour moi), mais à part cela, je ne visualise pas la différence avec PDO (d'où ma demande d'une description de cette "couche intermédiaire PHP/MySQL").

[srm]

Le README n'est pas très approprié en effet, puisque on utilise Mysqli et Pgsql comme driver.
Tu peux faire un HydratorAggregator pour ce besoin Xenos.

Avec PDO tu ne peux pas faire ce que tu viens de dire sauf si tu lies fortement ton object à ta base de données.
Ici on utilises le pattern DataMapper ce qui veut dire que ton objet à AUCUNE connaissance ou dépendance avec la bdd.

[Xenos]

J'ai lu la doc sans pratiquer, donc je peux me gourer, mais j'ai des doutes sur l'argument "aucune connaissance ou dépendance à la BDD", puisque j'ai vu passer la structure complète des tables dans le code PHP (un array('primary' => '...', 'id' => '...')).

Un PDO::fetchAll(PDO::FETCH_CLASS, MyClass::class), générant un bean de données que je passe en paramètre au constructeur de mon objet véritable (la classe ayant les comportements) me semble mieux découplé de la BDD (après, PDO est un DataMapper si je ne me trompe?).

Oui, ok, pour la "fusion" des x1 d'un [{x1, y1}, {x1, y2}, {x1, y3}], il faudra une couche supplémentaire... comme l'HydratorAggregator.
Ce serait intéressant justement que cet Hydrator, générique, soit fournit par défaut avec ce DataMapper (c'est le composant à plus forte valeur ajoutée je trouve).

[srm]

C'est le Repository qui a la responsabilité de connaître la base de données.
L'objet City lui n'a aucune connaissance de la base de données.

Et ton exemple avec PDO démontre bien tout le problème. Ton objet City est très dépendant de ta base de données.
Et la couche d'aggrégation n'est pas spécialement une forte valeur ajoutée.

De plus ton exemple PDO montre qu'un sens de travail, base de données > ton objet et l'inverse ?
Moi je fais :
$city = new City();
$city->setName("Luxiol");
$unitOfWork->pushSave($city);
$unitOfWork->process();

Petit complément, PDO n'est pas DU TOUT un DataMapper car il couple justement directement l'objet à la base de données, tout au plus si tu veux c'est un ActiveRecord qui marche que dans le sens base de données > objet.

[Xenos]

J'hésite entre

class CitySaverPdo extends APdoCaller { // APdoCaller stocke l'objet PDO et se charge de l'appel ->query()

    public function save(City $city) {

        $this->callSql('saveCity', $city->getId(), $city->getName());

    }

}



$city = new City();

$citySaver = new CitySaverPdo($pdo);

$city->setname("Tokyo");

$citySaver->save($city);

City n'a donc bien aucune connaissance de la BDD.
PS: j'utilise les procédures SQL parce que j'aime bien et que c'est une bonne abstraction du serveur de BDD; la procédure ici étant saveCity(?, ?) faisant surement un INSERT INTO ... (...) VALUES (...) ON DUPLICATE KEY UPDATE ....

Oui, PDO couple "l'objet" à la BDD, mais "l'objet"=le data bean. Pour moi, l'objet que sort PDO n'est effectivement pas le City, mais un "CityBean" disons, que le City peut alors accepter comme paramètre de constructeur (en plus de ses autres constructeurs usuels).

[srm]

Tu peux faire ça oui et tu gères comment une jointure deux fois sur le même objet ?
Tu peux tout faire sans DataMapper mais ça implique plus de code pour chaque objet