Design Pattern "data mapper", quelques précisions
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:
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:
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.
