Zend FR

Salut,

L'intérêt du mapper est de découpler un peu plus le front de l'application de la persistance.

Dans un monde parfait, les controlleurs ne devraient jamais communiquer directement avec la couche de persistance (pour toi Zend_Db). Ils ne devraient que "contrôler" l'information et transmettre après contrôle à une autre couche pour la suite des opérations.
Le controlleur ne va donc manipuler que des objets entité (Entity Object), ou objets métier (Domain Object/Business Object).

Qu'est-ce qu'un objet métier ?

Ces objets représentent la plupart du temps les entités du domaine métier pour lequel l'application est conçue.

Ils sont pensés et implémentés par les développeurs et non pas par le framework. Ils sont totalement détachés  de la persistance (base de données ou autre).

Par exemple, ton application doit afficher des galeries d'images, et ces galeries appartiennent à des utilisateurs.
Tu vas avoir une entité Utilisateur dans laquelle tu auras des galeries qui sont elle-mêmes des entités Galerie. C'est la définition des entités qui répondent au métier, au domaine abordé.

Le terme "modèle métier" est un peu utilisé à toutes les sauces. Le modèle métier (Domain model) représente l'ensemble des objets métiers, donc des entités, et les relations entre eux. Ni plus, ni moins.

Les objets métiers sont la plupart du temps peuplés avec des données des entités réelles (dans le métier) qu'ils représentent (mais pas toujours).


Le Mapper dans tout ça ?

Les objets métiers sont les seuls éléments qui sont connus dans toutes les couches de l'application.
Les controlleurs ne doivent pas connaitre l'organisation de la persistance, mais connaissent les objets métiers, c'est donc au travers de ceux là qu'ils vont travailler.
Ils assurent un contrôle aller/retour des informations vers le client, la dynamique de l'application (intéractions, etc.).

Sauf que, comment faire persister un objet métier, ou comment récupérer les données pour peupler un objet métier si le controlleur ne connait pas la persistance ? Et bien il passe par le mapper.

Le rôle du mapper, tel que Zend l'introduit, est de savoir comment récupérer les informations nécessaires dans la persistance pour peupler un objet métier. Ou bien de savoir comment demander à la persistance d'enregistrer un objet métier.

Le controlleur saura donc créer un objet métier, le peupler (depuis un formulaire par ex.) et demandera au mapper de faire persister cette objet. Ou dans l'autre sens, le controlleur a besoin d'un objet métier déjà peuplé, il demandera au mapper de lui retourner.

Si demain, la couche de persistance change, tu n'auras rien à refactoriser dans tes controlleurs, seuls les mappers vont changer.

Mais aussi, si tes mappers sont prêts, tu peux développer le front indépendamment du back et tu n'es pas obligé d'attendre après la conception de la base de données pour commencer ton dév.

Après, tout dépend de la dimension de l'application, beaucoup de développeurs décident qu'un Zend_Db_Table_Row = un objet métier, et ceci leur convient.

Pour moi ce n'est pas satisfaisant pour plusieurs raisons.
D'abord, une entité n'est pas forcément égale à une table, elle peut être construite à partir de plusieurs tables dans la BDD.
Ensuite, tout ceci lie très fortement ton front à une persistance type base de données. Si demain tu dois récupérer tes données depuis un webservice en XML ou depuis un annuaire il faudra tout refactoriser.

Enfin, la solution proposée par Zend dans le Quickstart est, selon moi, insuffisante. Par exemple, pour faire persister un objet métier, ils ont implémenté la méthode save() dans l'objet métier, ce qui, à mon sens est une abérration. Mais plus loin encore, pour un découplage réel de toutes les couches, la notion de mapper est plus qu'insuffisante et n'est qu'une brique de toute l'architecture.

Celà fait quelques jours que je me penche sur le sujet du découplage et d'une architecture découpées en Controlleurs/Services/ORM avec inversion de contrôles (IOC ou Di = injection de dépendances). Je vais très bientôt faire un retour de ce que j'en ai tiré sur le forum, ça pourra peut-être te donner des idées, sachant qu'il n'y a pas LA bonne solution, d'autres personnes t'en proposeront, parfois tout aussi efficaces, d'autres insuffisantes. Tout ceci demande beaucoup de réflexion.


A+ benjamin.

Merci Delprog pour cette analyse !

J'ajoute un article intéressant (téléchargez le PDF) vers une conf sur les différents types d'ORM en PHP (bon, Zend_Db_Mapper n'était pas encore sorti...).
http://maggienelson.com/2009/05/orm-in-the-php-world/
et le PDF :
http://maggienelson.com/conferences/php … _World.pdf

A+, Philippe

Asfaloth a écrit:

La seule chose qui me turlupine dans ton explication, c'est

Enfin, la solution proposée par Zend dans le Quickstart est, selon moi, insuffisante. Par exemple, pour faire persister un objet métier, ils ont implémenté la méthode save() dans l'objet métier, ce qui, à mon sens est une abérration.

Tu pourrais me dire, pourquoi de ton point de vue c'est une abérration ?

En fait, un objet métier peut avoir plusieurs "status". Il peut être une "entité" (c'est grossier mais je vais utiliser ce terme) et doit donc pouvoir être persisté. Il peut être un simple objet volatile (calculs par ex.), qui n'est donc pas persisté et ne représente pas d'entité en terme de métier.

Dans tous les cas, ces objets, quels qu'ils soient ne déterminent pas eux même leurs "status" et le save() n'est surement pas de leur ressort. Implémenter un save() dans l'objet métier revient à faire connaitre à l'objet autre chose que le métier. Dans le quickstart, l'objet métier fait appel au Mapper, c'est très "sale" :p

Julien a écrit:

Si je peux te donner un conseil : va voir ce qu'il se passe coté Java : Hibernate, Spring et autres EJB, et si t'as l'occasion d'attaquer un projet Ruby avec Rails, prend le vite vite vite. Après tu ne verras plus jamais PHP de la même manière.

Pour moi, hibernate et spring MVC sont la crème. Dans ce que je proposerai bientôt, je me suis inspiré sans retenue de leurs fonctionnement en essayant de l'adapter à un environnement script. Seule chose qui me laisse dubitatif dans leurs dernières versions, c'est l'utilisation des annotations, bien que pratique, je ne sais pas ça me dérange.

Sinon, JAVA est un langage très mûre, et Spring MVC couplé à Hibernate implémentent des patterns très très efficaces (Factory, Proxy, Service Layer, DAO, ORM pour ne citer que ceux là).

Julien a écrit:

Aussi, renseigne-toi sur les patterns (et des bouquins sur ça .... il en existe des tonnes et des tonnes, les meilleurs sont en anglais), c'est la base de tout développement informatique "moderne", quel que soit le langage.

Et si tu es passionné, chaque fois que tu découvriras ce que tu peux faire d'un pattern tu t'illumineras :p


A+ benjamin.

Par contre, désolé d'insister mais j'aime bien aller au fond des choses, le fameux save de la doc, tu l'aurais placer où et comment ?

L'idée serait de placer le save dans le mapper, on aurait :

$mapper->save($objetMetier);

au lieu de

$objetMetier->save();

Sur le principe je suis plutôt d'accord avec Delprog. C'est particulièrement choquant pour un delete : quand tu fais $objetMetier->delete(), ton instance a disparu en base et tu continues à avoir un $objetMetier un peu zombi... c'est pas à l'objet métier de se détruire lui même, c'est plutôt au mappeur...

Cependant d'un point de vue pragmatique, je trouve que c'est souvent bien pratique d'avoir ces méthodes dans l'objet métier... Sur le principe ça me choque un peu, mais dans un code c'est tellement pratique que je suis un peu plus mesuré sur ce point... (il faut s'appuyer sur les principes, ils finiront bien par céder )

A+, Philippe

Bonjour,

Delprog a écrit:

Par exemple, ton application doit afficher des galeries d'images, et ces galeries appartiennent à des utilisateurs.
Tu vas avoir une entité Utilisateur dans laquelle tu auras des galeries qui sont elle-mêmes des entités Galerie. C'est la définition des entités qui répondent au métier, au domaine abordé.

Du coup ici on aurait deux objets metier, Utilisateur et Gallerie ? Dès lors l'appel au mapper pour récupérer  un objet métier Utilisateur opèrerait (dans le cas d'une base de données avec 2 tables user/gallery) un select en base pour récupérer l'utilisateur (sur user), injectant les données dans un objet métier Utilisateur, puis ensuite un select pour récupérer toutes les galleries de l'utilisateur (sur gallery), les injectant chacune dans un objet métier Gallerie et ensuite injectant ces objets métier Gallerie dans une propriété (tableau) de l'objet métier Utilisateur (array galleries contenant donc les objets métiers gallerie) ?

Si c'est ainsi, est-ce qu'il convient que des mappers puissent communiquer entre eux ? A savoir que pour récupérer les galleries le mapper Utilisateur pourrait appeler le mapper Gallerie qui lui renverrait tous les objets Gallerie peuplés ?

Et lors d'une modification/ajout/suppression d'une gallerie à partir d'un objet métier Utilisateur le mapper Utilisateur passerait au mapper Gallerie les objets contenu dans l'objet métier l'Utilisateur pour qu'il les ajoute/modifie/supprime en base ?

Delprog a écrit:

J'essaie de trouver du temps pour expliquer tout ça en détail.

Merci, comme d'habitude enrichissant.

La solution que tu étudies/testes semble relativement performante et facilement maintenable, bien pratique en soit.

A l'époque où tu utilisaient les mappers par objet, te souciais-tu du fait qu'une propriété d'un objet avait pu être modifiée ou non ?
Je pense à un Utilisateur ayant 100 objets Gallerie, au moment d'opérer un save de l'Utilisateur, comment savoir si tout ou partie des galleries devaient être également modifiées dans la persistance ? (éventuellement une notion de propriété (tableau) "$_modified" par objet, recensant les propriétés modifiées au sein d'un objet ?)