IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Et vous les ORM ?

Votants
56. Vous ne pouvez pas participer à ce sondage.
  • J'utilise l'ORM du framework

    28 50,00%
  • J'utilise un ORM particulier (précisez)

    11 19,64%
  • Je n'utilise pas d'ORM, j'utilise directement PDO/ODBC

    9 16,07%
  • J'ai écrit mon propre ORM

    4 7,14%
  • ORM késako ??

    4 7,14%
Langage PHP Discussion :

ORM or not ORM faut-il les utiliser ?


Sujet :

Langage PHP

  1. #1
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut ORM or not ORM faut-il les utiliser ?
    Avec l’arrivée des frameworks php, nous avons appris à évoluer entre ces nouveaux acronymes: MVC, DAO, DRY et ORM
    Mais qu’est-ce qu’un ORM ?
    Un ORM (Object Relation Mapping) est un ensemble de librairies qui vous permettent d’interagir avec vos données via des objets.
    La plupart des frameworks respectant le design MVC* intègrent leurs propres ORM plus ou moins performants.
    note: pour les exemples de syntaxes d’ORM j’utiliserai l’ORM du mkFramework.

    *MVC: Model View Controller (séparation de la couche modèle de l’affichage et du contrôleur)

    Un ORM pourquoi faire ?
    Pourquoi utiliser un ORM plutôt que d’écrire simplement des requêtes SQL dans pdo ?
    Si vous voulez coder propre, vous allez dans un premier temps écrire toutes vos requêtes dans un fichier php.
    Si vous souhaitez organiser un peu mieux, vous allez regrouper les requêtes par table…
    Si vous souhaitez éviter de vous répéter, vous aller créer un fichier/une classe pour les éléments récurrents (connexion, requête…) : principe de DRY*
    Le fait de faire ceci, vous avez créé un pseudo début d’ORM

    *DRY Don’t Repeat Yourself (créer des fonctions/classes pour éviter d’écrire plusieurs fois le même code)

    Un des avantages des ORM se situe concernant la manipulation des données.
    Prenons un exemple ou dans plusieurs pages vous devez modifier uniquement le titre, l’auteur ou le nombre de vues d’un article.
    En pdo simple vous écririez:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    ‘UPDATE article SET titre=? WHERE id=?’,$titre,$îd
    ‘UPDATE article SET auteur=? WHERE id=?’,$auteur,$îd
    ‘UPDATE article SET nbVue=nbVue+1 WHERE id=?’,$îd
    Avec l’ORM vous n’avez pas besoin d’écrire à l’avance vos différents types de requêtes
    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    $oArticle=model_Article::getInstance()->findById($id);
    $oArticle->titre=$titre;
    $oArticle->save();
    //ou
    $oArticle->auteur=$auteur;
    $oArticle->save();
    //ou
    $oArticle->nbVue=($oArticle->nbVue+1);
    $oArticle->save();
    note: vous pouvez, si vous le souhaitez écrire des requêtes update
    Exemple:
    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    class model_article extends abstract_model{
    ()
    public function updateNbVue($id){
    $this->execute(‘UPDATE article SET nbVue=nbVue+1 WHERE id=?’,$id);
    }
    }
    Les avantages sont multiples:
    • Organiser vos requêtes
    • Gagner du temps à l’écriture
    • Bénéficier des avantages du design MVC*


    Tous les ORMs n’offrent pas les mêmes performances
    Pour argumenter un post dans un topic sur ce même site, j’avais à l’époque procédé au benchmark suivant:
    100 000 enregistrements en base de données mysql, et l’affichage de ces lignes dans un tableau HTML.
    5 types différents:
    - PHP simple en utilisant pdo
    - une application en Zend Framework (version 1.11.12)
    - une application en Yii (version yii-1.1.14)
    - une application en MkFramework (méthode findMany() )
    - une application en MkFramework en utilisant la récupération rapide (méthode findManySimple() )

    Résultat des courses:
    - 0.50s : pdo simple
    - 0.58s : MkFramework en utilisant la récupération rapide
    - 0.68s : Yii (version yii-1.1.14)
    - 1.97s : MkFramework (normal)
    - 11.20s : Zend Framework (version 1.11.12):

    note : j’ai fait un benchmark sur 100 000 entrées pour avoir un volume assez important pour mettre en évidence les différences de performances, si j’avais fait un findById(4)
    Sur un seul enregistrement on a
    - 0.007s : pdo simple
    - 0.015s : MkFramework en utilisant la récupération rapide
    - 0.043s : MkFramework (normal)
    - 0.049s : Zend Framework

    note 2 pour obtenir de bonnes performances avez yii j’ai écrit les requêtes sans passer par les classes « ORM »
    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    $sql=’SELECT * FROM Article’;
    $connection=Yii::app()->db; // vous devez avoir une connection « db »
    $command=$connection->createCommand($sql);
    $articles=$rows=$command->queryAll();
    note 2: j’ai fait un benchmark sur 100 000 entrées pour avoir un volume assez important pour mettre en évidence les différences de performances, si j’avais fait un findById(4)

    Les ORMs offrent de la flexibilité
    J’ai lu à plusieurs reprise que les ORM étaint lourd, qu’ils retournaient toujours toutes les colonnes même ceux non utilisées, que pour faire une jointure on se retrouvait à récupérer une ligne entière sur les deux tables liés…
    Premièrement, vous pouvez choisir de récupérer uniquement certains champs de votre table. Beaucoup d’ORM proposent d’écrire sa requête SQL
    Par exemple:

    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    class model_article extends abstract_model{
    ()
    public function findListAuteurName(){
    return $this->findMany(‘SELECT auteur.name FROM auteur’);
    }
    }

    Idem pour les fameuses jointures, vous avez le choix de récupérer par exemple un objet article puis de lui demander de nous retourner son auteur pour afficher son nom ainsi

    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    $oArticle=model_article::getInstance()->findById(4);
    print $oArticle->findAuteur()->nom;

    Mais vous pouvez également écrire une méthode qui vous retournera les articles avec leur auteurs

    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    class model_article extends abstract_model{
    ()
    public function findArticleWithAuteur(){
    return $this->findOne(‘SELECT article.titre, auteur.name FROM article INNER JOIN auteur ON article.auteur_id=auteur.id WHERE article.id=?’,(int)$id);
    }
    }

    Une flexibilité aussi concernant les performances: selon les parties de vos sites vous avez besoin de récupérer plus ou moins d’élements et ceci plus ou moins rapidement.
    La encore vous avez le choix: si vous devez récupérer un auteur, ses articles et ceci sans trop regarder les performances vous pouvez utiliser la méthode de récupération d’objets riches findMany/findOne
    Si au contraire vous souhaitez afficher un bon nombre d’article d’auteurs, ou autre, vous pouvez utiliser la méthode rapide retournant des objets « simple » findManySimple/findOneSimple

    Vous avez le choix

    Conclusion
    Comme vous avez pu le lire ici, tous les ORM ne sont pas des usines à gaz, ils sont très pratiques et vous permettent dans l’esprit du MVC de bien organiser votre couche modèle.
    Les ORM sont une bonne chose que vous codiez une petite application ou une application importante: l’essentiel c’est de penser à long terme (la maintenabilité).
    Il sera plus simple pour vous ou un collègue d’intervenir sur votre application avec ORM que sans ORM
    Certains ORM sont plus ou moins flexible et performants comme les frameworks, mais ne les mettez pas tous dans le même panier, essayez en plusieurs avant de vous faire un avis.

    note: je n’ai pas inclus Symfony 2 (pour tester doctrine) dans le benchmark, car malgré mes efforts d’optimisation de cache, mode production… je n’arrivais pas à passer sous la barre des 23 secondes
    Si vous pouvez m’envoyer un exemple d’application affichant ces 100 000 enregistrements en moins de 2 secondes je suis preneur

    note2: retrouvez dans mon post d’origine les éléments du benchmark (sauf celui de yii fait ici pour l’occasion)
    http://www.developpez.net/forums/d12...u/#post6847792


    Le billet: http://blog.developpez.com/ducodeetd...l-les-utiliser

    Ci-joint les fichiers logs complets (réalisé via la commande time et wget 10 fois de suite)

    Et vous ? utilisez vous un ORM si oui lequel ?
    Si non qu'utilisez vous ? pdo ? odbc ? fonction spéciale (mysql_connect, myqli,oci_connect...)
    Fichiers attachés Fichiers attachés
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  2. #2
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 441
    Points
    2 441
    Par défaut
    J'utilise Doctrine quand je fais de l'objet, et PDO pour le reste.

    Par curiosité, est-ce que tu as pensé à faire un benchmark avec le même framework, mais en utilisant différents ORMs? Cela permettrait de mieux isoler les performances de chaque ORM de la "lourdeur" inhérente à chaque framework.

  3. #3
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut
    Non j'avoue ne pas avoir "isoler" les performances de l'ORM en lui-même: utilisant leur propre ORM je ne sais pas si on peut les croiser

    Sinon Doctrine est un bon ORM, je ne l'ai pas inclus dans ce billet qui parle plus des ORM des frameworks: sur leur site je n'ai pas réussi à reproduire un exemple réel d'ORM juste de la DAO (retournant un fetch de pdo )

    C'est pour cela d'ailleurs que pour le mkframework il y a deux logs: un en mode simple (retournant des objets stdclass : plus DAO) et l'autre retournant un vrai objet ORM pour pouvoir bien comparer à ZF
    Mais pour yii (ne le connaissant que très peu) j'ai eu du mal à avoir le même cas, obligé d'écrire en "DAO" la requête
    En passant pas le générateur de CRUD il me pondait un objet activeRecord un peu obscur affichant une pagination (perte d'intérêt du benchmark ici...)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  4. #4
    Futur Membre du Club
    Profil pro
    Inscrit en
    janvier 2007
    Messages
    2
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 2
    Points : 6
    Points
    6
    Par défaut
    Dommage que le bench ne compare pas les même choses, ni les bonnes choses !!

    D'une avec un ORM c'est vraiment un non sens de récupérer 100 000 objets, l'ORM va récupérer les données depuis la BDD puis "remplir" 100 000 objets correspondants, forcément ça créer une charge supplémentaire très importante par rapport à un pdo classique !! Ce n'est vraiment pas un scénario réaliste donc ca n'apporte pas grand chose pour quelqu'un qui voudrait faire un choix à partir de ces données de test. En général pour ce genre de cas les ORM propose des modes qui permettent de s'affranchir de cette phase de "remplissage" et de gagner beaucoup en perf !

    Ensuite pour Yii ne pas utiliser les classes d'ORM ça ne sert juste à rien puisque le but est d'évaluer l'ORM. Pour le test donnée c'est équivalent à du pdo simple avec une légère surcharge pour les classes de connections et d’exécution de la requête. C'est un peu comme si on faisait un bench de framework pour le rendu d'1 fichier html statique

    Enfin comme noté par Tsilefy, avec ce bench je peux prendre le meilleur ORM du monde et le mettre dans un framework tout pourri et les résultats seront mauvais alors que peut etre l'ORM en lui même est excellent

  5. #5
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut
    Citation Envoyé par rasta tom
    D'une avec un ORM c'est vraiment un non sens de récupérer 100 000 objets, l'ORM va récupérer les données depuis la BDD puis "remplir" 100 000 objets correspondants, forcément ça créer une charge supplémentaire très importante par rapport à un pdo classique !! Ce n'est vraiment pas un scénario réaliste donc ca n'apporte pas grand chose pour quelqu'un qui voudrait faire un choix à partir de ces données de test. En général pour ce genre de cas les ORM propose des modes qui permettent de s'affranchir de cette phase de "remplissage" et de gagner beaucoup en perf !
    Oui c'est un test simple avec beaucoup d'enregistrements qui permet de mettre en evidence la perte du à cet aspect d'objets intelligents.
    On peut ainsi voir la différence de performance sur une requete simple
    Après comme vous le dites, certains frameworks permettent de récupérer de manière plus rapide des enregistrements (c'est le cas avec yii et le mkf en mode rapide)

    Citation Envoyé par rasta tom
    Ensuite pour Yii ne pas utiliser les classes d'ORM ça ne sert juste à rien puisque le but est d'évaluer l'ORM. Pour le test donnée c'est équivalent à du pdo simple avec une légère surcharge pour les classes de connections et d’exécution de la requête. C'est un peu comme si on faisait un bench de framework pour le rendu d'1 fichier html statique
    Pour yii comme je le disais je n'ai pas trouvé comment récupérer des objets riches, je n'ai trouvé via le crud que comment récupérer cet objet "active record" qui m'affichait de manière paginé les enregistrements (perte d'interet s ici)
    Et pour Zend Framework on voit une sacré différence de performance (et je n'affiche pas ici la différence de mémoire utilisée)

    Citation Envoyé par rasta tom
    Enfin comme noté par Tsilefy, avec ce bench je peux prendre le meilleur ORM du monde et le mettre dans un framework tout pourri et les résultats seront mauvais alors que peut etre l'ORM en lui même est excellent
    Comme je l'ai dit plus haut, je compare des ORM de frameworks donc c'est normal de faire ainsi, après j'aurais bien aimé inclure SF2 avec doctrine mais cf mon explication je n'arrivais pas à des performances raisonnable
    Que j'associe plus à ma méconnaissance du SF2 (et de son paramétrage)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  6. #6
    Membre averti

    Homme Profil pro
    Développeur informatique
    Inscrit en
    mars 2007
    Messages
    186
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Alpes de Haute Provence (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : mars 2007
    Messages : 186
    Points : 399
    Points
    399
    Par défaut
    Certes les ORM ralentissent l’exécution du code, cependant il faut les utiliser a bon escient. C'est a dire dans des projets ou ajouter un niveau d'abstraction a du sens.

    Un projet avec plusieurs dizaines d'entités et de relations entre-elles ne se portera que mieux avec un ORM même si ils sont lourd.

    Reste ensuite a utiliser les ORM correctement, sinon on se retrouve avec des charge monstrueuses oui. Par contre, bien utilisé on gagne de très nombreuses heures en maintenabilité et évolutivité...

  7. #7
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut

    Il faut toujours faire la balance entre la perte de performance d'un coté et le gain de confort tant à la création qu'à la maintenabilité
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  8. #8
    Membre expérimenté
    Homme Profil pro
    Développeur Web
    Inscrit en
    juillet 2009
    Messages
    420
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : juillet 2009
    Messages : 420
    Points : 1 435
    Points
    1 435
    Par défaut
    J'utilise Doctrine puisque je travaille avec Symfony.
    L'ORM apporte un confort dont j'aurai du mal à me passer dans l'absolue. Maintenant, c'est vrai qu'il peut être à l'origine de certaines lourdeurs. Cependant, mon expérience tend à montrer que ces situations représentent presque toujours des cas dans lequel l'ORM n'est pas aussi indispensable.
    Aussi, je pense qu'utiliser un ORM dans un projet objet est une bonne chose, mais il ne faut pas s'abstenir de coupler son usage avec du PDO selon le besoin.

    En clair, il n'y a pas de ORM VS PDO, mais une bonne utilisation des deux selon le besoin.

  9. #9
    Futur Membre du Club
    Homme Profil pro
    Directeur technique
    Inscrit en
    août 2013
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Directeur technique
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : août 2013
    Messages : 18
    Points : 6
    Points
    6
    Par défaut Selon les cas
    Difficile à dire comme souvent avec ce genre de question.
    Il y a les pour et les contre.

    L'ORM oui! Mais lorsqu'il s'agit d'une application entreprise. Que les performance ne soit pas impérative. Que le nombre de QPS reste faible.
    Quand le temps que me fait gagner l'ORM est supérieur au temps perdu par mes client pour cause d'ORM.

    l'ORM, j'adore. C'est magique. Mais j'y vois deux problème major:
    - Une logique simple ce traduit souvent pas énormément de requêtes simplissime. ENORMEMENT de requêtes simplissime.
    - Cette technique camoufle trop la logique interne. L'abstraction fait gagner un temps précieux. Mais lorsque il faut optimiser un requête ou comprendre un bug, le temps gagner grâce à l'ORM est perdu. On ce retrouve à faire des hack monstrueux.


    Les ORM sont trop souvent choisis en espérant avoir quelque chose de simple, de plus rapide à developer sans trop dégrader les performance.
    - Simple: Oui, oui, oui !
    - Rapide à développer: oui si on n'en fait pas une utilisation exotique.
    - performant: non, non, non (ou à grand coup de hack)


    Deux axes d'amélioration:
    - Utiliser une BDD NoSQL de type document oriented tel que CouchDB ou MongoDB.
    En gérant les entités on fait des read/save/update/delete d'une seul coup. Le travail de l'ORM est largement simplifier.

    - Faire du ORM semi-manager type "SQL mapping framework". CAD écrire les requêtes SQL et définir un mappaging en objet. Avoir la main sur les requêtes permet d'améliorer les performance et évite les requettes "idiote" des ORM.
    Exemple: mybatis (Java), Soma (C#) ...


    Martin Magakian

  10. #10
    Membre à l'essai
    Homme Profil pro
    Développeur .NET
    Inscrit en
    octobre 2008
    Messages
    14
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : octobre 2008
    Messages : 14
    Points : 16
    Points
    16
    Par défaut
    Dans l'environnement .net ce ne sont pas les ORM qui manquent : http://en.wikipedia.org/wiki/List_of...pping_software

    J'utilise petaPoco pour les projets simple et courts, EF pour les petits projets, un peu de LinqToSQL pour certains clients, et un fait maison sur quelques projets particuliers.

    Côté perf effectivement les ORM sont souvent inégaux : voir ici.

    Ensuite je pense sincèrement que c'est une très bonne technologie, mais pas la réponse à tout (perdre la main sur le SQL n'est jamais une bonne chose) et surtout qu'un ORM ne peut pas répondre à tous les besoins ; ils ont des spécialités.

  11. #11
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 441
    Points
    2 441
    Par défaut
    Alternative aux axes d'amélioration de Martin: utiliser des caches, ajouter de la RAM et augmenter le nombre de CPU.

    Évidemment ça varie selon les projets, mais entre le coût de la RAM et des CPUs supplémentaires et le coût du développement et de la maintenance hors ORM, ajouter du matériel peut être plus intéressant.

  12. #12
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 441
    Points
    2 441
    Par défaut
    Citation Envoyé par imikado Voir le message
    Non j'avoue ne pas avoir "isoler" les performances de l'ORM en lui-même: utilisant leur propre ORM je ne sais pas si on peut les croiser
    Oui, on peut tout à fait utiliser Doctrine2, Propel ou Eloquent (l'ORM de Laravel) dans n'importe quelle autre application PHP. Fini le temps des Framework lourds, l'heure est aux composants découplés :-)

  13. #13
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut
    Oui on peut utilliser les ORMs de manière indépendante, mais l'idée des frameworks c'est de rassembler tous ces designs patterns et bonnes idées tel que MVC / ORM / DRY ... l'ORM fait partie du package

    Après pour les performances, comme vous avez pu le voir non seulement tous les ORMs ont des performances différentes, mais de plus certains ORM permettent de récupérer des objets "simple" ce qui fait beaucoup gagner en performance
    Une seconde solution c'est d'user et abuser de cache
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  14. #14
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 300
    Points : 3 583
    Points
    3 583
    Billets dans le blog
    12
    Par défaut
    Il y a plusieurs choses qu'un ORM ne peut pas résoudre contrairement à PDO/ODBC/JDBC : les requêtes de sélection un peu complexe, ou bien les connexions à divers SGBD en même temps par exemple.

    Aussi, le but d'un ORM n'est pas d'enregistrer/récupérer 100 000 tuples dans une base. Généralement on se sert de la pagination (ex: récupérer les 20 premiers messages de ce topic).

    Cette article n'est malheureusement pas neutre, il n'y a pas de pour et contre concernant les ORM, mais que du pour. Au vu de ces benchmarks, cet article fait un peu pub du framework MkFramework.

    Je vous renvoie à un excellent article d'aout 2012 concernant les ORM sur developpez.com.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  15. #15
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    Il y a plusieurs choses qu'un ORM ne peut pas résoudre contrairement à PDO/ODBC/JDBC : les requêtes de sélection un peu complexe, ou bien les connexions à divers SGBD en même temps par exemple.
    Vous avez loisir pour écrire vos propres requêtes SQL aussi complexe qu'elles soient : tous les ORM proposent la possibilité d'écrire sa requête SQL.
    Pour les relations inter SGBD vous pouvez avoir plusieurs profils de connexions et indiquer pour chaque table quel profil utiliser et ainsi stoquer par exemple vos articles sur mysql et vos auteurs sur sqlite

    Citation Envoyé par Gugelhupf Voir le message
    Aussi, le but d'un ORM n'est pas d'enregistrer/récupérer 100 000 tuples dans une base. Généralement on se sert de la pagination (ex: récupérer les 20 premiers messages de ce topic).
    Comme indiqué dans le billet, je fais un benchmark sur 100 000 tuples pour avoir du volume et ainsi mieux mettre en évidence les différences de performances: avec 20 tuples les différences auraient été moins flagrantes
    De plus avec moins de tuples on aurait pas vraiment su si c'était le framework qui mettait du temps ou l'ORM

    Citation Envoyé par Gugelhupf Voir le message
    Cette article n'est malheureusement pas neutre, il n'y a pas de pour et contre concernant les ORM, mais que du pour. Au vu de ces benchmarks, cet article fait un peu pub du framework MkFramework.
    Je suis désolé du coup de pub mais je suis toujours attristé de ne pas voir le mkFramework dans les benchmarks que je peux lire à droite à gauche, j'en ai profité ici pour l'inclure au même titre que ZF et Yii, je suis désolé encore une fois de ne pas avoir mis Symfony 2 car n'ayant pas réussi a avoir des performances en dessous des 22-23 secondes
    Mais pour rappel ce n'est pas un article benchmark sur les ORM c'est un article sur le fait d'utiliser ou non les ORM et la partie benchmark est une toute petite partie concernant les performances différentes entre chaque ORM

    Personnellement j'ai commencé il y a quelque sannées avec symfony beta 1 qui utilisait propel et j'ai pu voir en utilisant par la suite Zend Framework des différences de performances, parallèlement je developpais mon propre framework en essayant de faire un bon compromis entre un ORM confortable et performant

    Mais suite aux commentaires ici, sur google+... j'écrirais prochainement un article spécialement de benchmpark d'ORM où je testerais plus de points: jointure, récupérations cross tables (par exemple à partir d'un auteur afficher ses articles/commentaires...)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  16. #16
    Nouveau membre du Club
    Profil pro
    Inscrit en
    octobre 2011
    Messages
    71
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : octobre 2011
    Messages : 71
    Points : 39
    Points
    39
    Par défaut
    J'aime le langage SQL ! Donc je n'utilise pas d'ORM car c'est un vrai plaisir de pondre du SQL !!!

    Et dire que maintenant, beaucoup de personnes se disant "programmeur" connaissent uniquement "les base"s du langage SQL. Une honte !!

  17. #17
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 300
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 300
    Points : 3 583
    Points
    3 583
    Billets dans le blog
    12
    Par défaut
    Vous avez loisir pour écrire vos propres requêtes SQL aussi complexe qu'elles soient : tous les ORM proposent la possibilité d'écrire sa requête SQL.
    Je ne sais pas comment c'est avec les autres ORM, mais de souvenir avec Doctrine2 et son DQL, il n'y a pas l'équivalent de l'instruction standard SQL "CASE WHEN", pas de "LIMIT" (qu'on aurait pu utiliser dans une sous-requête par exemple), et pas de fonction équivalent à TO_DATE et TO_CHAR qu'on peut trouver dans PostgreSQL ou Oracle...

    Donc même s'il est possible d'écrire sa requête "SQL" avec un ORM, je trouve que ça reste assez limité.
    Je n'ai rien contre les ORM, c'est bien sympa pour faire du INSERT|UPDATE|DELETE et les SELECT simples, mais ça n'arrive pas à la cheville du SQL lorsqu'on veut récupérer des données sous une certaine forme.


    je fais un benchmark sur 100 000 tuples pour avoir du volume et ainsi mieux mettre en évidence les différences de performances
    C'est bien ça le problème, quand je lis le titre de l'article « ORM or not ORM » : faut-il les utiliser ou continuer d'écrire simplement des requêtes SQL ? je ne m'attends pas à une série de benchmark d'ORM mais un débat sur le pour ou contre, et les raisons qui poussent à leur utilisation ou non.
    D'ailleurs, faire un benchmark sur un SELECT simple d'une table c'est un peu du pipi de chat, faudrait faire cela avec une requête plus compliqué.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  18. #18
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    Je ne sais pas comment c'est avec les autres ORM, mais de souvenir avec Doctrine2 et son DQL, il n'y a pas l'équivalent de l'instruction standard SQL "CASE WHEN", pas de "LIMIT" (qu'on aurait pu utiliser dans une sous-requête par exemple), et pas de fonction équivalent à TO_DATE et TO_CHAR qu'on peut trouver dans PostgreSQL ou Oracle...

    Donc même s'il est possible d'écrire sa requête "SQL" avec un ORM, je trouve que ça reste assez limité.
    Je n'ai rien contre les ORM, c'est bien sympa pour faire du INSERT|UPDATE|DELETE et les SELECT simples, mais ça n'arrive pas à la cheville du SQL lorsqu'on veut récupérer des données sous une certaine forme.
    Il doit y avoir un quiproquo: vous pouvez écrire votre requete complète avec les case when to_char... ils proposent la possibilité d'écire vous-même la requete

    Citation Envoyé par Gugelhupf Voir le message
    C'est bien ça le problème, quand je lis le titre de l'article « ORM or not ORM » : faut-il les utiliser ou continuer d'écrire simplement des requêtes SQL ? je ne m'attends pas à une série de benchmark d'ORM mais un débat sur le pour ou contre, et les raisons qui poussent à leur utilisation ou non.
    J'indique les raisons qui poussent à l'utiliser:
    Un ORM pourquoi faire ?
    (...)
    Un des avantages des ORM se situe concernant la manipulation des données.
    Organiser vos requêtes
    Gagner du temps à l’écriture
    Bénéficier des avantages du design MVC
    (...)
    Les ORM sont une bonnes choses que vous codiez une petite application ou une application importante: l’essentiel c’est de penser à long terme (la maintenabilité).
    Il sera plus simple pour vous ou un collègue d’intervenir sur votre application avec ORM que sans ORM
    Citation Envoyé par Gugelhupf Voir le message
    D'ailleurs, faire un benchmark sur un SELECT simple d'une table c'est un peu du pipi de chat, faudrait faire cela avec une requête plus compliqué.
    Je le répète c'est un simple benchmark pour voir ce que l'on perd rien qu'avec des requêtes simples en utilisant un ORM et selon l'ORM choisi: si juste avec un simple select on obtient ces différences de performances, on peut facilemnent imaginer avec des requetes plus complexe

    Mais comme je l'ai dit, j'écrirais quand j'aurais un peu de temps un article spécial benchmark où je testerai plus d'ORM et dans plus de cas plus ou moins complexe
    Mais pour cela, il faut que j'arrive à faire une application sf2 qui passe sous les 20 secondes avec ce tests, sinon, ça ne sert à rien de continuer pour sf2 (les performances ne seront pas révélatrices...)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  19. #19
    Membre émérite

    Profil pro
    Inscrit en
    mai 2008
    Messages
    1 575
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mai 2008
    Messages : 1 575
    Points : 2 441
    Points
    2 441
    Par défaut
    Citation Envoyé par Gugelhupf Voir le message
    Je ne sais pas comment c'est avec les autres ORM, mais de souvenir avec Doctrine2 et son DQL, il n'y a pas l'équivalent de l'instruction standard SQL "CASE WHEN", pas de "LIMIT" (qu'on aurait pu utiliser dans une sous-requête par exemple), et pas de fonction équivalent à TO_DATE et TO_CHAR qu'on peut trouver dans PostgreSQL ou Oracle...
    Il y a la classe NativeQuery pour les SELECTs pour utiliser du Sql dans Doctrine2

  20. #20
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Ingénieur développement
    Inscrit en
    décembre 2006
    Messages
    5 235
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur développement
    Secteur : Finance

    Informations forums :
    Inscription : décembre 2006
    Messages : 5 235
    Points : 19 557
    Points
    19 557
    Billets dans le blog
    17
    Par défaut
    Citation Envoyé par Gugelhupf
    Contre :
    Pour ma part ayant déjà utilisé Doctrine, je trouve qu'on est techniquement limité pour faire des requêtes complexes, il faut alors passer par le DQL (requête doctrine, équivalent de HQL pour Hibernate), et là encore je ne suis pas sur d'arriver à ce que je veux.
    Bien sur il y a cette grosse couche d'abstraction qui peut nuire aux performances... et d'après ce que j'ai compris un ORM peut effectuer plus de requête que nécessaire parfois.
    Bien maitriser un ORM demande beaucoup de temps de formation (les entités, les annotations, les contraintes...).
    Pour répondre à votre post concernant l'article que vous avez indiqué:

    Techniquement limité : comme on vient de vous l'indiquer, on peut écrire nos propres requetes SQL dans les ORM
    performances cela dépend des ORM, sur certains on perd très peu en performance alors que l'on gagne beaucoup en confort, organisation et maintenabilité
    temps de formation idem : cela dépend des ORM, certains demande au plus 5 minutes de formation, le temps d'apprendre les 2-3 méthodes à utiliser
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

Discussions similaires

  1. Réponses: 6
    Dernier message: 23/05/2015, 18h35
  2. Récupérer variables d'1 <form> et les utiliser dans X
    Par honeyz dans le forum XSL/XSLT/XPATH
    Réponses: 3
    Dernier message: 20/04/2006, 11h39
  3. [Properties] comment les utiliser ?
    Par Kyti dans le forum Collection et Stream
    Réponses: 6
    Dernier message: 25/03/2005, 10h37
  4. Réponses: 7
    Dernier message: 13/03/2005, 16h45
  5. Réponses: 5
    Dernier message: 05/10/2004, 13h05

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo