Discussion :

[JPLAROCHE]

J'avoue que Orm , a suscité chez moi l'envie de me plonger dans la confection de mon propre Orm, et m'a apporté beaucoup tant technique, qu'idée de comment faire pour que le service soit plus dans le fonctionnel que dans le code cela a été payant.
mais nous n'avons pas donnés dans le Orm tout fait .... pourtant je reconnais à Orm des qualités indéniables.
je rejoindrais la première réponse et ne mélangerais pas son utilisation pour dire si cela est bon ou pas.....

[MaximeCh]

On me dit à l'oreille bisounours

[Max Lothaire]

Ça me rappel ce billet : http://sametmax.com/les-critiques-de...-de-la-plaque/

Puisque pour faire une application propre on à besoin de faire un module dédier à l'accès aux données, on finira par faire un petit ORM qui sera moins bien testé et moins bien documenté. Donc autant en utiliser un déjà fait.

[Sodium]

Je comprends mal comment l'on peut nier que le SQL est chiant à écrire, chiant à générer par programmation et surtout que les données sont chiantes à traiter par la suite (exemple simple, les relations one to many où SQL n'est pas foutu de renvoyer un sous-tableau de tous les résultats de la jointure et qui oblige à looper tous les résultats pour composer les résultats), sans même parler des faiblesses de sécurité qui permettent aux débutants de se retrouver rapidement avec des injections.
Qu'on aime une techno c'est une chose, nier ses faiblesses évidentes ça me dépasse.
Biais cognitifs over 9000.

Ça me rappel ce billet : http://sametmax.com/les-critiques-de...-de-la-plaque/

Puisque pour faire une application propre on à besoin de faire un module dédier à l'accès aux données, on finira par faire un petit ORM qui sera moins bien testé et moins bien documenté. Donc autant en utiliser un déjà fait.

D’abord, on optimise pour les humains. En chemin, on optimise pour la machine. Quand ton ORM arrête de scaler, c’est un BON problème à avoir. Ca veut dire que le projet a atteint un certain succès, et qu’on peut investir dans la séparation avec l’ORM.

Tout est dit..

Autre commentaire plein de bon sens :

“Les ORMs sont une annerie. Voici ma solution, qui est un ORM en moins bien”

[Michel.Priori]

Bonjour Sodium,
Je salue ton combat qui vire à "seul contre tous".
Malheureusement tu as, certainement à ton insu, fait tourner la conversation à des arguments personnels.
Arguments qui ne peuvent balancer dans le débat : "Faut-il utiliser les ORM ou continuer d'écrire simplement des requêtes SQL ?"

Je comprends mal comment l'on peut nier que le SQL est [...], chiant à générer par programmation

Bon, j'ai passé l'argument purement personnel par le masquage [...]
Pour le reste, ta position t'empêche visiblement d'intégrer qu'on puisse développer autrement.
Je m'explique : je suis un défenseur d'un développement de solution dans laquelle la base est définie comme une API. Les seuls "objets" accessibles sont des vues et des procédures stockées.
Du coté applicatif, le programme ne doit jamais dépasser le langage ANSI en se refusant l'utilisation d'un quelconque mot de "dialecte" lors de l'utilisation des vues ; pour les PS le problème ne se pose pas.
Donc d'un certain coté je te rejoint en disant qu'on de doit pas générer du SQL par programmation ; je rajoute "côté application" pour ma part.

et surtout que les données sont chiantes à traiter par la suite (exemple simple, les relations one to many où SQL n'est pas foutu de renvoyer un sous-tableau de tous les résultats de la jointure et qui oblige à looper tous les résultats pour composer les résultats),

C'est par des remarques de ce type que tu te fais taxer de ne pas comprendre le SQL.
La base du SQL est de manipuler des matrices complètes. C'est évident pour tout le monde. Pas pour toi visiblement.
Si tu veux une structure hiérarchique demande à formaliser la réponse en XML (ou autre) à l’exécution de la requête.

Au fait, quand t'as fini de "looper" t'as quoi comme structure dans ton programme ?

sans même parler des faiblesses de sécurité qui permettent aux débutants de se retrouver rapidement avec des injections.

Débutant et sécurité.
Ok, tu te lance dans une conversation stérile.
D'une part ça me fait penser aux grammairiens qui expliquent la puissance du mécanisme à des illétrés, alors que, pour eux, leurs thèses respectives ne sont pas des livres de chevet.
D'autre part, quand le mal est connu ça fait simplement un chapitre à apprendre.

[Sodium]

Je m'explique : je suis un défenseur d'un développement de solution dans laquelle la base est définie comme une API. Les seuls "objets" accessibles sont des vues et des procédures stockées.

Tu fais donc comme beaucoup une généralité de ta manière de travailler.

La base du SQL est de manipuler des matrices complètes. C'est évident pour tout le monde. Pas pour toi visiblement.
Si tu veux une structure hiérarchique demande à formaliser la réponse en XML (ou autre) à l’exécution de la requête.

S'encombrer d'une couche supplémentaire XML ? Non merci...

Au fait, quand t'as fini de "looper" t'as quoi comme structure dans ton programme ?

Pour le site que je suis en train de développer ça donne quelque chose du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
$contents = [
    [
        'title',
        'images' => []
        'settings' => [],
        'files' => []
        'children' => [
            'title',
            'images' => [],
            'settings' => [],
            'files' => [],
            'children' => []
            ...
        ]
    ]
]

Nope bien que justement je ne loope pas puisque l'ORM se charge de me retourner un objet facile à manipuler. Et comme le framework mesure les performances de l'application, je peux en quelques secondes tweaker ma requête pour voir ce qui fonctionne le mieux, une grosse requête qui récupère un maximum de données en une fois ou du lazy-load, tout dépend des cas.

Débutant et sécurité.
Ok, tu te lance dans une conversation stérile.
D'une part ça me fait penser aux grammairiens qui expliquent la puissance du mécanisme à des illétrés, alors que, pour eux, leurs thèses respectives ne sont pas des livres de chevet.
D'autre part, quand le mal est connu ça fait simplement un chapitre à apprendre.

Pour que les débutants ne fassent pas d'erreurs de débutants il faut leur apprendre à ne plus être des débutants... on va aller loin comme ça.
D'ailleurs pour qu'il y ait moins de chômage il suffirait que tout le monde ait un BAC+5 (ce qui est faux mais c'est pour l'exemple), pourquoi n'y a t-on pas pensé plus tôt ?

[Michel.Priori]

Tu fais donc comme beaucoup une généralité de ta manière de travailler.

Oui, j'ai des principes dans mon travail.
Non, je n'en fais pas une généralité.

Pour être honnête, je m'attendais à ce que tu soulève les limites du modèle que j'ai proposé.
Car oui, j'essaie d'avoir conscience des limites des solutions que je propose.
Donc, si tu veux l'entendre, non cette vision n'est pas la bonne dans tous les contextes.
N'empêche que je la défend... quand c'est possible.

Il me semble que bon nombre de personnes ont déjà répondu qu'il fallait savoir utiliser chaque outil pour ce qu'il peut apporter.
Le fait d'utiliser un ORM n'est pas hérétique. C'est juste pas LA réponse universelle.
Dans certaines situations c'est bien, pas dans toutes.

Et fondamentalement, vu qu'un ORM "pond" du SQL, chercher à dénigrer le SQL, est quelque peu suicidaire.
L'inverse n'est pas vrai.

[Sodium]

C'est justement pour cela que je fais la distinction.
Si le but recherché est de piocher des données très précises avec des requêtes complexes sur énormément de records, le SQL se justifie.
Si l'on développe une application orientée objet qui manipule régulièrement des données modestes et que la lisibilité du code est la priorité (et elle devrait toujours l'être), je ne vois pas ce qui justifierait de ne pas utiliser un ORM.
Tout comme l'on ne développe pas la même chose avec du C et du Java (à moins d'être masochistes).

[BugFactory]

si tu mets lazy, lorsque tu voudras accéder à l'élément une autre requête sera faite

C'est un peu le principe du chargement paresseux, l'ORM n'y est pour rien. On a la même chose quand on le fait soi même. Après on peut débattre des mérites du chargement paresseux, mais c'est un autre sujet.

C'est déroutant cette réticence à vouloir apprendre le SQL.

Tous les développeurs utilisant Hibernate que je connais connaissent aussi le SQL.

Pourriez vous vous surveiller vous tous? C'est un sujet intéressant, mais le niveau est tombé bien bas. Je ne vois plus que des insultes contres les compétences du "camp" adverse. Des retours d'expérience? Des benchmarks? Des analyses? C'est trop en demander sur un forum de professionnels j'imagine.

[Sodium]

Je ne critique les compétences de personne, je critique leur vision bas niveau du développement ainsi qu'un certain élitisme et un manque de recul assez communs à tous les gens qui sont experts d'une techno.

Personnellement je me considère comme un expert en CSS, mais quand un collègue me dit que le CSS c'est compliqué, contre-intuitif et assez naze niveau syntaxe je leur répond... ben oui.

[deltree]

Cette phrase de l'article m'a sauté aux yeux:

"En général, ils causent des problèmes lorsque la base de données n’est pas faite dans les règles de l’art."

Ah oui, mais est-ce que c'est normal de ne pas faire les bases de données dans les règles de l'art? est-ce qu'on doit considérer que c'est le cas général?
J'écoute les arguments pour et contre et je suis tenté de trouver à la fois des avantages et inconvénient à l'Orm et au pur SQL, mais pour moi le prérequis c'est que le développeur maitrise le SQL et une modélisation "dans les règles de l'art".
(Pourquoi on ne parle plus de normalisation BCNF d'ailleurs plutot que de "règles de l'art")

[marc.collin]

mais pour moi le prérequis c'est que le développeur maitrise le SQL et une modélisation "dans les règles de l'art".

c'est le minimum pour s'assurer que l'orm fait bien le travail escompté

[SQLpro]

Je comprends mal comment l'on peut nier que le SQL est chiant à écrire, chiant à générer par programmation et surtout que les données sont chiantes à traiter par la suite (exemple simple, les relations one to many où SQL n'est pas foutu de renvoyer un sous-tableau de tous les résultats de la jointure et qui oblige à looper tous les résultats pour composer les résultats),

Soit vous êtes inculte, soit vous avec un SGBD de merde (style MySQL qui n'implémente que 10 % de la norme SQL), soit vous êtes de mauvaise fois, mais pour avoir un sous total (et même de multiples sous totaux), vous avez plusieurs choix possibles en passant par les fonctions de fenêtrage ou le groupage OLAP...

sans même parler des faiblesses de sécurité qui permettent aux débutants de se retrouver rapidement avec des injections.

S'il existe des problèmes d'injection c'est justement par ce que la plupart des développeurs ne savent pas :
1) modéliser coorrectement une base
2) écrire des requêtes sensées répondre directement aux demandes
3) utiliser des vues
4) utiliser des UDF table

Et de toutes les façons, le fait qu'il y ait possibilité d'injection n'est pas propre à SQL, mais à tous les langages interprétés...

a +

[Sodium]

soit vous avec un SGBD de merde (style MySQL qui n'implémente que 10 % de la norme SQL),

Je l'ai dit plus haut, je bosse sous MySQL, Postgres et Informix. Pour le reste, je n'ai pas envie de répondre à des insultes. De toute manière, quand on en vient aux insultes c'est généralement que l'on n'a pas grand-chose de pertinent à dire.

[Michel.Priori]

Je vous propose d'alimenter/voter pour chaque propositions du tableau suivant (1 ligne = 1 argument/proposition).

Allez je commence :

N° de proposition	ORM fortement conseillé	ORM simplement avantageux	ORM ou SQL pur en équivalence	SQL pur simplement avantageux	SQL pur fortement conseillé	Validé par	Réfuté par
1	Lorsque le modèle Objet est complet et la méthode bien suivie					michel.priori ;
2					Lorsque les données stockées sont multi applications sans modèle objet global	michel.priori ;
3			Facilité d'acquisition du langage			michel.priori ;
4		Facilité d'écriture des opérations CRUD				michel.priori ;
5				Retour sur investissement de l'apprentissage à l'échelle d'une carrière		michel.priori ;
6					Optimisation du traitement SQL	michel.priori ;

[mermich]

Quelque notes :

Ligne 2) C'est pas parce qu'une appli A est en sql pur que la B qui utilise la meme base de donnees devrai etre en sql pur aussi.
Ligne 3) Niveau completement debutants un orm est plus simple a prendre en main.
Ligne 5) Si on veut devenir dba oui, sinon non.
Ligne 6) Idem c'est pour les dba.

[blbird]

je n'ai pas envie de répondre à des insultes. De toute manière, quand on en vient aux insultes c'est généralement que l'on n'a pas grand-chose de pertinent à dire.

Ca fait tellement de fois que tu énerves des personnes sur ce forum car tu parles de ce que tu ne comprends pas, mais que tu insistes et insistes encore, qu'il serait bon que tu puisses envisager que le problème n'est peut-être pas chez les autres.

[Sodium]

Je m'en fiche d'énerver des gens, ce qui compte pour moi ce sont les idée et les arguments

Donc si tu penses que j'ai tort, il va falloir faire un peu plus que "olol 2 toute facon tu di sa parske ty connai r1, pui 2 toute facon le typage statik sa sert a r1 javascript c tro b1 pui lé ORM cé tro nul é je le c parske le bo frer 2 mon onkl il é exper en bdd et il di ke sa ser a r1 lol" pour me convaincre et accessoirement pour ne pas passer pour un guignol qui n'a tout simplement rien à dire. Par ailleurs, je n'ai encore jamais croisé dans le monde professionnel de personnes ayant un meilleur niveau que moi en JavaScript (et j'ai probablement lu beaucoup plus de bouquins et d'articles sur le sujet que la plupart des gens qui le défendent bec et ongles), donc m'attaquer sur mes connaissances ça m'en touche une sans faire bouger l'autre. Pour les bases de données c'est nettement moins vrai, mais comme pour 95% des devs web et mobiles avoir une expertise dans le domaine ne servirait absolument à rien car nous manipulons rarement des données d'une complexité. Ce dont nous avons besoin, c'est d'optimiser au mieux la logique d'interactions avec ces données et de pondre un code propre, pas de savoir optimiser une requête qui fait des calculs complexes sur 15 tables.

Soit dit en passant, la majorité des gens qui sont sur un forum pour discuter d'une techno, ce sont les gens qui aiment cette techno, donc les discours la critiquent ça les énervent et c'est bien normal. Là sur ce sujet il y a quelques personnes qui sont passées et qui avaient globalement les mêmes arguments que moi, puis elles sont passées à autre chose parce qu'au final elles s'en foutent. Donc ben il reste les gens dont le corps de métier est les bases de données et forcément quand on leur dit que la technique derrière a 20 ans de retard sur le reste du monde du développement informatique, encore une fois ça les énerve.

[blbird]

Je m'en fiche d'énerver des gens, ce qui compte pour moi ce sont les idée et les arguments

Hé bien justement, on est nombreux à t'avoir démontré techniquement que quand tu n'y connaissais rien, ton avis était trop souvent très mauvais. Remarque qu'il y a une relation de cause à effet...

Donc ben il reste les gens dont le corps de métier est les bases de données et forcément quand on leur dit que la technique derrière a 20 ans de retard sur le reste du monde du développement informatique, encore une fois ça les énerve.

Du Sodium pur et dur : il ne connait rien à la techno en question, mais va répéter haut et fort que c'est de la merde et que ca a 20 ans de retard. C'est à pleurer.

Là sur ce sujet il y a quelques personnes qui sont passées et qui avaient globalement les mêmes arguments que moi

Je serais bien curieux de savoir qui sur ce topic à dit que le SQL c'était de la merde, malgré le fait qu'il n'y connaissait rien, et qu'il n'y avait pas besoin de connaître SQL pour utiliser des ORM?
Allez je t'aide : après avoir relu toutes les réponses, il n'y a que toi.

Le problème il n'est pas chez les autres, il est chez toi. Quand tu arriveras à l'envisager, tu auras fais un grand pas vers l'âge adulte.

[Michel.Priori]

Merci mermich d'avoir joué le jeux.

Nous ne sommes pas d'accord.
Voici mon argumentaire :

Ligne 2) C'est pas parce qu'une appli A est en sql pur que la B qui utilise la meme base de donnees devrai etre en sql pur aussi.

Objection : L'évolution de la base va être un point d'achoppement.
Même 2 projets objets qui pointeraient la même base (parce que) mais ne partageant pas le même modèle objet est un merdier sans nom. Alors de là à imaginer un projet avec un ORM et d'autres sans ... bonjour les dégâts.
N'oublions pas qu'un ORM utilise certes mais aussi implémente les éléments de la base en fonction du modèle présenté.

Ligne 3) Niveau completement debutants un orm est plus simple a prendre en main.

Objection : ce que je ne connais pas m'est difficile.
Il parait que le français est très complexe ; c'est un chinois qui me l'a dit

Ligne 5) Si on veut devenir dba oui, sinon non.

Objection : cet argument à été soulevé quelques posts plus tôt : Le langage SQL évolue mais reste stable dans le temps malgré les dialectes. Les ORM, du fait de la compétition, sont plus nombreux et leur durée de vie moyenne est donc plus courte.

Ligne 6) Idem c'est pour les dba.

Objection : Les ORM sont limités dans leur proposition aux techniques qui ont des "équivalences" chez les autres. Tout sujet pour lequel un SGBD à une "longueur" d'avance (ou expertise ou bibliothèque ou ... ce qu'on veux, vous m'avez compris) est forcément moins bien exploité par un ORM

Je reste à l'écoute des contre-arguments et/ou de nouvelles propositions.