Discussion :

[BugFactory]

J'utilise moi-même Hibernate, et je vois des avantages et inconvénients dont personne n'a parlé.

Ce qui me manquerait le plus sans Hibernate, ce sont les chargements paresseux. Un gain de performance appréciable, mais complexe à coder soi-même. Hibernate le fait automatiquement.

Ce qui ne me manquerait pas, ce sont les problèmes de compatibilité avec d'autres librairies. Hibernate utilise des proxies qui affolent les librairies utilisant l'introspection de code, par exemple Jackson. Dans le cas de Jackson il existe un plugin, encore faut-il le savoir.

En parlant de Jackson, celui-ci possède des fonctionnalités appréciables permettant au développeur de gérer manuellement les cas complexes. Ça manque à Hibernate, et contourner un bogue peut être difficile.

Un problème récurrent que je vois avec les ORM est la façon de les aborder. M. Bendersky semble attendre de l'ORM qu'il permette de s'abstraire entièrement de la base de données sous-jacente et de traiter les données comme si elles étaient en mémoire vive. C'est trop en demander. Les ORM permettent d'économiser du code répétitif, point. Ils ne permettent absolument pas de ne pas savoir utiliser une base de données relationnelle et de ne pas utiliser SQL. Si on les utilise en connaissance de cause, ils sont très utiles.

Je dois admettre que mon expérience est à 99% sur Hibernate, donc d'autres développeurs ont peut-être une expérience différente.

[marc.collin]

Si, dans SQL Server via les tables In Memory et l'indexation ColumnStore….

A +

désolé, pas vraiment la même chose...

[frfancha]

1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

2) "Les ORM sont bien pour les requêtes de base."
Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
S'encombrer de la lourdeur d'un ORM pour ça...

3) Les ORM rendent indépendants de la base de données.
Non. Les ORM rendent dépendants de l'ORM !!
Ce qui est bien pire.
Ce qui rend indépendant de la base de données c'est justement SQL.
Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

3A) Oui mais quid changement de base de données?
Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.

[Sodium]

1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL..

Un peu comme les gens qui considèrent que coder avec autre chose que VIM est une hérésie...

C'est sûr que quand on a 25 ans d'expertise dans un domaine, et qu'on a arrêté de se tenir à jour niveau technos parce qu'au bout d'un moment marre quoi, il faut bien justifier cette expertise et le chèque qui va avec.

[frfancha]

C'est sûr que quand on a 25 ans d'expertise dans un domaine, et qu'on a arrêté de se tenir à jour niveau technos parce qu'au bout d'un moment marre quoi, il faut bien justifier cette expertise et le chèque qui va avec.

Je sais pas. Peut-être que tu as raison que je devrais arrêter de me tenir à jour.
En attendant toute l'interface est en vue.js - asp.net core 3 preview 5 - les appels à la DB passent les rows aux procédures stockées en JSON en SQL Server 2016, etc, etc, ...
Mais bon tu as raison c'est du vieux brol.
Vivement la retraite.

[blbird]

1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

2) "Les ORM sont bien pour les requêtes de base."
Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
S'encombrer de la lourdeur d'un ORM pour ça...

3) Les ORM rendent indépendants de la base de données.
Non. Les ORM rendent dépendants de l'ORM !!
Ce qui est bien pire.
Ce qui rend indépendant de la base de données c'est justement SQL.
Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

3A) Oui mais quid changement de base de données?
Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.

Alors là, que dire de plus, tout est dit. Je confirme complètement via ma aussi très longue expérience sur plusieurs plateforme (J2EE et M$) : je n'aurais pas dit mieux.

[david_st]

1) En 25 ans de carrière je n'ai jamais rencontré un défenseur des ORM qui connaissait vraiment bien SQL.

2) "Les ORM sont bien pour les requêtes de base."
Ok admettons. Et? Dans la vraie vie d'un vrai système complexe les requêtes de base représente quelle partie du temps de développement par rapport à celui des requêtes complexes?
S'encombrer de la lourdeur d'un ORM pour ça...

3) Les ORM rendent indépendants de la base de données.
Non. Les ORM rendent dépendants de l'ORM !!
Ce qui est bien pire.
Ce qui rend indépendant de la base de données c'est justement SQL.
Si votre couche d'accès est complètement en SQL dans la DB (procédures stockées), vos couches d'accès (qui peuvent être multiples!) sont indépendantes et interchangeables!

3A) Oui mais quid changement de base de données?
Dans la vraie vie changer de base de données se passe moins souvent que le changement de technologie qui s'addressent à la DB.
Et faire passer du SQL d'une DB à l'autre, même si ce n'est pas automatique n'est pas la fin du monde (de DB2 windows à oracle en 2001 à DB2/400 en 2003 à SQL Server en 2016. Sans souci.

Mon expérience, reste assez limitée à MySQL/mariadb et SQLite. et essentiellement derrière du PHP.

quelques points que j’ajouterais :

1) "Les ORM sont bien pour les requêtes de base." => c'est vrai, à condition de bien connaître les ORM, que l'ORM soit bien fournie.

2) Sur l'indépendance de la base de donnée, il faut encore que les bases de données aient les même fonctions. Si pour les fonctions basiques, il y a des équivalences dans dans toutes les bases de données, pour des fonctions plus spécifiques ou elles ne sont pas présentes dans l'ORM (comme right joint avec doctrine) ou elles ne sont pas compatibles avec la DB. (ça m'est déjà arrivé de me faire piéger lors de tests de passer de mariadb à sqlite, d'avoir des erreurs sur sqlite uniquement)

Enfin pour moi, pour bien utiliser sa DB, même avec un ORM, il faut bien connaître sa BD. Du coup, pour bien utiliser un ORM, il faut apprendre DB + ORM =, > 2 * plus d’éléments à apprendre.

Mais il y a quelques points qui obligent à savoir travailler avec ORM :
- la majorité des développement se font avec.
- on trouve sur tous les frameworks (en tout cas le principal) ont un ORM (plus ou moins dédié)
- certains disent que c'est plus sécurisé. (j'aimerais bien que l'on me dise pourquoi, c'est vrai que sur php, msqli c'était mal foutu sur ce point là, mais PDO fait bien le travail) et les entreprises aiment ça.


Du coups, mon avis sur la question, les ORM sont utile dans les cas simples, çà simplifie certain le travail. comme la migration, certain contrôle. Mais complique la tache dés que l'on a quelle chose de complexe à demander.
Le SQL est un langage simple, mais écrire une bonne requête SQL, et de géré une base de donnée, une spécialité.

Alors pour ou contre? je n'est pas d'avis, j'ai une référence à ne pas les utiliser, si je peux. Je trouve que comme ça, on a un meilleure contre sur sa DB.

[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.

[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 +