Affichage des résultats du sondage: Rencontrez-vous des réticences d'usage des outils de mapping O/R de vos DBA

Votants
46. Vous ne pouvez pas participer à ce sondage.
  • Non, pas de réticence du tout

    23 50,00%
  • Oui, des réticences au départ mais plus maintenant

    9 19,57%
  • Oui, des réticences et même que l'on ne peut pas utiliser ces outils

    14 30,43%
+ Répondre à la discussion Actualité déjà publiée
Page 2 sur 3 PremièrePremière 123 DernièreDernière
  1. #21
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 412
    Points
    1 412

    Par défaut

    Je n'utilise pas d'ORM, pour autant, je n'estime pas que je fais de la perte de temps. La création des mappings n'est faite qu'une fois également, comme si j'avais un ORM. Je ne comprends pas cet argument qui dit que lorsqu'on n'utilise pas d'ORM, il y a 3000 mappings à faire.

    L'argument de la portabilité de la base de données est beau dans les faits, mais perd de son ampleur dans la réalité. Les deux réelles applications à ceci sont la possibilité laissée au client d'utiliser le SGBDR de son choix et la possibilité de changer sa base de données quand on le souhaite. Ceci me pose deux problèmes : on ne sait pas quelle est la base de données du client et l'on doit la supporter. Vouloir prôner l'universalité d'un système est beau dans l'idée, mais a de solide contre-arguments, tel les perfs misérables.

    Le jour où un ORM libre créera des stored procs (pour une quelconque BDD) à ma place à partir de mon code Java afin d'avoir l'avantage de la rapidité de développement et des perfs, j'envisagerai peut-être de passer aux ORM (cela existe déjà en système payant). En attendant, je reste à mon système qui, bien que très légèrement plus lent au développement, m'assure des performances excellentes et une séparation des problématiques extrêmement nette.

  2. #22
    Membre habitué

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    121
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : janvier 2007
    Messages : 121
    Points : 153
    Points
    153

    Par défaut

    Citation Envoyé par GLDavid Voir le message
    Maintenant, tu mentionnes que cette solution apporte un niveau d'abstraction. Mouais... Franchement, il me semble que la création des tables et le fait de produire un schéma relationnel est déjà une abstraction. Autre chose, si ces frameworks miment les tables en objets, dites, pour des grosses bases de données (>100 tables) votre application doit grossir méchamment, non ?
    @++
    C'est un abstraction, c'est un fait, même si ce n'est pas la dernière couche. En final, ce sera bien du sql qui sera généré, ce n'est pas "un autre langage". Bien sûr, il y a plus de classes dans les applications, mais elles ne grossissent pas nécessairement. Elles sont simplement mieux découpées et on mélange moins facilement la persistance et le métier, avec tous les avantages liés. Les outils de développement modernes permettent de générer tout ça très rapidement, ce n'est pas nécessairement plus difficile à maintenir ("grossir méchamment" ?), au contraire. Mais il faut une certaine expérience de développement pour voir les avantages de cette abstraction supplémentaire.

  3. #23
    Membre chevronné

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    novembre 2006
    Messages
    1 248
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : novembre 2006
    Messages : 1 248
    Points : 1 852
    Points
    1 852

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Je n'utilise pas d'ORM, pour autant, je n'estime pas que je fais de la perte de temps. La création des mappings n'est faite qu'une fois également, comme si j'avais un ORM. Je ne comprends pas cet argument qui dit que lorsqu'on n'utilise pas d'ORM, il y a 3000 mappings à faire.
    Parce que probablement tu ne travaille pas directement sur ton modèle métier mais sur une vue de celui-ci. Ainsi, tu n'as pas à te pré-occuper de la navigabilité du modèle.

  4. #24
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 412
    Points
    1 412

    Par défaut

    Au contraire, nous sommes deux à nous occuper du domaine : le programmeur SQL et moi-même.

    Nous suivons quelques conventions comme retourner un maximum des ensembles de données identiques, quitte à les remplir par des NULL. Par exemple, si nous voulons uniquement les noms des clients des livres, la stored proc renverra par exemple :

    ID : rempli
    Prénom : rempli ou NULL si société
    Nom : rempli ou NULL si société
    Société : rempli ou NULL si particulier
    TVA : NULL
    Adresse : NULL

    etc.

    Si c'est cela que tu appelles avoir des vues métier, alors je dis oui.

    Rien à voir, mais il était pas autre part, ce sujet ?

  5. #25
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 822
    Points : 7 071
    Points
    7 071

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Je n'utilise pas d'ORM, pour autant, je n'estime pas que je fais de la perte de temps. La création des mappings n'est faite qu'une fois également, comme si j'avais un ORM. Je ne comprends pas cet argument qui dit que lorsqu'on n'utilise pas d'ORM, il y a 3000 mappings à faire.
    Je dirai que l'un des points

    L'argument de la portabilité de la base de données est beau dans les faits, mais perd de son ampleur dans la réalité. Les deux réelles applications à ceci sont la possibilité laissée au client d'utiliser le SGBDR de son choix et la possibilité de changer sa base de données quand on le souhaite. Ceci me pose deux problèmes : on ne sait pas quelle est la base de données du client et l'on doit la supporter. Vouloir prôner l'universalité d'un système est beau dans l'idée, mais a de solide contre-arguments, tel les perfs misérables.
    Bien dit, tu me croiras si je te dis que tous les logiciels axé données que je connais qui justement se prétendaient multi-base au départ ont fini par devenir mono-base?
    La raison est simple, on doit se limiter au plus petit dénominateur commun au niveau fonctionnalité ce qui veut dire quasiment tirer une croix sur le code serveur, de plus il faut tenir compte des spécificités des SGBDR au niveau des DDL entre autres de leur façon de gérer les clefs auto incrémentales et si on veut des fonctionnalités avancées comme la réplication multi-site, là ça peut devenir infernal.
    On ajoute à cela les nombreux tests nécessaires au support multi-base, le support client très dépendant de l'environnement de celui-ci, ça peut devenir une charge de travail astronomique pour un gain au final assez faible

    je reste à mon système qui, bien que très légèrement plus lent au développement, m'assure des performances excellentes et une séparation des problématiques extrêmement nette.
    A ce sujet, IBatis m'a semblé une excellente solution car il permet de profiter de toute la puissance du SQL tout en éliminant certains aspects pénibles du JDBC pur.

    Qu'est-ce que tu entends par "trop de plomberie"
    La conversion des ResultSet en POJO, et toutes ces choses rébarbatives dont je peux soit me passer, soit sortir du code.

  6. #26
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 412
    Points
    1 412

    Par défaut

    Citation Envoyé par _skip Voir le message
    Bien dit, tu me croiras si je te dis que tous les logiciels axé données que je connais qui justement se prétendaient multi-base au départ ont fini par devenir mono-base?
    Oui, c'est le déroulement classique d'un projet :
    - Tous les clients utilisent Oracle ?
    - Oui, boss, sauf un qui utilise MySQL
    - Bon, bah, à partir de maintenant, on ne supporte plus qu'Oracle alors.
    - Ah ben zut, boss on aura des perfs nulles avec notre ORM, et puis il nous faudrait un programmeur SQL, ce qui coûte un pont !
    - Non, vous continuez comme ça, je trouverais bien quelque chose à dire aux clients inquiets des perfs : c'est mon job ; et pour le gars qui utilise MySQL, je le ferai passer à Oracle.

    Je connais bien la problématique. J'avais écrit une longue tartine qui l'incluait, mais au final, j'ai supprimé les trois quarts car c'était presque du hors sujet ici.

    Citation Envoyé par _skip Voir le message
    A ce sujet, IBatis m'a semblé une excellente solution car il permet de profiter de toute la puissance du SQL tout en éliminant certains aspects pénibles du JDBC pur.
    Bien possible : je ne connais pour ainsi dire qu'Hibernate comme ORM. C'est, semble-t-il le plus développé, et donc le seul auquel je m'intéresse en attendant LA fonctionnalité qui me fera passer à l'ORM, c'est à dire la traduction de code Java métier en stored-proc.

    Citation Envoyé par _skip Voir le message
    La conversion des ResultSet en POJO, et toutes ces choses rébarbatives dont je peux soit me passer, soit sortir du code.
    Pour cela, j'ai juste une version modifiée de DBUtils. Le mapping est fait assez rapidement, et sans me casser la tête.

  7. #27
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 461
    Points : 8 465
    Points
    8 465
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Bien possible : je ne connais pour ainsi dire qu'Hibernate comme ORM. C'est, semble-t-il le plus développé, et donc le seul auquel je m'intéresse en attendant LA fonctionnalité qui me fera passer à l'ORM, c'est à dire la traduction de code Java métier en stored-proc.
    Le jour où il se mettront d'accord sur un langage et des fonctionnalités 100% communs, pourquoi pas... il ne restera plus alors que le problème des paramètres à passer à la store proc pour remplir sa fonction (quand on ajoute des colonnes en cours de route par exemple)...

    En attendant, l'ORM a de beaux jours devant lui, et sûrement pas parce qu'il est mauvais et qu'on est tous des andouilles à suivre les modes

    Utiliser un ORM juste pour éviter de coder soit même des classes typées "Entity" en JDBC est déjà bien, même si c'est très limitant.
    Je préfère considéré l'ORM comme un super outil qui me permet de causer fonctionnel plutôt que table et laisse la "plomberie" (pour citer l'expression de _skip) au moteur (avec des possibilités de spécialisations par SGBDR via les "dialect").

    Pour résumer, sans contraintes fortes de performances, je choisis l'ORM plutôt 2x qu'une.

  8. #28
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 412
    Points
    1 412

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    [...] et qu'on est tous des andouilles à suivre les modes
    Je ne dis pas cela et suis à mille lieues de le penser. L'expérience que j'en ai ne me convainc pas. Si sur 1000 développeurs, 800 utilisent un ORM, c'est qu'il a ses qualités. Je fais partie du reste qui en demande davantage.

  9. #29
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 461
    Points : 8 465
    Points
    8 465
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Je ne dis pas cela et suis à mille lieues de le penser. L'expérience que j'en ai ne me convainc pas. Si sur 1000 développeurs, 800 utilisent un ORM, c'est qu'il a ses qualités. Je fais partie du reste qui en demande davantage.
    Je te rassure, je ne pensais pas à toi mais à un pro du sql

  10. #30
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par OButterlin Voir le message
    C'est vrai qu'il est difficile de faire ressortir l'ironie dans l'écrit...
    Je suis d'accord avec toi, c'était une forme (extraterrestre faut croire) d'humour... je ne suis pas attaché au passé, mais je ne l'oublie pas pour autant... les bonnes fondations permettent de bâtir haut et robuste
    ok alors pas de soucis

  11. #31
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut

    je suis attéré par l'extremisme de vos réactions et le design que certains proposent.
    S'appuyer sur des proc stockées, c'est franchement pas la solution que j'ai vu dans ma vie d'informaticien depuis maintenant 16 ans. Je suis peut être moi aussi à côté de la plaque mais je ne crois pas avoir fait ou vu de projets avec des proc stockées.
    Luc Orient me corrigera mais dans notre boite il ne doit pas y en avoir et nous travaillons dans une TRES TRES grosse entreprise avec de TRES TRES GROS besoins en termes de volume et de transactions/seconde. Et je crois que ça marche.........me semble t-il.
    Et puis vous savez, l'informatique va vers de plus en plus d'abstraction et donc travailler au niveau objet même pour déclencher des requêtes en base me parait "normal" (sachant que malgré tout il y a SQL derrière). Mais qui sait, peut être qu'un jour il n'y aura même plus le SQL......oh zut, j'ai dit une grossièreté, non

    Pour ceux qui restent collé à leur SQL, vous vous trimballez, si vous faites du Java, avec vos ResultSet dans toute l'application ?
    Et pour celui qui fait des proc stock qui renvoie des NULL en fonction de l'objet retourné, moi je mettrai un zéro en terme de conception.
    Et mon exemple avec le "select new ClientSimple..." c'est justement fait pour ça = ne pas tout ramener si on n'a pas besoin de tout le Client.

    Mais peut être que ceux qui n'ont jamais utilisé d'ORM devraient au moins faire l'essai, pour voir et parler en connaissance de cause.

  12. #32
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    95
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 95
    Points : 87
    Points
    87

    Par défaut

    Finalement, l'utilisation d'ORM c'est un peu choisir Windev comme outil de dev !
    Pas une ligne de code (ou presque), pas de code SQL (commande hlit...).
    Où est donc l'intérêt d'utiliser Java ?

    J'utilise Windev et je code mes requêtes SQL.
    J'ai essayé avec les ordres hlit... hajoute ... et question performance les requêtes SQL sont nettement plus performantes.
    Il faut bien entendu maitriser le SQL.
    En écrivant du code SQL respectant le norme SQL (la vrai, celle qui est respecté par la majorité des SGDB), on peut s'en sortir sans réécrire du code SQL si on change de SGBD.

  13. #33
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    95
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 95
    Points : 87
    Points
    87

    Par défaut

    Oh j'oubliais !

    Il ne faut pas perdre de vue le besoin client !
    Que veux le client ?
    Une appli qui réponde à ces specs et qui ne mets pas trois plombe à faire les traitements demandés !

  14. #34
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut

    le parallèle avec Windev n'engage que toi et je ne suis pas certain que ce parallèle soit judicieux ici

  15. #35
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 461
    Points : 8 465
    Points
    8 465
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par brice01 Voir le message
    Finalement, l'utilisation d'ORM c'est un peu choisir Windev comme outil de dev !
    Pas une ligne de code (ou presque), pas de code SQL (commande hlit...).
    Où est donc l'intérêt d'utiliser Java ?

    J'utilise Windev et je code mes requêtes SQL.
    J'ai essayé avec les ordres hlit... hajoute ... et question performance les requêtes SQL sont nettement plus performantes.
    Il faut bien entendu maitriser le SQL.
    En écrivant du code SQL respectant le norme SQL (la vrai, celle qui est respecté par la majorité des SGDB), on peut s'en sortir sans réécrire du code SQL si on change de SGBD.
    Soyons sérieux, Windev a toujours eu comme point faible sa base. Passer à n'importe quelle autre base apporte un plus à une application Windev et un énorme gain en stabilité.
    Pour le reste, ça fait des choses simplement... mais question performance, on a eu l'occasion (à l'époque) de comparer un exe windev avec la même fonctionnalité Delphi, il n'y avait pas photo (en faveur de Delphi bien sûr ).

    A part ça, un ORM ne veut pas dire "pas de ligne de code", il faut coder les requêtes d'accès, l'aspect transaction, etc... il reste à faire...
    On n'a "juste" pas à faire ce qui n'a aucune valeur ajoutée en terme de fonctionnel (à savoir le lien entre les colonnes et les attributs objets et toute cette soupe).
    Je me répète (ou alors c'était dans l'autre post) mais un des intérêts principal est de pouvoir manipuler des objets fonctionnels et pas des tables.
    Bien utilisé, on a une approche très proche des triggers pour les contrôles (par callback) à la différence près (tout de même) en faveur du SGBDR que si on utilise un autre vecteur d'accès aux données, on perd la centralisation et l'intégrité des contrôles.

  16. #36
    Membre expérimenté
    Profil pro
    Inscrit en
    mai 2004
    Messages
    1 252
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : mai 2004
    Messages : 1 252
    Points : 1 412
    Points
    1 412

    Par défaut

    Mouais bon, je quitte la discussion : je vois le forum dans lequel mes posts ont été transférés, je ne risque pas de voir des personnes un peu plus ouvertes d'esprit à ce qui existe hors ORM...

  17. #37
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 822
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 822
    Points : 7 071
    Points
    7 071

    Par défaut

    Citation Envoyé par brice01 Voir le message
    Finalement, l'utilisation d'ORM c'est un peu choisir Windev comme outil de dev !
    Pas une ligne de code (ou presque), pas de code SQL (commande hlit...).
    Où est donc l'intérêt d'utiliser Java ?
    Non, c'est une affirmation fausse. Les ORM ont vraiment pas grand chose à voir avec les facilités que vous propose windev pour l'accès à ses propres outils de bases de données hyper file.
    Quant à l'intérêt d'utiliser java, prenez donc la peine de comparer ce que vous pouvez faire avec un ORM du style hibernate et ce que vous pouvez faire avec les ordres H** de windev, à la fois en terme de performance et de fonctionnalités et vous serez fixé.

    J'utilise Windev et je code mes requêtes SQL.
    J'ai essayé avec les ordres hlit... hajoute ... et question performance les requêtes SQL sont nettement plus performantes.
    La raison de ceci est qu'on ne travaille pas avec une base de données client-serveur de la même manière qu'avec un fichier monoposte en accès séquentiel. Vous pouvez affirmer que les ordres HLitXXX de windev sont très limitées, ne supportent pas les jointures et sont peu adaptés à la récupération de lots de données.
    Les mappings d'un ORM quant à eux peuvent générer les mêmes requêtes que vous écririez à la main, avec des jointures, des conditions, des sous-requête, bref du pur SQL que vous pouvez monitorer.

    Il faut bien entendu maitriser le SQL.
    En écrivant du code SQL respectant le norme SQL (la vrai, celle qui est respecté par la majorité des SGDB), on peut s'en sortir sans réécrire du code SQL si on change de SGBD.
    Si vous ne faites que des manipulations basiques oui, sinon les adaptations sont vite nécessaires. Surtout avec les dates comme ça a été cité, l'éventuelle absence de type booléen propre, ou les clefs primaires auto-incrémentées. Et quand on parle de programmation sur serveur (souvent utile), là on oublie la portabilité.


    Citation Envoyé par ego
    Pour ceux qui restent collé à leur SQL, vous vous trimballez, si vous faites du Java, avec vos ResultSet dans toute l'application ?
    Non nous avons des outils qui permettent de transformer des resultsets en POJO java fortement typés. Les mappings sont juste un élément de l'ORM que proposent égalements les mappers.
    Personnellement j'ai arrêté de croire qu'on pouvait bosser dans un monde merveillleux full OO en faisant semblant que c'est pas une base de données qui est derrière.

    Citation Envoyé par ego
    S'appuyer sur des proc stockées, c'est franchement pas la solution que j'ai vu dans ma vie d'informaticien depuis maintenant 16 ans. Je suis peut être moi aussi à côté de la plaque mais je ne crois pas avoir fait ou vu de projets avec des proc stockées.
    Il est parfois très judicieux lorsque vous calculez des statistiques lourdes, le genre qui vous oblige à appliquer un petit traitement à chaque ligne d'un resultset qui lui aussi nécessite une requête individuelle, de placer ça coté serveur afin de tirer partie des tables temporaires et/ou d'éviter 50'000 aller-retours entre le poste client et la base de données, en comptant l'overhead induit par la conversion du resultset en quelque chose d'utilisable dans votre technologie.

    Vous pouvez partir de l'idée que toutes les opérations sur le résultat d'un SELECT dans lequel chaque ligne nécessite une requête individuelle gagnent énormément à être faits coté serveur.
    Ils vous économisent les allers-retours réseau et permettent à vos transactions de durer moins longtemps en cas d'UPDATE.

    Citation Envoyé par dingoth
    Mouais bon, je quitte la discussion : je vois le forum dans lequel mes posts ont été transférés, je ne risque pas de voir des personnes un peu plus ouvertes d'esprit à ce qui existe hors ORM..
    Ben si : moi.
    Je n'ai pas non plus le sentiment qu'un ORM qui fait plein de magie est la solution parfaite, toutefois je ne suis pas contre un bon mapper.

  18. #38
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    6 461
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 6 461
    Points : 8 465
    Points
    8 465
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par _skip Voir le message
    Ben si : moi.
    Je n'ai pas non plus le sentiment qu'un ORM qui fait plein de magie est la solution parfaite, toutefois je ne suis pas contre un bon mapper.
    Moi aussi, je n'arrête pas de dire qu'il n'y a pas 1 bon outil et les autres mauvais, c'est une question de contexte et d'application...

  19. #39
    Membre régulier
    Profil pro
    Inscrit en
    décembre 2004
    Messages
    95
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2004
    Messages : 95
    Points : 87
    Points
    87

    Par défaut

    La raison de ceci est qu'on ne travaille pas avec une base de données client-serveur de la même manière qu'avec un fichier monoposte en accès séquentiel. Vous pouvez affirmer que les ordres HLitXXX de windev sont très limitées, ne supportent pas les jointures et sont peu adaptés à la récupération de lots de données.
    Les mappings d'un ORM quant à eux peuvent générer les mêmes requêtes que vous écririez à la main, avec des jointures, des conditions, des sous-requête, bref du pur SQL que vous pouvez monitorer.
    Windev a évolué depuis la version 8 : Il fait du client-seveur. Mais là n'est pas la question. Windev fait du multi base sans changer le code source.

    Ce que je voulais dire, c'est que à la manière des ORM windev masque et simplifie la persistance des données et ce fonctionnement peut amener à des performances amoindrie.

    Je ne juge pas hibernate, ibatis ou tout autre ORM (j'ai jamais essayer .. à tort peut être) etje suis à 100% pour l'ORM pour faire du CRUD (mono-table) et seulement pour le CRUD.
    A partir du moment, où la requête est plus complexe (genre sous requêtes....) je ne suis pas sur que les ORM savent le gérer.
    De plus pour que le client serveur soit le plus performant possible il faut éviter les aller retour avec le serveur (requete avec sous requetes...).

  20. #40
    ego
    ego est déconnecté
    Rédacteur

    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juillet 2004
    Messages
    1 883
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 47
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Finance

    Informations forums :
    Inscription : juillet 2004
    Messages : 1 883
    Points : 3 497
    Points
    3 497
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par dingoth Voir le message
    Mouais bon, je quitte la discussion : je vois le forum dans lequel mes posts ont été transférés, je ne risque pas de voir des personnes un peu plus ouvertes d'esprit à ce qui existe hors ORM...
    On ne dis pas cela. On essaye juste de vous convaincre que les ORM ne sont pas aussi mauvais que certains le pense et que, selon moi, le débat ne devrait pas se situer là ou il a été amené = les performances et la pseudo-négation du SQL.
    Encore une fois, il s'agit avant tout de conserver une manipulation homogène des concepts objets côté code. Il n'en reste pas moins important de savoir écrire des requêtes "SQL" sauf qu'on le fait avec un langage qui utilise plutôt le noms des attributs des classes et non leur correspondance en base (les colonnes). Une requête mal foutue en HQL (cas d'Hibernate), sera mal foutue en une fois traduite en SQL.
    Il s'agit donc d'une facilité c'est tout.
    Le seul problème de faire du SQL "natif" et qu'on est obligé ensuite de transférer les ResultSet dans les objets. C'est franchement inutile quand on a un framework qui le fait pour nous. Oui vous pouvez avoir mis en place des solutions maison qui fonctionnent bien mais comme d'habitude en informatique, pourquoi ré-inventer la roue (l'histoire des mapper peu tout à fait être suffisant dans bien des cas).
    Pour faire de la communication réseaux, dans la majorité des cas, je suppose que vous ne faite pas de la manipulation de sockets avec read/write, vous utilisez des protocoles/frameworks de plus haut niveau et vous avez raisons dans 99% des cas. Eh bien avec les ORM c'est un peu pareil.

Discussions similaires

  1. Réponses: 11
    Dernier message: 01/04/2010, 17h27
  2. Quel outil de mapping objet-relationnel choisir ?
    Par mamelouk dans le forum Persistance
    Réponses: 63
    Dernier message: 21/08/2008, 12h11
  3. Etat des lieux des outils de mapping objet/relationnel (ORM)
    Par Exsilius dans le forum Général Dotnet
    Réponses: 12
    Dernier message: 12/02/2008, 08h50
  4. Outil de mapping objet/relationnel OR not ?
    Par Exsilius dans le forum Général Dotnet
    Réponses: 5
    Dernier message: 01/02/2007, 18h52
  5. Réponses: 2
    Dernier message: 02/08/2005, 13h53

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