Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Salut à tous,
Après avoir lu quelques articles et critiques à propos de Zend et Doctrine, je me demande l'intêret, le vrai, d'utiliser Doctrine...
Est-ce bien utile ?. Bien que ZF ne possède pas d'ORM (pour l'instant), il semble que Zend_Db_Table_Abstract, Zend_Db_Table_Row_Abstract soit largement suffisant pour la majorité des projets, même des plus gros.
Certain se sont penché vers une solution intéressante et alternative, à lire dans ce livre
Votre avis ?
Fabrice
Dernière modification par __fabrice (18-05-2010 22:58:11)
Hors ligne
Moi, j'ai déjà intégré Doctrine à mes projets Zend. De toute façon, la version 2 du Framework va venir avec Doctrine!
Hors ligne
Hum... après avoir utilisé Propel sur un projet assez gros, je suis un peu sceptique sur l'intérêt des ORM "étendus". Je vois bien l'intérêt d'utiliser des entités pour représenter des lignes de tables avec des fonctions CRUD basiques. Par contre suivre les relations en PHP au lieu de les suivre en SQL... Je me pose la même question que toi : est-ce bien raisonnable... Finalement je trouve que ça va plus vite en SQL.
Bref, dans mes projets, j'utilise souvent un "mini ORM maison" qui assure les fonctions suivantes :
- CRUD simple
- Gestion basique du polymorphisme pour gérer l'héritage d'objets PHP au sens "class Toto extends Titi" (quand la famille d'objets arrive dans la même table)
- Gestion d'une sorte de hiérarchie d'objets au sens node, parent node, children
- Gestion de conversions de types (un Zend_Date est transformé comme il faut pour arriver dans un DATE_TIME par exemple)
- Gestion du multilangues (oui, c'est spécifique, mais c'est tellement courant que je l'ai mis dans l'ORM....)
et quand j'ai des relations à suivre, je fais du bête SQL que j'injecte ensuite pour recréer mes entités (populate).
A+, Philippe
PS : je suis ouvert à toute discussion, mais pitié pas de troll sur ce sujet... Que des arguments justifiés et modérés...
Hors ligne
Hello,
La plupart du temps, l'utilisation d'un ORM n'est pas justifiée. Souvent les utilisateurs confondent et c'est d'un simple DBAL dont ils ont besoin et non pas d'un ORM. Le choix de l'ORM est souvent une obligation en fait
Je vous invite à lire ceci : http://www.doctrine-project.org/blog/or … t-a-choice
Ça résume bien l'idée.
L'intérêt principal d'un ORM (pour moi) est de pouvoir garder une couche métier consistante sans y ajouter une connaissance de la persistance. Pour certains gros projets (en perpétuelle évolution) c'est très appréciable pour la pérennité du système. Attention par contre, c'est relativement lent, même s'il ne faut pas faire une psychose sur les temps d'exécution. Il faut surtout faire attention à ce qu'on fait, continuer à écrire des requêtes JOIN et ne pas compter sur le lazy loading
Les ORM PHP (contrairement à d'autres langages) ne sont pas encore au point pour répondre à cette problématique. La version actuelle de Doctrine non plus et les entités sont encore liées à la persistance. La version 2 permet elle, par contre, d'avoir une couche métier solide et de faire persister les objets seulement quand nécessaire. Je ne saurais que conseiller pour les nouveaux arrivants sur Doctrine, de commencer directement avec la version 2 et de se faire la main le temps de la bêta.
Dans les autres avantages, je citerai le CLI (avec migrations et fixtures), et certaines fonctionnalités bien pratiques, comme le searchable ou le i18n.
Dans beaucoup de situations Zend_Db suffit largement, il suffit d'être conscient que celà lie très fortement le modèle métier à la persistance puisque c'est la structure de la BDD qui dicte l'orientation du métier. Mais parfois, ce n'est pas gênant du tout, il faut simplement s'attendre, lors d'un changement dans la BDD à devoir repasser par toutes les couches (jusqu'à la vue) pour propager la modification.
J'en reste là philippe, je me retiens :p
A+ benjamin.
Dernière modification par Delprog (19-05-2010 09:39:25)
Hors ligne
Bonjour
l'un n'empêche pas l'autre
on peut très bien utiliser un ORM pour ce qu'il sait faire et bien faire et aussi dans certain cas faire faire des jointures au moteur SQL
faire un jointure n'est pas toujours la bonne solution
prenons un exemple
j'ai une table principale avec 5 champs texte varchar(30) et une table fille avec 10 champs varchar(50)
j'ai en moyenne 500 éléments fils par maitre. et j'ai 1000 maitre
utiliser une jointure va me faire 1 seule requêtes qui vas remonter un volume moyen de donnée de 500 x 30 x 5 + 500 x 50 x 10 par élément maitre les champs maitres étant répliqué à chaque ligne remonté soit donc 1000 x 500 x ( 30 x 5 + 50 x 10 ) = 325 000 000
à contrario sans jointure je vais avoir 1 requête sur la table maitre et autant de requête sur la table fille que d'élément dans la table maitre soit donc 1001 requêtes la première va remonter 5 x 30 x 1000 et les 1000 autres 500 x 50 x 10 soit donc (5 x 30 x 1000) + (1000 x 500 x 50 x 10) = 250 150 000
on vois vite que la surcharge de donnée de la première solution par rapport à la seconde est de 1,2 environ mais que le nombre de requête est d'un rapport de 1 à 1000. le coût global sur le moteur est très largement en faveur de la première solution.
maintenant prenons une table principale de 5 champs 2 varchar(30) et 3 blob de 5 Mo (en moyenne) chacun et une table fille identique à la précédente soit 10 champs varchar(50)
cette fois en moyenne 5 éléments fils par maitre. et j'ai 1000 maitre
la solution de la jointure donne toujours une seule requête avec un poids de
1000 x 5 x ( 1024 x 1024 x 5 x 3 + 30 x 2 + 50 x 10 ) = 78 646 000 000
la solution sans jointure donne
(1024 x 1024 x 5 x 3 + 30 x 2) x 1000 + (1000 x 5 x 50 x 10) = 15 731 200 000 le sur coût est de 4.9 pour la jointure et le rapport des requête est de 1 à 5 en nombre de requêtes
pour 50 fils on à un sur coût en requêtes de 1 à 50 et en poids qui augmente proportionnellement soit 49
ces exemples sont des cas caricaturaux et dans la vrais vie on fait attention de ne remonter que les colonnes nécessaires. mais sur de grosse base il faut faire attention à ce genre de rapport pour la cas précédent avec 5 fils
en imaginant qu'on ait réellement besoin de ses infos le volume de donnée opérationnel est celui donné sans jointure soit environs 18 Mo faire 6 requêtes pour y arriver à un coût mais devoir remonter 78 Go de donnée pour ne faire qu'une seule requête n'est pas l'idéal.
il n'y a donc pas de règles absolue et il convient d'être pragmatique et de bien cibler la nature des données qu'on manipule.
et les organiser d'une façon différente permet de s'affranchir de certain problèmes.
si on reprends l'exemple avec 5 fils
mais on décide de faire une jointure mais en ne remontant que les champs varchar(30) de la table principale et une 2eme requête pour remonter les blob
on obtient
1000 x 5 x ( 30 x 2 + 50 x 10 ) = 2 800 000 pour la jointure
1000 x ( 1024 x 1024 x 5 x 3 ) = 15 728 640 000 pour les blob
soit un total de 15 731 440 000 pour 2 requêtes cela est à comparer avec 15 731 200 000 pour 6 requêtes et 78 646 000 000 pour 1 requête
avec 50 fils
1000 x 50 x ( 30 x 2 + 50 x 10 ) = 28 000 000 pour la jointure
1000 x ( 1024 x 1024 x 5 x 3 ) = 15 728 640 000 pour les blob
soit un total de 15 756 640 000 pour 2 requêtes cela est à comparer avec 15 753 700 000 pour 51 requêtes et 786 460 000 000 pour 1 requête
un seul mot d'ordre adaptez votre stratégie à votre dommaine fonctionnel
A+JYT
Hors ligne
Il me semblait avoir lu que ZF intégrait pourtant la gestion des namespaces PHP et ce depuis longtemps. Ou alors je me trompes....
Hors ligne
Moi, j'utilisais Doctrine avant le ZF
Hors ligne
Hello,
Tiens un qui n'a pas suivi mon webinar sur ZF 1.10 : autrement il saurait que ZF 1.10 intègre une modification de Zend_Loader::loadClass() pour gérer les namespaces suivant la PSR-0 (http://groups.google.com/group/php-stan … l-proposal)
@+
Hors ligne
Salut,
Si moi j'ai suivi ton Webinar d'aujourdhui:), très bien d'ailleurs, mais trop court . Bravo
Sinon, pour revenir à Doctrine, je vois donc que l'utilité de l'inclure à ZF n'est pas forcement flagrante. Ce qui existe déjà suffit amplement pour les petits, et moyens-gros projets.
A savoir, si pour le 2.0, cela ne va pas alourdir tout çà...
Fabrice
Hors ligne
mikaelkael a écrit:
Hello,
Tiens un qui n'a pas suivi mon webinar sur ZF 1.10 : autrement il saurait que ZF 1.10 intègre une modification de Zend_Loader::loadClass() pour gérer les namespaces suivant la PSR-0 (http://groups.google.com/group/php-stan … l-proposal)
@+
Merde, je me suis fait cramer en beauté
Va falloir que j'aille voir tout ca de plus près alors... Car DC2 m'intéresse grandement.
Hors ligne
On trouve aussi adaptateur Zend_Auth pour doctrine
http://framework.zend.com/wiki/pages/vi … Id=3866950
Hors ligne
Pour les utilisateurs de Doctrine 1.2 et des DTO, je viens de publier une implémentation du pattern Transfert Object Assembler : http://www.armetiz.info/transfer-object … octrine-1/
Dernière modification par armetiz (31-05-2010 12:21:27)
Hors ligne
Pages: 1