Discussion :

[comode]

Bonjour,

J'ouvre ce post suite à une discussion suggérant qu'il valait mieux utiliser le design pattern DataMapper plutôt que l'ActiveRecords.

Sans revenir sur les raisons qui font que l'un est mieux que l'autre, je m'inspire d'un billet visible sur http://blog.tekerson.com/2008/12/17/...attern-in-php/ pour tenter de faire mon implémentation de la chose.

Grosso modo, on trouve sur cet exemple 2 class abstraites servant de base au Mapper et aux heu... Domaines (?).

1er question : Ne serait-il pas envisageable d'implémenter le mapper sous forme de class statiques ?

L'exemple du lien ci-dessus nous donne un :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
// Initialise the Mapper.
$userMapper = new UserMapper();
 
// Fetch and manipulate the User object
$user = $userMapper->findById(1);
$user->lastname = 'Alker';
 
// Tell the UserMapper that the User needs to be saved.
$userMapper->save($user);

Je trouverai plus élégants d'écrire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
$user = UserMapper::findById(1);
$user->lastname = 'Alker';
// Tell the UserMapper that the User needs to be saved.
UserMapper::save($user);

Y'a t-il une raison de ne pas implémenter ça comme ça ?

2eme question : on trouve dans l'ActiveRecords des choses pratiques qu'il serait dommage de ne plus pouvoir utiliser... Je pense notamment aux interceptions de méthodes qui permettent de ne pas avoir à écrire les méthodes Get et Set pour chaque champs de la table. C'est appréciable quand on a des centaines de tables qui peuvent avoir plusieurs dizaines de champs ! Est-il contraire à la philosophie du data mapper de conserver ce principe et de rajouter les méthodes (magics ou non) nécessaire à son fonctionnement directement dans la class abstraite de base dont dériverait tous les autres mapper du projet ?

J'ai bien d'autre question, mais elles dépendent des réponses à ces 2 premières questions :p

En vous remerciant pour votre altruisme.

[Nightfall]

Ca doit être un abus de langage volontaire mais en php ce ne sont pas les classes mais les membres des classes qui sont statiques. Du coup il n'existe pas de constructeur statique en php. Or sur un vrai projet il y aura probablement des propriétés, liées par exemple à la source de données à utiliser, sous peine sinon de les avoir en paramètres dans toutes les méthodes. En plus je ne suis pas sûr que ces propriétés doivent être statiques : que se passe-t-il si je veux travailler avec 2 sources de données différentes en même temps, donc utiliser des mappers qui ont des sources de données différentes ?

Pour la question 2, non il n'y a pas de rapport entre les méthodes magiques et l'active record ni entre les méthodes magiques et le data mapper. C'est juste une possibilité qui facilite les choses et que l'auteur n'a pas utilisé dans ton exemple pour aller plus vite mais il aurait pu.

[comode]

Pour la question 2, je parle en terme de philosophie et ne pose pas la question en lien avec l'exemple que je cite. C'est comme si je demandais si il était judicieux de faire une class user en statique. C'est faisable mais pas du tout judicieux car c'est manifestement une incompréhension de la POO. N'étant pas encore sur d'avoir compris tout l’intérêt du data mapper, je me pose donc la question.

Pour en revenir à la question 1, le faire en statique, ça serait donc justement se priver de l’intérêt du data mapper ?

En te remerciant pour tes réponses.

[Nightfall]

Pour en revenir à la question 1, le faire en statique, ça serait donc justement se priver de l’intérêt du data mapper ?

Non, ça n'a rien à voir. Si on pouvait le faire avec tous les membres en statiques on le ferait en static. Mais je ne pense pas que ce soit un bon choix pour les raisons que j'ai expliqué.

L'intérêt du data mapper par rapport à l'active record est que l'on a des objets métier (ici l'objet user par exemple) qui n'ont aucune notion de persistance. Donc c'est un objet que l'on va pouvoir utiliser quelque soit le moyen de persistance. Ensuite on aura plusieurs versions de data mapper en fonction de la source de données. Encore faut-il faire un projet suffisamment important pour avoir une raison d'envisager des sources de données vraiment différentes, au point qu'un même data mapper ne puisse pas les gérer toutes. Autrement dit avoir une différence autre que simplement des paramètres de connexion qui diffèrent.

[ovh]

Pour le point 1, pourquoi le statique c'est mal, en gros c'est parce que les méthodes statiques imitent la programmation procédurale, par opposition à la POO. C'est-à-dire qu'en mode statique, tu ne pourras pas utiliser toute la puissance de l'OO.
L'usage de méthodes statiques devraient être limité à certains cas spécifiques (exemple : une classe "fabrique").
Pour plus de détails, je t'invite à lire l'article suivant :
http://www.croes.org/gerald/blog/de-...statiques/931/
Dont voici un extrait significatif :

L’une des forces de la programmation objet est entre autres d’encourager les mécanismes de polymorphisme et de composition. Utiliser des classes statiques, c’est s’interdire de décorer, adapter, proposer un proxy, utiliser une fabrique pour récupérer la meilleure stratégie. Utiliser des méthodes statiques c’est s’interdire de garder l’instance du service dans une collection ou dans une propriété, c’est se priver de composition.

Pour compléter ma réponse, et l'illustrer dans le cadre d'un ORM, si ce qui t'ennuie c'est de devoir faire un "new Mapper" à chaque fois, sois rassuré, ce ne sera jamais le cas en pratique.
En effet, dans un framework tel que Symfony 2, tu as accès au service "entity manager" très aisément (par un $this->get('doctrine')->getManager()), et de là tu récupère un mapper par un simple get également. Donc aucun "new" n'est nécessaire
C'est sûrement le cas dans tout autre framework qui se respecte : l'accès aux services est facilité dans l'appli, et c'est à partir de là que tu récupéreras systématiquement les mappers dont tu as besoin.

Pour le point 2, ça n'a rien à voir avec le design pattern utilisé pour la persistance. Tes entités métier peuvent très bien utiliser une classe mère qui fournit des utilitaires tels quel des getters et setters magiques, des méthodes fromArray et toArray, etc. il n'y a pas de raisons de s'en priver !
La différence c'est qu'avec le data mapper, tu fais comme tu veux, tu n'es pas obligé d'étendre une classe mère imposée par l'ORM.

[comode]

Merci beaucoup pour ces précisions !