Discussion :

[sir_gcc]

Bonjour,

J'ai passé un peu de temps à regarder la doc du framework à propos de la partie base de données, donc Zend_Db et les classes qui tournent autour, et j'ai été un peu dérouté par rapport à ce que je connaissais.
J'ai lu il y a quelques temps que ce framework permettait de faire de l'ORM, mais je n'ai pas retrouvé mes petits. Pour moi l'ORM c'est mapper une classe avec une table. Et le framework gère ensuite tout seul les opérations sur les objets.

Par exemple, on crée un objet de type Client avec des attributs qu'on renseigne, et ensuite, reste à appeler la bonne méthode pour le créer.
Par exemple create($client). Cette méthode étant appelée sur une classe utilitaire qui hérite d'une classe générique du framework (ma référence est hibernate).
Pour info je suis habitué à ce qu'un objet avant d'être persisté ait comme clé primaire la valeur "null", et après avoir été persisté il s'en voit attribuer une par le framework, celle utilisée par le sgbd.

Ensuite si on veut modifier notre objet on le fait sans s'occuper de la base et si on veut le faire persister on utilise la méthode update sur la même classe utilitaire que pour la création.

En regardant la doc je n'ai pas trouvé d'exemple ou on manipule des objets métier. Bref je n'ai pas trouvé la notion de mapping.

Est-ce que j'ai loupé quelque chose dans ce que propose le framework ?

[aurelman]

Bonjour,

Tu peux regarder du coté de Zend_Db_Table, c'est le point de départ des fonctionnalités d'ORM dans le Zend Framework.

[sir_gcc]

Tu penses bien que j'ai deja regardé la doc du framework à ce sujet.
Ce que je me demande, c'est comment distinguer la couche métier de la couche d'accés aux données.
Je n'ai pas l'impression qu'on ait besoin d'objets métiers pour faire de l'ORM avec le framework, ce qui est un peu paradoxal selon moi. Ou alors, si on fait des objets métier, on n'a pas besoin d'une couche DAO.

C'est pour ça que je voulais avoir des avis de gens qui utilisent Zend Framework pour une appli deja conséquente, et qu'ils me disent comment sont organisées ces deux couches.

[__2mx]

Jette un œil à :

http://www.developpez.net/forums/sho...d.php?t=426354

La partie intéressante est en page 2.

[sir_gcc]

Merci pour le lien. J'avais déjà lu cette discussion, mais elle ne répond pas à mon problème.
Pour ma part, je suis convaincu par l'usage du pattern facade. Clairement c'est vraiment se simplifier la vie que de l'utiliser.

Mon "problème" se situe plus au niveau implémentation de l'ORM.

Pour l'instant j'ai cette arborescence :


En admettant que Inscrit.php soir cette classe :

Code :

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

1
2
3
4
5
6
7
<?php
	class Inscrit {
		private $pseudo = '';
		private $password = '';
		private $email = '';
	}
?>

A quel endroit je peux mettre le code qui me permettra via l'appel à des méthodes de la classe IService de créer, mettre à jour, supprimer et sélectionner des objets de type Inscrit ?
Et aussi, quel est la façon de procéder avec ce que Zend propose ?

Ce que j'ai vu pour l'instant, c'est de faire par exemple :

Code :

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

1
2
3
4
5
6
7
<?php
	class Inscrit extends Zend_Db_Table_Abstract {
		private $pseudo = '';
		private $password = '';
		private $email = '';
	}
?>

Et ensuite, dans le controlleur :

Code :

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

1
2
3
4
5
6
7
8
 
$data = array(
'PSEUDO' => 'jean_test',
'PASS' => 'pass_test',
'EMAIL' => 'monadresse@free.fr_test',
);
$newInscrit = new Inscrit();
$newInscrit->insert($data);

Ce qui me semblerait plus naturel, serait de créer un objet de type Inscrit, de lui attribuer des valeurs pour chaque attribut, et enfin de le faire persister.

Code :

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

1
2
3
4
5
6
 
$alphonse = new Inscrit();
$alphonse->setPseudo('georgio');
$alphonse->setEmail('geaorgio@developpez.com');
$alphonse->setPassword('azerty');
$this->service->createInscrit($alphonse); // à ce moment en suppose que le sgbd attribue la valeur 7 (par exemple) comme id à l'enregistrement

Par la suite, je peux récupérer mon objet de type Inscrit en faisant :

Code :

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

1
2
3
4
 
$alphonse = $this->service->getInscritById(7);
$alphonse->setEmail('unAutreEmail@developpez.com');
$this->service->updateInscrit($alphonse);

Le framework est-il prévu pour ce genre de chose ? Et si oui, comment organiser ce qui est derrière le service ? Des exemples seraient bien venus

[sekaijin]

j'ai écrit ceci si ça peu aider
http://zend-framework.developpez.com...in/blog/zf/db/

A+JYT

[__2mx]

D'après ton exemple, il semble que tu veuille utiliser le "Data Mapper" patterns (http://martinfowler.com/eaaCatalog/dataMapper.html).

En m'aventurant sur un sujet que je ne maitrise pas, il me semble possible de l'implémenter facilement à partir de Zend_Db_Table. J'ai sous les yeux l'excellent bouquin "php5 Objects, Patterns, and Practice" de Matt Zandstra et pour finaliser ce type d'implémentation il utilise aussi les Patterns "Identy Map" (pour éviter d'avoir plusieurs instances d'une même classe), "Unit of Work" (pour limiter les opérations inutiles sur la base de données)

Par contre, si par ORM tu entends des outils de génération de code pour tes objets métier et les DataMapper ect... il n'y a rien pour l'instant, et je ne sais pas ce qui est planifié.

ZF a été développé avec la règle des 80/20, avec pour objectif, je pense, des "Domain Model" peu compliqué avec un mapping assez directe avec la base de données. Là je pense que Zend_Db_Table et Zend_Db_Row répondent bien à ces critères.

Il y a beaucoup de cas d'utilisation ou l'on aura peu ou pas de logique métier et si le couplage avec la base de données n'est pas un problème on peut directement utiliser Zend_Db_Table comme modèle ( là je risque d'en faire hurler quelques un ).

Si le couplage devient un souci on peut séparer en 2 couches, une couche métier et une couche d'accès au données, plus d'autres goodies si besoin est (voir le blog de Sekaijin http://zend-framework.developpez.com/sekaijin/)

Il y a eu une discussion sur ce sujet dans la mailing list :
http://www.nabble.com/Models-and-zen...094s16154.html

et une ici
http://www.nabble.com/Models%2C-Obje...html#a11521922

[sir_gcc]

@sekaijin : très bon article, c'est exactement ce que je me posais comme question. Je crois comprendre que tu commences à bien connaître ZF. Je t'encourage vivement à continuer d'écrire des articles de ce genre !

@__2mx : En ce qui concerne les patterns, je devrais peut-être mieux les connaitre avant d'essayer de les retrouver dans un framework, ça me ferait gagner du temps.
Mis à part ça je ne vois pas ce que tu veux dire en associant ORM et génération de code. Pour moi l'ORM c'est ce que sekaijin décrit dans l'article qu'il cite.

En tous cas grâce à vos réponses j'ai de quoi avancer. Je sais comment réaliser le mapping, maintenant il me reste à voir comment je vais découper mon appli en couches (ou pas). Mais vous m'avez fourni un peu de lecture là-dessus.

Merci à vous.

[__2mx]

Mis à part ça je ne vois pas ce que tu veux dire en associant ORM et génération de code.

Tu définis ton mapping dans un fichier XML et l' ORM te génère toute les classes dont tu as besoins, exemple avec Propel http://propel.phpdb.org/trac/

[sir_gcc]

D'accord, en le disant c'est vrai que j'en ai deja entendu parler, mais je n'ai jamais utilisé.
Je crois que pour l'instant ce que je développe ne nécessite pas l'artillerie lourde.
Merci du tuyau quand même.

[sekaijin]

pour la génération automatique j'avais commencé un parseur de fichier DBDesigner4 et donc à partir du shéma de la base et des commentaires présent je générais tout la couche d'accès aux données. mais FabForce à annoncé l'abandon de DBD4 alors je me suis arrêté. puis entre temps php5 est arrivé et ma couche objet pour les base de données est devenue celle de Zend

donc à part mon expérience en php 4 avec dbd4 il ne me reste rien d'exploitable.

j'ai vaguement entendu dire qu'il y aurait un repreneur pour dbd4. il y a aussi le fichier xml de l'outil de MySQL AB, il y a aussi les fichiers xml ERwin

pour le moment je n'ai pas d'orientation quant à l'outil qui sera utilisé. mais je garde sous le coude cette idée.

j'ai utilisé la version précédente pour générer automatiquement le code pour une appli ayant 26 tables 31 relations dont certaines hiérarchiques et d'autre d'héritage (je travaillait sous postgresql)

bref c'est d'un certain confort que de pouvoir ainsi dessiner sa base générer le script SQL et toute la couche d'accès php en une compilation.

reste que sur se genre d'outil se pose toujours le pb des modifs du modèle, doit on regénéer où produire un path car bien évidement on laisse rarement les classes en l'état

A+JYT

[ovh]

Perso je fais comme ça :
Insertion :

Code php :

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

1
2
3
$myrow = $myDbTable->createRow();
$myrow->mon_attribut = "ma valeur";
$myrow->save();

Update :

Code php :

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

1
2
3
$myrow = $myDbTable->find($macleprimaire);
$myrow->mon_attribut = "ma nouvelle valeur";
$myrow->save();

Simple non ?
Bref, le framework s'emploie exactement de la même façon pour insert/update il exécute la requête adéquate. Et quand il sauve, il rafraîchit les attributs des classes avec ceux de la table physique en db

[sekaijin]

avec le save il va même un peut plus loin car il fait le ménage

Code :

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

1
2
3
4
$myrow = $myDbTable->find($macleprimaire);
$myrow->mon_attribut = "ma nouvelle valeur";
$myrow->mon_attribut_de_ma_classe_qui_nest_pas_dans_la_table = "autre nouvelle valeur";
$myrow->save();

myDbTable va ignorer les champs de l'objet qui ne sont pas des colonnes de la table et ne cherchera à enregistrer que les champs correspondant à des colonnes.

A+JYT

[ovh]

Oui et d'ailleurs autre chose que j'ai remarqué : il respecte bien le schéma de la table, en ce sens que par exemple si certaines colonnes ne pouvant être NULL ne sont pas renseignées, il lance une exception Tandis qu'avec mysql_query() il n'en a rien à foutre...