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. #41
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    Une base de données relationnelle est une collection de lignes de données dans des tables et non pas une collection d'objets instanciant des classes.

    Un mapping objet sert à naviguer d'objet en objet. Chaque objet est chargé avec l'intégralité d'une ligne d'une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l'objet du mapping chargera toujours toutes les colonnes.

    Par comparaison, le SQL sert à sélectionner les valeurs des cellules dont on a besoin et uniquement celles-là. Et ça tombe bien car il est rare d'avoir besoin simultanément de toutes les colonnes d'une table dans une même portion du programme.

    En SQL nous effectuons des jointures afin de ramener en une requête telle cellule d'une table couplée à telle autre d'une autre table. Alors que dans le même temps un ORM ramène brutalement en deux requêtes séparées deux lignes entières.

    Certes les ORM proposent tous une solution paliative, une sorte de sous-SQL bridé, avec lequel il devient possible d'extraire des valeurs sans passer par les objets. Mais c'est de l'inversion des bonnes pratiques qu'il s'agit. Bien utiliser un ORM, c'est utiliser par défaut les objets du mapping et ne pratiquer le sous-SQL que dans des cas qui le justifient. Bien utiliser le SQL, c'est ne charger que les données dont on a besoin, systématiquement. Le débat ORM vs SQL porte non pas sur ce qu'on peut faire - on peut faire des objets et des tableaux avec un ORM autant qu'en SQL - mais quelles sont les bonnes pratiques en matière de base de données.

  2. #42
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    Au-delà des considérations générales, il existe un impact négatif en PHP sur l'utilisation systématique d'objets. Selon moi cela suffit à changer de perspective par rapport à d'autres langages : les bonnes pratiques en PHP ne sont pas les mêmes que celles en Java. Le cœur de PHP est le tableau PHP. Et ça tombe bien car le SQL est fait pour ramener des tableaux. Alors pour la simplicité et la performance, restons-en à l'essentiel : le couple SQL-tableau PHP.

  3. #43
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 221
    Points
    2 221
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    C'est ne pas penser à ceux qui au contraire ont une faible expérience en SQL (voir pas du tout) et qui seront surement plus à l'aise avec un ORM...

    Ca me fait penser au débat ligne de commande/interface graphique
    Je ne suis pas persuadé qu'apprendre HQL soit fondamentalement plus facile qu'apprendre SQL. On ne fait donc que repousser le problème.

  4. #44
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 221
    Points
    2 221
    Par défaut
    Citation Envoyé par imikado Voir le message
    Je le répète les ORM permettent de saisir nos propres requêtes
    Par exemple il nous est arrivé dans nos ORM d'appeler des procédures stoquées pour gagner en performance, mais aussi des vues et autres requetes plus complexe

    Il est assez rare en entreprise de migrer le SGBD d'un projet on peut donc écrire sans trop s'inquiéter des requêtes en utilisant les avantages du SGBD choisi
    Si c'est pour finir par faire du SQL, je ne vois pas l'intérêt de faire du SQL. Je travaille justement en ce moment sur un projet utilisant Hibernate et qui est entièrement fait avec des native queries (du SQL, quoi). Et justement, il s'agit de passer d'Oracle à MySQL, ce qui est bien le seul intérêt d'un ORM à mes yeux. En l'occurrence, je ne comprends pas à quoi sert Hibernate dans le projet. On va devoir valider toutes les requêtes SQL pour être sûr qu'elles marchent avec MySQL. Hibernate ajoute simplement un niveau de complexité supplémentaire dont on se passerait bien, finalement.

  5. #45
    Inactif  
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2009
    Messages
    1 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 1 083
    Points : 1 231
    Points
    1 231
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Je ne suis pas persuadé qu'apprendre HQL soit fondamentalement plus facile qu'apprendre SQL. On ne fait donc que repousser le problème.
    C'est plus transparent dans un développement que d'y mettre des lignes SQL et une barda de lignes pour la connexion, etc...

    Mais je connais pas HQL....

  6. #46
    Inactif  
    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2009
    Messages
    1 083
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2009
    Messages : 1 083
    Points : 1 231
    Points
    1 231
    Par défaut
    Citation Envoyé par Traroth2 Voir le message
    Si c'est pour finir par faire du SQL, je ne vois pas l'intérêt de faire du SQL. Je travaille justement en ce moment sur un projet utilisant Hibernate et qui est entièrement fait avec des native queries (du SQL, quoi). Et justement, il s'agit de passer d'Oracle à MySQL, ce qui est bien le seul intérêt d'un ORM à mes yeux. En l'occurrence, je ne comprends pas à quoi sert Hibernate dans le projet. On va devoir valider toutes les requêtes SQL pour être sûr qu'elles marchent avec MySQL. Hibernate ajoute simplement un niveau de complexité supplémentaire dont on se passerait bien, finalement.
    Le souci c'est que tu vois ça comme une couche complexe parce que tu préfères utiliser le langage SQL...

    C'est comme un barbu qui trouve que l'interface graphique c'est une couche complexe...il a tort ou raison ?

  7. #47
    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 Traroth2 Voir le message
    Si c'est pour finir par faire du SQL, je ne vois pas l'intérêt de faire du SQL. Je travaille justement en ce moment sur un projet utilisant Hibernate et qui est entièrement fait avec des native queries (du SQL, quoi). Et justement, il s'agit de passer d'Oracle à MySQL, ce qui est bien le seul intérêt d'un ORM à mes yeux. En l'occurrence, je ne comprends pas à quoi sert Hibernate dans le projet. On va devoir valider toutes les requêtes SQL pour être sûr qu'elles marchent avec MySQL. Hibernate ajoute simplement un niveau de complexité supplémentaire dont on se passerait bien, finalement.
    L'intérêt de l'ORM :
    - organiser les requetes SQL (on groupe les requetes pas table/entité concerné)
    - la flexibilité sur la manipulation (on recupere un objet, on met des champs à jour et on sauvegarde)
    - on profite des avantages du MVC
    - profitez du DRY *

    *DRY : Don't Repeat Yourself. Par exemple une chose toute bête: vous souhaitez récupérer tous les articles d'un auteur donné.
    Si vous faites du sql pure, vous allez écrire votre requete dans la page d'affichage des articles de l'auteur, et si vous avez besoin à un autre endroit de faire la même chose vous allez devoir recopier ce bout de code
    L'avantage avec un ORM c'est ici, dans la classe de l'article vous allez ajouter une fois une requete recuperant les entrées d'un auteur passé en variable.
    Vous pourrez l'appeler de n'importe ou à n'importe quel moment, et si pour une raison ou une autre il y a des changements à faire vous modifierez uniquement cette méthode


    Citation Envoyé par laffreuxthomas
    Une base de données relationnelle est une collection de lignes de données dans des tables et non pas une collection d'objets instanciant des classes.

    Un mapping objet sert à naviguer d'objet en objet. Chaque objet est chargé avec l'intégralité d'une ligne d'une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l'objet du mapping chargera toujours toutes les colonnes.

    Par comparaison, le SQL sert à sélectionner les valeurs des cellules dont on a besoin et uniquement celles-là. Et ça tombe bien car il est rare d'avoir besoin simultanément de toutes les colonnes d'une table dans une même portion du programme.

    En SQL nous effectuons des jointures afin de ramener en une requête telle cellule d'une table couplée à telle autre d'une autre table. Alors que dans le même temps un ORM ramène brutalement en deux requêtes séparées deux lignes entières.
    Vous pouvez le faire aussi
    Dans mes projets il m'arrive d'avoir besoin de joindre N tables.
    Prenons par exemple une table lié à une catégorie et un auteur:
    Vous avez le choix soit de faire appel à l'objet article et lui demander de vous retourner l'objet catégorie et auteur, soit écrire une methode qui vous retourne un objet article riche contenant exactement les champs demandés
    C'est souple un ORM : vous avez le choix
    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. #48
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    Citation Envoyé par imikado Voir le message
    Si vous faites du sql pure, vous allez écrire votre requete dans la page d'affichage des articles de l'auteur, et si vous avez besoin à un autre endroit de faire la même chose vous allez devoir recopier ce bout de code
    Allons, la factorisation est dans la nature du bon programmeur. L'ORM est une factorisation automatisée, elle est loin d'être la plus élégante.

    Citation Envoyé par imikado Voir le message
    soit écrire une methode qui vous retourne un objet article riche contenant exactement les champs demandés
    C'est souple un ORM : vous avez le choix
    Et si nous n'avons pas besoin de toutes les colonnes de la table Article ?

    Alors il nous faudrait implémenter un objet Article "pauvre" qui aurait perdu des propriétés ?

    C'est surement possible d'une manière ou d'une autre. Mais tout cela nous pouvons aussi le faire en utilisant SQL. D'où la conclusion de mon post : ce débat ne concerne pas ce qu'on peut faire, mais ce qu'il est mieux de faire.

  9. #49
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 221
    Points
    2 221
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    Le souci c'est que tu vois ça comme une couche complexe parce que tu préfères utiliser le langage SQL...

    C'est comme un barbu qui trouve que l'interface graphique c'est une couche complexe...il a tort ou raison ?
    Dans un système, toute couche ajoute de la complexité. On l'accepte à cause des services dont on bénéficie. Là, si on utilise Hibernate, mais qu'on fait tout en SQL quand même, je ne vois pas quel service rend l'ORM.

  10. #50
    Membre chevronné

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 221
    Points
    2 221
    Par défaut
    Citation Envoyé par imikado Voir le message
    L'intérêt de l'ORM :
    - organiser les requetes SQL (on groupe les requetes pas table/entité concerné)
    - la flexibilité sur la manipulation (on recupere un objet, on met des champs à jour et on sauvegarde)
    - on profite des avantages du MVC
    - profitez du DRY *

    *DRY : Don't Repeat Yourself. Par exemple une chose toute bête: vous souhaitez récupérer tous les articles d'un auteur donné.
    Si vous faites du sql pure, vous allez écrire votre requete dans la page d'affichage des articles de l'auteur, et si vous avez besoin à un autre endroit de faire la même chose vous allez devoir recopier ce bout de code
    L'avantage avec un ORM c'est ici, dans la classe de l'article vous allez ajouter une fois une requete recuperant les entrées d'un auteur passé en variable.
    Vous pourrez l'appeler de n'importe ou à n'importe quel moment, et si pour une raison ou une autre il y a des changements à faire vous modifierez uniquement cette méthode



    Vous pouvez le faire aussi
    Dans mes projets il m'arrive d'avoir besoin de joindre N tables.
    Prenons par exemple une table lié à une catégorie et un auteur:
    Vous avez le choix soit de faire appel à l'objet article et lui demander de vous retourner l'objet catégorie et auteur, soit écrire une methode qui vous retourne un objet article riche contenant exactement les champs demandés
    C'est souple un ORM : vous avez le choix
    Mais là, on ne parle pas d'ORM, alors, mais de framework de persistance. MyBatis fait tout ce que tu dis très bien, et n'a pas la complexité de Hibernate.

  11. #51
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    Le souci c'est que tu vois ça comme une couche complexe parce que tu préfères utiliser le langage SQL...

    C'est comme un barbu qui trouve que l'interface graphique c'est une couche complexe...il a tort ou raison ?
    Il y a de ça effectivement. Avec une différence. Le client final est l'utilisateur de l'interface graphique. Même s'il gagnerait en efficacité en se formant à la ligne de commande, c'est lui le roi, et c'est au programmeur d'adapter le logiciel. Le client d'un ORM est le développeur objet, il n'est pas un client final et n'est donc qu'un sous-roi : si son logiciel est moins efficace que celui de la concurrence, un jour cela se verra et il disparaitra.

    L'ORM est une erreur conceptuelle. La conception d'un schéma d'une DB obéit à des règles qui n'ont rien à voir avec celles de la programmation à objets. Mieux vaut concevoir ses objets avec une approche "métier", je veux dire que les objets devraient être conçus en fonction de ce que le logiciel doit faire et non pas en fonction des règles de normalisation. C'est un peu comme si la boutique devait organiser ses étalages en fonction des rayons de son entrepôt. Mais les étalages devraient être gouvernés par le marketing alors que les entrepôts sont organisés par la logistique.

  12. #52
    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
    @laffreuxthomas Justement la factorisation est le propre de l'ORM, et les frameworks permettent de générer les diverses classes nécessaires

    Citation Envoyé par laffreuxthomas
    Et si nous n'avons pas besoin de toutes les colonnes de la table Article ?

    Alors il nous faudrait implémenter un objet Article "pauvre" qui aurait perdu des propriétés ?
    Non : faites une méthode différente
    Dans les ORM on a souvent la notion de factory et d'item: d'un coté une classe modèle qui, via des méthodes nous retourne un tableau d'objet
    De l'autre ces objets retournés peuvent être des classes riches (ou non si on veut plus de performance)

    Ici vous pouvez avoir une méthode findAll() findByArticle() et findByArticleRich() (qui utiliserait des jointures)
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  13. #53
    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 Traroth2 Voir le message
    Mais là, on ne parle pas d'ORM, alors, mais de framework de persistance. MyBatis fait tout ce que tu dis très bien, et n'a pas la complexité de Hibernate.
    L'ORM du mkframework fonctionne ainsi
    Je développe depuis une bonne dizaine d'année, comme je l'ai déjà dit j'ai développé en parallèle mon framework en utilisant symfony/propel puis Zend Framework et son Zend DB
    J'ai essayé de faire un bon compromis entre un ORM confortable, flexible et performant
    On a le choix entre utiliser des objets plus ou moins riche, parcontre je ne propose pas de méthodes pour bypasser le SQL, ici on écrit ses propres requetes SQL plus ou moins complexe
    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. #54
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    Citation Envoyé par imikado Voir le message
    Non : faites une méthode différente
    Dans les ORM on a souvent la notion de factory et d'item: d'un coté une classe modèle qui, via des méthodes nous retourne un tableau d'objet
    De l'autre ces objets retournés peuvent être des classes riches (ou non si on veut plus de performance)
    L'ORM est donc plus compliqué que le SQL dès qu'on parle de performance.
    CQFD.

    Je ne vais pas répéter une troisième fois la conclusion.

  15. #55
    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 c'est vous qui avez le choix: si vous misez sur les performances, utilisez (pour le mkf) les méthodes findManySimple() et findOneSimple()
    Si vous n'avez pas à vous souciez des performances, vous pouvez utiliser les méthodes findMany() et findOne()
    Si cela dépend des pages et des éléments à afficher, vous pouvez mixer les deux

    Comme l'indique erwanlb les utilisateurs ne sont pas des chronomètres, mais comme nous le savons tous, certaines pages, fonctionnalités nécessitent d'afficher beaucoup d'élements, et à ce moment on est bien ravi de savoir que l'on peut miser sur les performances dans ce cas là

    Exple objets riches
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    class  model_auteur extends abstact_model{
     
    (...)
    findArticleByAuteur($auteur_id){
     return $this->findMany('SELECT * from article WHERE auteur_id=?',(int)$id);
    }
     
    }
    Exple objets léger (très rapide)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    class  model_auteur extends abstact_model{
     
    (...)
    findArticleByAuteur($auteur_id){
     return $this->findManySimple('SELECT article.titre,auteur.nom from article INNER JOIN auteur on auteur.id=article.auteur_id WHERE auteur_id=?',(int)$id);
    }
     
    }
    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. #56
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    En effet, et en SQL également vous avez le choix. Vous pouvez charger les données dans des objets complexes et mal pensés si vous tenez à détériorer les performances, par exemple parce que la page n'affiche qu'un seul élément. Vous pouvez au contraire écrire des objets faits pour ce que le logiciel doit faire et alors vous conserverez de bonnes performances.

  17. #57
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624
    Par défaut
    Citation Envoyé par imikado Voir le message
    Exple objets léger (très rapide)
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     
    class  model_auteur extends abstact_model{
     
    (...)
    findArticleByAuteur($auteur_id){
     return $this->findManySimple('SELECT article.titre,auteur.nom from article INNER JOIN auteur on auteur.id=article.auteur_id WHERE auteur_id=?',(int)$id);
    }
     
    }
    Merci pour le code. C'est effectivement une bonne idée, puisque si tout le monde voit bien à quoi ressemble l'utilisation de SQL via PDO (ou JDBC pour Traroth2 avec qui je suis bien entendu d'accord), ce n'est pas le cas pour les ORM. En tout cas en ce qui me concerne, mon expérience des ORM vient de Java alors qu'en PHP j'ai pu choisir et donc je n'ai jamais pratiqué.

    Que renvoie la méthode "findArticleByAuteur" ? Si c'est un objet, eh bien à mon avis un tableau PHP est plus simple, plus élégant, plus performant qu'un objet écrit ad hoc pour le résultat d'une requête. [EDIT] Et si c'est un tableau, la méthode "findManySimple()" fait-elle un traitement particulier en plus d'un simple appel à PDO ?

  18. #58
    Membre confirmé

    Développeur Web
    Inscrit en
    mars 2002
    Messages
    409
    Détails du profil
    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : mars 2002
    Messages : 409
    Points : 624
    Points
    624

  19. #59
    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 laffreuxthomas Voir le message
    Que renvoie la méthode "findArticleByAuteur" ? Si c'est un objet, eh bien à mon avis un tableau PHP est plus simple, plus élégant, plus performant qu'un objet écrit ad hoc pour le résultat d'une requête. [EDIT] Et si c'est un tableau, la méthode "findManySimple()" fait-elle un traitement particulier en plus d'un simple appel à PDO ?
    findArticleByAuteur retourne un tableau d'objets
    La différence entre findMany et findManySimple:
    findManySimple fait un simple appel à pdo et retourne un tableau d'objets pdo (objet simple) mais tres rapide
    findMany "hydrate": il fait une requete pdo et crée à partir du tableau retourné un tableau d'objets "riches" de classe row_maTable
    Cela permet de l'enrichir de différentes méthodes et de permettre la manipulation
    Exple:
    Code php : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    $oArticle=model_article::getInstance()->findById(2);
    $oArticle->titre="mon titre";
    $oArticle->save();
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  20. #60
    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 laffreuxthomas Voir le message
    Le problème c'est que vous écrivez des choses inexactes comme:
    Chaque objet est chargé avec l’intégralité d’une ligne d’une table. Et peu importe que telle colonne ne soit pas utilisée par telle partie du programme, l’objet du mapping chargera toutes les colonnes.
    Vous pouvez lors de votre requete en SQL indiquer les champs à récupérer par exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    public function findAuteurNameById($id){
     return $this->findOne('SELECT auteur.nom from auteur WHERE id=?',(int)$id);
    }
    public function findListAuteurName(){
     return $this->findOne('SELECT auteur.nom from auteur');
    }
    Idem pour cette phrase
    En SQL nous effectuons des jointures afin de ramener en une requête telles cellules d’une table couplées à telles autres d’une autre table. Alors que dans le même temps un ORM ramène brutalement en deux requêtes séparées deux lignes entières.
    Vous pouvez tres bien écrire vos jointure
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    public function findArticleWithAuteur($id){
     return $this->findOne('SELECT article.titre, auteur.nom from article INNER JOIN article.auteur_id=auteur.id AND article.id=?',(int)$id);
    }
    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