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

Actualités Discussion :

Êtes-vous pour ou contre les ORM ? Un blogueur invite à tenir le bâton par le milieu

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    CEO
    Inscrit en
    Juillet 2012
    Messages
    78
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : CEO
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Juillet 2012
    Messages : 78
    Points : 1 395
    Points
    1 395
    Par défaut Êtes-vous pour ou contre les ORM ? Un blogueur invite à tenir le bâton par le milieu
    Êtes-vous pour ou contre les ORM ?
    Un blogueur invite à tenir le bâton par le milieu



    S'il y a bien une constante dans la nature humaine, c'est celle qui rend tellement rare qu'un choix ou un avis particulier fasse partout l'unanimité.
    Le monde de l'informatique et du développement ne dérogent pas à cette règle. C'est même un domaine où les guéguerres idéologiques peuvent être les plus enflammées et les opinions des plus tranchées.

    Des décennies durant, de vifs débats reviennent encore et encore dans les communautés de développement : Big Endian vs Little Endian, EMACS vs Vi(m) ou Java vs .NET, pour ne citer que les plus notables.

    Mais au-delà du débat, constructif ou répétitif, il est incontestable que le vrai gagnant est celui qui arrive à synthétiser les qualités et les faiblesses de chaque opinion dans un contexte précis. Qui arrive à en extraire l'essence pour adapter son choix au besoin particulier de chacun.

    C'est avec cette philosophie qu'aborde Andy Boothe le débat sur les ORM dans un billet de son blog SIGPWNED.

    L'ORM (mapping objet-relationnel) est une technique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé.



    Andy Boothe commence par étayer les avis de chacun, pour nous laisser les meilleures pratiques pour la fin. Entre les modeleurs (les pro-ORM) et les persistants (les anti-ORM), Andy préconise les habitudes suivantes :

    • Utilisez des objets modèles les plus simples possible, lors de l'utilisation de l'ORM. Il faut être vigilant de ne pas sur-simplifier et s'assurer que les modèles reflètent tout simplement l'ancien modèle de données. Autrement on fera face à un effort non négligeable avec l'ORM pour s'assurer que la persistance marche comme prévu pour ne pas chercher des méthodes et des propriétés manquantes.
    • Si vous n'utilisez pas l'ORM, vous devez probablement définir des DAO (Data Access Objects) ou des méthodes de requête et de persistance, pour éviter un couplage fort entre la couche modèle et la couche persistance. Sinon, vous vous retrouverez avec du SQL dans les objets modèles et avec une dépendance forcée.
    • Si vous savez que les schémas d'accès aux données seront simples, mais vous ne les cernez pas entièrement, vous devriez songer à utiliser un ORM. Même si les ORM peuvent rendre difficile de créer et de déboguer les requêtes complexes, ils s'avèrent efficaces et permettent de gagner beaucoup de temps pour des requêtes simples.
    • Si vous savez que les schémas d'accès aux données seront complexes ou que divers mécanismes spécifiques à un SGBD particulier seront utilisés, il est préférable d'éviter les ORM. Même si certains ORM, tels que Hibernate, permettent un accès facile à la connexion sous-jacente, les avantages seront perdus si vous vous retrouvez à utiliser beaucoup de SQL personnalisé.
    • Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.



    Et vous ?

    Êtes-vous pour ou contre les ORM ?
    Pouvez-vous justifier votre choix ?
    Votre choix s'adapte-t-il au type de développement que vous faites ?

    Source : Billet de blog de sigpwned

  2. #2
    Nouveau membre du Club
    Homme Profil pro
    PhD Student, Engineer, Teaching Assistant
    Inscrit en
    Juillet 2010
    Messages
    17
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Meurthe et Moselle (Lorraine)

    Informations professionnelles :
    Activité : PhD Student, Engineer, Teaching Assistant

    Informations forums :
    Inscription : Juillet 2010
    Messages : 17
    Points : 32
    Points
    32
    Par défaut
    Je suis personnellement pour les ORM mais différent de ceux existant actuellement.

    Un ORM apporte une souplesse, une simplicité déconcertante. Il permet un développement plus fiable et plus robuste.

    La performance pourrait être au rendez-vous en utilisant un compilateur qui s'adapte à un SGBD particulier et élimine les couches d'abstraction pour faire des appels directes à des requêtes préparés.

    Pour le développement Object, l'ORM c'est un véritable atout. Reste à gommer ses faiblesse notamment par l'intermédiaire d'un compilateur.

  3. #3
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    Décembre 2011
    Messages
    1 320
    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 320
    Points : 3 740
    Points
    3 740
    Billets dans le blog
    12
    Par défaut
    Je ne suis pas forcément pour ou contre.
    L'article cite assez bien les avantages et inconvénients de l'utilisation d'un ORM.

    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 :
    • Dans l'ensemble, utiliser des objets et leurs méthodes facilite le développement, on évite de passer par des méthodes contenant de longues chaines de requêtes SQL.
    • Les données sont persistants.
    • Notre application devient multi-BDD (ex: fonctionne aussi bien sous MySQL que sous PostgreSQL ou autre...)
    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

  4. #4
    Membre averti Avatar de Stopher
    Homme Profil pro
    Responsable technique
    Inscrit en
    Juin 2004
    Messages
    198
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Nord (Nord Pas de Calais)

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

    Informations forums :
    Inscription : Juin 2004
    Messages : 198
    Points : 446
    Points
    446
    Par défaut
    Pour et contre,

    pour moi il est essentiel de maitriser ce qui se passe lorsque l'on code.

    Il convient d'apprendre à utiliser les bases de données sans ORM, et lorsque l'on a le temps/l'occasion/la contrainte/la volonté d'utiliser/d'apprendre à utiliser un ORM.

    L'utilisation d'un ORM apporte aussi de nouvelles contraintes technique qui ajoute encore un "pseudo langage" à apprendre qui va différer d'une techno à une autre ...

    N'étant personnellement pas lié à un langage particulier je me méfie comme la peste des couches d'abstraction qui permettent "d'arriver plus vite" à ses fins. de plus si le code se veut maintenable, la lib ORM doit être maitrisée par ses mainteneurs .. bref ...

    ça peut vous simplifier la vie, comme la rendre plus compliquée ... à utiliser en connaissance de cause

    Ch.

  5. #5
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 562
    Points : 7 262
    Points
    7 262
    Par défaut
    Citation Envoyé par tarikbenmerar Voir le message
    Êtes-vous pour ou contre les ORM ?
    Pouvez-vous justifier votre choix ?
    Tout dépend du type de développement que l'on fait je pense:
    • si le logiciel produit doit pouvoir supporter différentes bases de données (par exemple une solution de BI ou un CMS), alors le choix d'un ORM peut être justifié
    • dans tous les autres cas, passer par un ORM coûte cher en temps de formation, apporte moins de souplesse et produit de moins bonnes performances que si le développeur avait passé le même temps à apprendre à utiliser correctement une BDD


    Citation Envoyé par tarikbenmerar Voir le message
    Votre choix s'adapte-t-il au type de développement que vous faites ?
    Développant sur des SI sur mesure, je n'ai effectivement pas l'intérêt d'un ORM. Je préfère former mes développeurs correctement, et faire un bon découplage des couches (utilisation de DAO si le langage le permet, création d'une abstraction entre la BDD et le code avec l'utilisation de vues et de procédures stockées)
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  6. #6
    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 222
    Points
    1 222
    Par défaut
    Pouvez-vous justifier votre choix ?

    Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...

    Pas besoin non plus de savoir systématiquement ce qui se passe derrière comme on a pas besoin d'être mécano pour rouler vite en voiture...

    Pour la formation, elle peut être nécessaire aussi quand on utilise pas d'ORM...

  7. #7
    Expert éminent sénior
    Avatar de rawsrc
    Homme Profil pro
    Dev indep
    Inscrit en
    Mars 2004
    Messages
    6 142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Dev indep

    Informations forums :
    Inscription : Mars 2004
    Messages : 6 142
    Points : 16 545
    Points
    16 545
    Billets dans le blog
    12
    Par défaut
    Bonjour,
    Citation Envoyé par erwanlb Voir le message
    Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...
    Faut pas pousser non plus : comme si gérer une connexion à une BDD filait obligatoirement des maux de têtes et concernant le langage SQL, il faut le mettre en parallèle avec l'apprentissage de ceux embarqués par les ORM le HQL et DQL (pour les plus connus). Pour moi c'est kif-kif.

    Le seul hic avec l'abus des ORM c'est quand tu tombes sur un environnement qui t'oblige pour des raisons de sécurité, de performance... à ne passer que par des procédures stockées et là comme je l'ai vu récemment l'abus d'ORM nuit gravement à la productivité.

    Alors sans être expert en SQL, il faut quand même avoir de bonnes notions en bases de données et en langage SQL, le reste c'est un plus mais à consommer avec modération.

  8. #8
    Expert éminent Avatar de kain_tn
    Homme Profil pro
    Inscrit en
    Mars 2005
    Messages
    1 562
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations forums :
    Inscription : Mars 2005
    Messages : 1 562
    Points : 7 262
    Points
    7 262
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    Bossant en .Net je ne me pose pas la question d'utiliser ou pas...je préfère systématiquement la simplicité d'un ORM plutôt que me palucher les connexions, le langage SQL pur, etc...le tout avec un intérêt proche de zéro...
    Euh, le .Net est orienté objet il me semble, donc les connexions etc ça se gère une fois, pas plus. Après pour ce qui est de l'intérêt, c'est encore une fois une question de performances (et donc aussi de coûts).

    Citation Envoyé par erwanlb Voir le message
    Pas besoin non plus de savoir systématiquement ce qui se passe derrière comme on a pas besoin d'être mécano pour rouler vite en voiture...
    Si je comprends où tu veux en venir, je trouve que ta comparaison est assez mal choisie: là, celui qui roule vite ou pas serait l'utilisateur final, tandis que le développeur serait plutôt du côté de celui qui construit la voiture donc bon... Une meilleure comparaison serait peut être la boite de vitesses automatique contre la boite manuelle... Pour une conduite de tous les jours, tu peux utiliser l'une ou l'autre. En revanche sur un circuit, la boite auto c'est pas forcément ce qui se fait de mieux...

    Citation Envoyé par erwanlb Voir le message
    Pour la formation, elle peut être nécessaire aussi quand on utilise pas d'ORM...
    Tout à fait d'accord! Elle est nécessaire! En revanche, le résultat n'est pas du tout le même.
    Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!


    Code C : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    #include <stdio.h>
     
    int main(int argc, char **argv) {
     
        printf("So long, and thanks for the fish, Dennis...\n");
        return 0;
    }

  9. #9
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par tarikbenmerar Voir le message
    • Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.
    Rare ? Au contraire, c'est super répandu !

    J'irais même plus loin: c'est quoi l'intérêt de développer un Système d'Information incapable de tenir la charge ?

    Là où je suis d'accord, c'est qu'un ORM dans ce cas, c'est pas la joie. Typiquement:
    - ça créé une transaction (par ce qu'on en a besoin pour assurer l'intégrité des données)
    - ça fait plein de petites requêtes qui, cumulées, utilisent pas mal de ressources
    - pendant tout le temps où la transaction est restée ouverte, d'autres applications ont eu le temps de faire des timeouts...

    À ce niveau là, je préfère une bonne procédure stockée qui fait des bons gros traitements par lots, et de manière efficace.

    C'est vrai que la POO c'est rassurant parce qu'on comprend les interactions entre objets, et que l'algèbre relationnelle ça fait peur à pas mal de gens. C'est vrai que certaines procédures stockées font mal à la tête quand on doit les relire (surtout si elles sont mal indentées, c'est une horreur !) mais souvent, quand on voit tout ce qu'il faut écrire en POO pour arriver au même résultat (mais en moins performant), c'est même pas la peine !

    Un autre avantage des procédures stockées, c'est que si on se rend compte d'un problème, on a juste à modifier la procédure pour que les changements prennent immédiatement effet, pas besoin de tout recompiler et redéployer...


    J'ai un collègue développeur qui m'a raconté qu'il ne s'était jamais intéressé au SQL... jusqu'à ce qu'il me rencontre et qu'il voie ce qu'il est possible de faire avec du SQL. Depuis il me pose plein de questions.

    À la base, je ne suis pas partisan d'une solution plutôt qu'une autre. Mais quand on a des deadlines parfois assez serrées, on va vers la solution qui permet de réduire les temps de développement. Et quand à cela s'ajoutent des contraintes de performance...
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  10. #10
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2006
    Messages
    5 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2006
    Messages : 5 239
    Points : 19 100
    Points
    19 100
    Billets dans le blog
    17
    Par défaut
    Bonjour,
    Je préconise l'utilisation d'ORM:
    • ça permet de centraliser les requêtes, rangées par table, plus pratique à maintenir. (MVC oblige)
    • on identifie les paramètres des requêtes (pratique pour ajouter les bons index, plus facile de sécuriser)


    Je conseille l'utilisation de requêtes SQL dans les classes modèles à la place de la syntaxe objet ORM
    • Plus simple à écrire/décoder (pour la maintenance/reprise de code), pas besoin d'apprendre un nouveau language
    • Plus facile pour travailler avec le dba*, lorsqu'il faut optimiser les requêtes...
    • Plus performant


    En faisant ainsi on bénéficie des avantages de la séparation de la couche modèle avec la l'organisation des requêtes par table, sans trop perdre en performances.


    *database administrator

    note:On fait ainsi avec zend framework 1.*, et c'est le choix que j'ai également fait pour mon framework php
    Framework php sécurisé et simple à prendre en main avec générateur web http://mkframework.com/ (hebergé sur developpez.com)
    Mes cours/tutoriaux

  11. #11
    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 222
    Points
    1 222
    Par défaut
    Citation Envoyé par rawsrc Voir le message
    Bonjour,

    Faut pas pousser non plus : comme si gérer une connexion à une BDD filait obligatoirement des maux de têtes et concernant le langage SQL, il faut le mettre en parallèle avec l'apprentissage de ceux embarqués par les ORM le HQL et DQL (pour les plus connus). Pour moi c'est kif-kif..
    Pourquoi se donner du boulot en plus ? Je fais pas du bénévolat à mon boulot

  12. #12
    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 222
    Points
    1 222
    Par défaut
    Citation Envoyé par kain_tn Voir le message
    Euh, le .Net est orienté objet il me semble, donc les connexions etc ça se gère une fois, pas plus. Après pour ce qui est de l'intérêt, c'est encore une fois une question de performances (et donc aussi de coûts).



    Si je comprends où tu veux en venir, je trouve que ta comparaison est assez mal choisie: là, celui qui roule vite ou pas serait l'utilisateur final, tandis que le développeur serait plutôt du côté de celui qui construit la voiture donc bon... Une meilleure comparaison serait peut être la boite de vitesses automatique contre la boite manuelle... Pour une conduite de tous les jours, tu peux utiliser l'une ou l'autre. En revanche sur un circuit, la boite auto c'est pas forcément ce qui se fait de mieux...



    Tout à fait d'accord! Elle est nécessaire! En revanche, le résultat n'est pas du tout le même.
    Je connais le langage SQL mais entre l'utiliser dans mon code C# et utiliser un ORM...y a pas photo....

    OK pour la boite manuelle....mais un mauvais pilote ne saurait pas passer les vitesses rapidement...et je dirais qu'un ORM c'est plutôt une boite manuelle avec des palettes plutôt qu'un levier...en tout cas dans ma manière de coder...

  13. #13
    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 222
    Points
    1 222
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Rare ? Au contraire, c'est super répandu !

    J'irais même plus loin: c'est quoi l'intérêt de développer un Système d'Information incapable de tenir la charge ?

    Là où je suis d'accord, c'est qu'un ORM dans ce cas, c'est pas la joie. Typiquement:
    - ça créé une transaction (par ce qu'on en a besoin pour assurer l'intégrité des données)
    - ça fait plein de petites requêtes qui, cumulées, utilisent pas mal de ressources
    - pendant tout le temps où la transaction est restée ouverte, d'autres applications ont eu le temps de faire des timeouts...

    À ce niveau là, je préfère une bonne procédure stockée qui fait des bons gros traitements par lots, et de manière efficace.

    C'est vrai que la POO c'est rassurant parce qu'on comprend les interactions entre objets, et que l'algèbre relationnelle ça fait peur à pas mal de gens. C'est vrai que certaines procédures stockées font mal à la tête quand on doit les relire (surtout si elles sont mal indentées, c'est une horreur !) mais souvent, quand on voit tout ce qu'il faut écrire en POO pour arriver au même résultat (mais en moins performant), c'est même pas la peine !

    Un autre avantage des procédures stockées, c'est que si on se rend compte d'un problème, on a juste à modifier la procédure pour que les changements prennent immédiatement effet, pas besoin de tout recompiler et redéployer...


    J'ai un collègue développeur qui m'a raconté qu'il ne s'était jamais intéressé au SQL... jusqu'à ce qu'il me rencontre et qu'il voie ce qu'il est possible de faire avec du SQL. Depuis il me pose plein de questions.

    À la base, je ne suis pas partisan d'une solution plutôt qu'une autre. Mais quand on a des deadlines parfois assez serrées, on va vers la solution qui permet de réduire les temps de développement. Et quand à cela s'ajoutent des contraintes de performance...
    Tu peux utiliser un ORM et des procédures stockées...

    Vu les arguments utilisés on en est au stade d'un débat genre Win/Linux, iOS/Android....

    Est ce que ceux qui sont contre les ORM les connaisse et les ont utilisé ?

  14. #14
    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 222
    Points
    1 222
    Par défaut
    Citation Envoyé par imikado Voir le message
    [*]Plus simple à écrire/décoder (pour la maintenance/reprise de code), pas besoin d'apprendre un nouveau language[*]Plus facile pour travailler avec le dba*, lorsqu'il faut optimiser les requêtes...[*]Plus performant[/LIST]
    En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

    Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

    Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....

  15. #15
    Rédacteur
    Avatar de imikado
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Décembre 2006
    Messages
    5 239
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique
    Secteur : Finance

    Informations forums :
    Inscription : Décembre 2006
    Messages : 5 239
    Points : 19 100
    Points
    19 100
    Billets dans le blog
    17
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

    Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

    Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....
    Un des problèmes que j'ai déjà rencontré avec l'utilisation de certains ORM était l'utilisation systématique de "select *", donc oui, au niveau perf on peut faire mieux
    Perso j'ai pu faire des benchmarks d'ORM et j'arrivai à des ratio assez important en fonction du nombre d'éléments retournés*

    Pour l'optimisation, je parle de transmettre l'ensemble des requêtes sql au dba pour voir si il ne peut pas ajouter des index, créer certaines vues (si ce n'est pas deja fait) ...
    Ca permet une meilleur communication entre les différentes postes qui interviennent sur le projet (on va pas demander au dba d'apprendre le langage doctrine, ou autre...)


    * j'avais fait une simple page bouclant sur 100 000 articles, et écrivant le titre, l'auteur et la catégorie dans un fichier texte, et on pouvait voir une différence très importante entre les ORM
    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
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    En utilisant un EDM j'ai pas appris un langage en plus....par contre certains peuvent se passer d'apprendre SQL...

    Pour les perfs il faut avoir un sacré nombre de requêtes pour voir une réelle différence (je dis bien une réelle....pas 30ms de bonus dans un domaine non critique)

    Et pour l'optimisation.....on en voit tellement qui croient savoir se servir de SQL alors qu'il n'en est rien....
    me rappel encore d'un reportage d'étudiant qui disait que ça servait à rien le sql parce que les orm faisait tout le boulot....... et par la suite tu avais des ssii qui ralait car trop de gens ne maitrisait pas le sql.....

  17. #17
    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 222
    Points
    1 222
    Par défaut
    Citation Envoyé par imikado Voir le message
    Un des problèmes que j'ai déjà rencontré avec l'utilisation de certains ORM était l'utilisation systématique de "select *", donc oui, au niveau perf on peut faire mieux
    Perso j'ai pu faire des benchmarks d'ORM et j'arrivai à des ratio assez important en fonction du nombre d'éléments retournés*

    Pour l'optimisation, je parle de transmettre l'ensemble des requêtes sql au dba pour voir si il ne peut pas ajouter des index, créer certaines vues (si ce n'est pas deja fait) ...
    Ca permet une meilleur communication entre les différentes postes qui interviennent sur le projet (on va pas demander au dba d'apprendre le langage doctrine, ou autre...)


    * j'avais fait une simple page bouclant sur 100 000 articles, et écrivant le titre, l'auteur et la catégorie dans un fichier texte, et on pouvait voir une différence très importante entre les ORM
    J'ai déjà vu ce genre de benchmark....qui sont généralement contesté dans les méthodes utilisées...même si on sait que l'ORM sera un peu moins rapide...

    Ca dépend grandement de la destination de l'application et de la manière dont elle a été conçue

  18. #18
    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 222
    Points
    1 222
    Par défaut
    Citation Envoyé par marc.collin Voir le message
    me rappel encore d'un reportage d'étudiant qui disait que ça servait à rien le sql parce que les orm faisait tout le boulot....... et par la suite tu avais des ssii qui ralait car trop de gens ne maitrisait pas le sql.....
    Même en utilisant un ORM, dire que SQL ne sert à rien c'est de la connerie...

    Surtout pour "tester" en direct sur la base c'est toujours utile de connaitre SQL

  19. #19
    Membre émérite
    Homme Profil pro
    Ingénieur en génie logiciel
    Inscrit en
    Juin 2012
    Messages
    851
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur en génie logiciel
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Juin 2012
    Messages : 851
    Points : 2 424
    Points
    2 424
    Par défaut
    Citation Envoyé par erwanlb Voir le message
    Même en utilisant un ORM, dire que SQL ne sert à rien c'est de la connerie...

    Surtout pour "tester" en direct sur la base c'est toujours utile de connaitre SQL
    c'est justement mon point de vue et je suis bien content d'avoir une plusieurs cours sur le sujet.

  20. #20
    Membre régulier
    Homme Profil pro
    Chef de projet NTIC
    Inscrit en
    Février 2008
    Messages
    49
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Chef de projet NTIC
    Secteur : Conseil

    Informations forums :
    Inscription : Février 2008
    Messages : 49
    Points : 88
    Points
    88
    Par défaut
    "Êtes-vous pour ou contre les ORM ?" Pourquoi pour ou contre ?
    Le choix de la méthode de persistance s'impose souvent par le contexte, ou par des décisions de l'entreprise prise dans le passé.
    Pour un même projet, il peut y avoir plusieurs applications qui n'utilisent pas toutes les mêmes méthodes de persistance. Le temps fait son œuvre.
    Je n'ai pas encore rencontré ce choix binaire...

Discussions similaires

  1. Etes vous pour ou contre les commentaires dans le code
    Par omarcisses dans le forum Débats sur le développement - Le Best Of
    Réponses: 56
    Dernier message: 04/09/2012, 01h43
  2. Êtes-vous pour ou contre les "strict type hints" ?
    Par RideKick dans le forum Langage
    Réponses: 44
    Dernier message: 21/03/2012, 22h18
  3. [travail] Pour ou contre les bureaux open-space ?
    Par Mat.M dans le forum La taverne du Club : Humour et divers
    Réponses: 31
    Dernier message: 08/04/2008, 13h58
  4. [Mapping O/R] - Pour ou contre les procédures stockées
    Par spidetra dans le forum Persistance des données
    Réponses: 8
    Dernier message: 03/04/2006, 11h01

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