Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les frameworks de mapping Objet / Relationnel (ORM)
Sont-ils dangereux pour les performances et la stabilité des applications ?

Le , par SQLpro

0PARTAGES

4  1 
Toutes ces histoire de framework et d'ORM sont les plus belles merdes mercatiques que l'on a fait depuis l'existence de l'informatique. Si vous voulez avoir l'assurance de ne pas finir à temps votre prijet et que ce dernier soit inexploitable lors de la montée en charge, alors allez-y, amusez vous bien avec Hibernate et les frameworks associé comme JPA...

Voici un extrait de l'article que je suis en train d'écrire sur les dérives de ce genre d'immondices...

6 – Pourquoi pas un ORM ?

Bonne idée, mais mauvaise pioche… Les outils actuels de mapping relationnel objet, d’Hibernate à iBatis en passant par l’inabouti Entity Framework, possèdent tous les mêmes défauts. Malgré tous les caches qu’on leur met les performances sont divisées par un facteur important par rapport à une série d’insertions faites directement depuis le code client . Pire encore lorsque l’on compare ce que fait l’ORM par rapport à une procédure stockée. En sus les transactions durent plus longtemps car il faut se payer les temps de communications réseau entre les serveurs, ce qui augmente la durée des verrous sur les tables et diminue donc la capacité globale du système à absorber la charge, alors que c’est un des principaux argument de vente (cherchez l’erreur !). Enfin, peu de gens savent qu’une transaction applicative n’est pas l’équivalent d’une transaction de données et qu’il faut à la fois l’un et l’autre si l’on veut être rigoureux. Quant au pilotage du niveau d’isolation des transactions de données, comme les développeurs ne savent même pas de quoi il s’agit, on en constate généralement l’absence !
Finalement les seuls arguments positifs en faveur ce ces outils sont les suivants : pour les éditeurs, cela permet de vendre de la boîte (noire…), pour les développeurs cela leurs permet de rester dans le concept objet sans jamais aller voir du côté de la base de données, les enfonçant ainsi encore un peu plus dans leurs carences.
Quant à l’argument qui consiste à dire que la maintenabilité d’un code client est bien plus simple qu’un code relationnel, j’ose dire qu’elle est d’une évidente stupidité : avoir 3 à 4 fois moins de lignes de code en matière relationnelle qu’avec du code itératif induit mathématiquement le fait qu’il y aura proportionnellement moins d’intervention à y faire. De plus la maintenance d’un service se fait à froid, alors que dans la base c’est nativement à chaud. Bref l’argument de facilité de maintenance largement répandu, montre encore une fois l’étendu du désastre culturel : pour avoir, par manque de formation, laissé les développeurs dans l’ignorance des possibilités de codage dans un SGBDR, pour avoir parfois choisit les mauvais outils (MySQL, SQLite…) on a contourné le problème en y ajoutant des couches superflues, alambiquées et coûteuses, tant en licence, qu’en temps de développement ou en administration.

Toon Koopelars nous donne ce graphique si pertinent (figure 2). On y voit les possibilités des SGBDR croîtrent de façon exponentielle, tandis que leur utilisation commence à décroître brusquement avec la mode d’utilisation de certains outils comme les ORM ou l’arrivée de SGBD pseudo relationnels…


A lire sur le sujet :
http://www.dulcian.com/Articles/Thic...ited_final.htm
http://thehelsinkideclaration.blogsp...vc-part-2.html

A +

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de fr1man
Expert confirmé https://www.developpez.com
Le 31/01/2017 à 9:10
@fsanti
Vous mélangez un peu tout.
Personne ne vous interdit de faire de l'analyse et de pondre un beau modèle de données et d'ensuite utiliser un ORM.
Personne ne vous interdit non plus d'utiliser des procédures stockées dans le cas où l'avantage serait conséquent.
Personne ne vous interdit de travailler de concert avec les DBA pour optimiser votre modèle de données et vos requêtes si besoin.
De plus, au niveau des coûts, certains préféreront ajout de la RAM ou un serveur, plutôt que de payer des journées de développements.
Aucun raisonnement n'est stupide s'il est argumenté.
8  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 31/01/2017 à 20:05
Merci fr1man d'apporter un peu de nuance là dedans car franchement ça fout la trouille ce qu'on lit comme généralisation.

Il y a des cas d'utilisation parfaitement valides pour tout type de solution. Devoir gonfler un serveur pour supporter la charge ça peut être un choix plus avisé que de passer des jours à optimiser un système sans garantie de résultat et en prenant le risque de casser. Oui c'est moche, mais c'est la vie . Les applications légères et élégantes à leur début mais auxquelles on a fait avaler n'importe quoi par la suite, où les compétences se sont éparpillées et perdues en route, ça devrait pas exister mais ça existe.

Un ORM est un outil, un moyen, s'il expédie n'importe quoi comme requête à la DB, c'est que la personne qui s'en servait ne savait pas ce qu'elle faisait. Marrant d'attribuer systématiquement l'outil la responsabilité d'un boulot mal fait. Mais bon on voit ça tout le temps.

Pour le noSQL, faut voir le contexte, si c'est pour faire des modélisations qui demanderaient à un SGBDR traditionnel un modèle en EAV comme certaines solutions eCommerce. Ca peut tout à fait faire du sens.
3  0 
Avatar de Pill_S
Membre expert https://www.developpez.com
Le 02/02/2017 à 10:08
Citation Envoyé par _skip Voir le message
Merci fr1man d'apporter un peu de nuance là dedans car franchement ça fout la trouille ce qu'on lit comme généralisation.
Tout à fait d'accord. Vous êtes quand même tous en train de vous plaindre que votre marteau "automatique" tape moins vite que votre marteau manuel. Personne ne se dit à un moment que le marteau automatique était peut-être plus complexe, et donc nécessitait un poil plus de réflexion avant d'être efficace?

Avec des raisonnements pareils, on se remettrait tous à l'assembleur sous prétexte que c'est plus perfo...
2  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 23/06/2009 à 16:20
De mon côté, nous utilisons joyeusement des outils comme cayenne (+ comme un mapper) et le gain de développement est réel.

Je pense que c'est presque un mythe de vouloir un monde full OO lorsqu'il y a une base de données relationnelle derrière, et c'est peut être là que certains débutants font des erreurs.

Celle que je vois souvent, c'est par exemple négliger les fonctions aggrégats.
Commencer à faire des sommes en bouclant sur une collections de "Orders" d'un objet "customer" en ne se rendant pas compte que cela nécessitera le chargement de certaines branches dans le graphe objet alors qu'on peut résoudre ceci efficacement en 1 aller-retour à l'aide d'une SUM en SQL et une ou deux jointures.
Un autre exemple qui revient souvent, c'est charger une collection d'objet à l'aide d'un select puis ensuite supprimer ses membres un à un au lieu de balancer tout de suite un DELETE en sql.

Pour éviter ça, je pense qu'il est simplement important de garder un oeil sur le code SQL envoyé par l'ORM à la base de données et ne pas attendre pour s'inquéter lorsqu'on constate que ça ne correspond pas du tout au SQL qu'on écrirait soi-même naturellement (multiples requêtes au lieu de jointures, etc...).

Pour ce qui est des procédures stockées, nous évitons car cela nous semble difficile d'implémenter du code métier en SQL plutôt qu'en java, et un mélange des deux risquerait de compliquer la maintenance.
Par contre y avoir exceptionnellement recours pour des traitements qui nécessiteraient beaucoup d'aller-retours, c'est tout à fait admis ici. Mais hors de question de faire des Insert et des Update d'une seule ligne avec des procédures stockées.
1  0 
Avatar de brice01
Membre régulier https://www.developpez.com
Le 23/06/2009 à 18:20
Ne faudrait il pas que les éditeurs de SGBD respectent la norme SQL et l'enrichissent si nécessaire ?
Cela résoudrais le problème de portabilité !
1  0 
Avatar de _skip
Expert éminent https://www.developpez.com
Le 24/06/2009 à 9:14
Dans le cas d'une interface de recherche multi-critère...
Formater ses requêtes en pur SQL en ajoutant à la demande des AND dans une clause WHERE, des colonnes dans un ORDER et des JOIN de tous les côtés puis ensuite binder les paramètres à leur valeur finale alors que leur nombre dépend du contexte, c'est pénible.

Ca fait une sacré plomberie qui atteint facilement la bonne centaine de lignes de code et dans laquelle on a vite fait de se gourrer (tant malin qu'on soit).

Puis ensuite vient la conversion du resultSet en objet ou à nouveau on est bon pour faire du copier-coller et oublier de modifier le nom d'une colonne sur les 20-30 propriétés de l'objet qui doivent être affectés.
Les tests unitaires peuvent supprimer une partie des erreurs dus a la syntaxe, mais difficilement une faute style affectation d'une colonne à la mauvaise propriété.

Plus de tâches répétitives et ingrates à faire à la main, c'est parfois plus de code, plus de chance de se gourrer, plus de difficulté en cas d'évolution.

Citation Envoyé par dingoth
Pour maintenir à la fois des procédures stockées et du code java, je vois bien la difficulté que l'on pourrait ressentir. Cependant, elle n'est pas présente. Il suffit de savoir séparer d'une part les données et d'autre part le reste (et pas spécialement la couche de présentation : la coordination entre les systèmes par exemple). La maintenance est relativement aisée, malgré les centaines de procédures stockées et les milliers de classes que nous avons.
Mais que font vos procédures stockées? Sont elles plutôt orientées "métier" ou font elles surtout de la manipulation de données.
Par exemple est-ce qu'une opération CRUD est une procédure stockée? Avez-vous des exemples de choses que vous faites en procédure stockée que souvent les développeurs tenderaient à faire coté client?
1  0 
Avatar de B.AF
Membre chevronné https://www.developpez.com
Le 06/07/2009 à 16:52
Ben là, t'as tout compris.

Voilà !


Et on va en revenir à l'éternel recommencement : c'est la conception globale qui est importante, la conception technique n'est qu'un étape.

Donc, le choix d'un ORM arrive tard, et au moment où il arrive, il doit faire du sens.

Et comme tu dis, si l'application fonctionne, est testable correctement, évolutive avec un cout technique moindre, avec des coûts de maintenance réduits, tu es pas loin d'avoir bien bossé !!!!


Dans notre métier il y a théorie et pratique, les théoriciens fondent leurs théories souvent sur des exemples triviaux et répétitifs (pet shop et autres)

Dans la pratique, l'informatique est vivante et on a tendance à oublier que développer prend aussi du temps, et que toute chose étant égale par ailleurs, une application est aussi développée avec le standards du moment.
1  0 
Avatar de B.AF
Membre chevronné https://www.developpez.com
Le 09/07/2009 à 18:31
Citation Envoyé par lespoches Voir le message
Tout ca pour dire que les ORM sont très largement répandu et qu'ils conviennent à la majorité des projets (même ceux à risque). D'autre part, je ne pense pas que l'API de persistance Java est vu le jour comme ca juste pour le fun. Il s'agit d'une capitalisation de best-practice sur un nombre majoritaire de projet orienté nouvelle techno.
Oui enfin nouvelle techno, hibernate, ca reste du java et une librairie, rien de plus. C'est plus un concept qu'une techno.

Après une autre réalité, c'est que ce n'est pas parce que la majorité utilise une techno que cela en fait la meilleure. C'est la plus répandue. Point.

Les ORM ne conviennent pas à la majorité des projets : embarqué ? client mobile ? pas de db ? traitements de fichier ? Calculs scientifiques ?

L'ORM c'est surtout un choix. Souvent mal fait parce que facilité, et après mal utilisé parce qu'on se dit "bon ben je vais générer du code maintenant". C'est surtout ça la réalité de l'ORM.

Et en plus, ils ne fonctionnent pas tous de la même façon, n'ont pas tous les mêmes patterns et les même contraintes.

C'est comme SQL Server et ORACLE : connaitre le SQL n'a jamais garanti qu'on puisse se servir parfaitement des deux.

C'est comme hibernate : connaitre le java n'a jamais garanti qu'on s'en serve correctement. Je serai curieux, parce que je n'en ai jamais rencontré en fait, de connaitre la statistique exacte du nombre de personnes qui ont déjà forké, modifié ou simplement regardé à l'intérieur du moteur pour comprendre.

Je dirai 5%. Pas plus. Comme les utilisateurs de JBoss d'ailleurs.
1  0 
Avatar de ego
Rédacteur https://www.developpez.com
Le 16/01/2010 à 14:00
Citation Envoyé par SQLpro Voir le message
C'est d'un simplicité enfantine.
Si vous avez lu l'article en entier je conseille de ne travailler qu'avec des procédure stockées, ce qui est le plus portable, et d'en faire une pour chaque CRUD (INSERT, SELECT, UPDATE, DELETE).
Il est alors d'une simplicité biblique de les tester unitairement...

A +

Est-ce que ce que tu veux dire c'est que finalement, les drivers ODBC ou JDBC (en ne prenant que cela) ne servent finalement à rien. Les éditeurs ne devraient offrir que l'exécution de procédures stockées et pas d'ordres SQL ?
L'ensemble de l'industrie se serait donc trompé sur les outils mis à disposition des développeurs ?

J'ai bien compris ta position ?
1  0 
Avatar de Fabske
Futur Membre du Club https://www.developpez.com
Le 24/01/2010 à 18:18
Je découvre ce sujet, et me suis dit que c'est assez marrant car c'est le même genre de débat qui se passe un peu partout depuis ... 4 ans. Oui à l'époque c'était pas trop les ORM, mais plutôt Store Proc vs Query dynamique. D'ailleurs le 1er post (de SqlPro) fait un peu un amalgame entre ORM et Query dynamic.

Il y a 4 ans pour développer une nouvelle application j'ai du faire le choix entre un ORM ou travailler par Store Proc. J'ai choisi l'ORM, pour le nommer c'est LLBLGEN. Après 4 ans, je peux en faire un bilan. Evidemment je n'ai pas utilisé d'autres ORM depuis, mais ça peut donner une idée.

Performances:
Les performances par rapport à une Store Proc "crud" sont bien plus basse. Mais si on veut faire une SP qui sélectionne les données sur plusieurs critères qui peuvent être null, on en arrive à créer la query dans la SP et là les perf sont semblables. Ou alors ont doit faire 1 SP par combinaison de critères null/non-null et là on se retrouve vite avec des milliers de SP. Bref au niveau performance, pour moi c'est ok tant que ce n'est pas un point critique. Dans mon projet, quelques fonctionnalités très intensives sur les données ont été faites sous SP, et donc l'ORM gère 95% des queries.
De la même manière, il faut surveiller les queries générées par l'ORM pour détecter les problèmes de performance, et réécrire ces queries (en utilisant l'ORM differemment ou en utilisant une SP) si nécessaire.
Le plus gros désavantage a été l'utilisation plus élevée de la mémoire. Quand on travaille sur des milliers d'objets en même temps, ça commence à devenir limite. Donc à ne pas utiliser si c'est un point critique ou en tenir compte dans le design de ce genre de process (ce qu'on a fait).

Réseau:
Le paragraphe sur le temps réseau qui augmente le lock est vrai, mais ce n'est pas spécifique à un ORM. Si on prend cet argument en compte alors il ne faut plus jamais écrire de query dynamique et uniquement fonctionner avec des store proc.

Temps de développement plus court: vrai ... et faux dans certains cas.
Vrai, SI on connait l'ORM assez bien (ou si le projet est long, comme dans mon cas sur plusieurs années). Apprendre à utiliser un ORM pour un projet de 3-6 mois, c'est une perte de temps. Mais si on le connait bien, ça fait gagner un temps énorme.

Indépendance vis-à-vis de la db: vrai ... et faux, à nouveau.
On peut jamais être complètement indépendant (il y aura toujours des SP & View à maintenir pour chaque type de DB). Mais si dès le design on pense aux spécificités de chaque type de DB sous lequel ça va tourner (type de champs, longueur des noms, héritage etc.) on peut en effet arriver, avec un ORM, à avoir le même code qui tourne sous plusieurs SGBDR. Mais ça veut dire
1) Il faut quand même réécrire et maintenir les SP & views,
2) Il ne faut utiliser aucune fonctionalité propre à un SGBDR (c'est si vite fait...). Ca implique une bonne connaissances des SGBD

La phrase pour la maintenance d'un service à froid (dans le 1er post du thread), j'ai rien pigé, désolé .

En résumé:
On peut faire ce qu'on veut, rajouter une couche ne peut qu'alourdir / ralentir le traitement (c'est la même chose avec LINQ p.ex.). Maisç a a tjrs été comme ça. Le .NET lui^même est un exemple (les applications real-time sont toujours faite en c++).
Mais par contre ça a beaucoup d'autres avantages. En tout cas moi j'ai été convaincu de l'utilité des ORM. En plus, les serveurs sont toujours plus puissant et ont tjs plus de mémoire, alors si on peut se le permettre autant utiliser ça (sinon, on coderait toujours en assembleur).
Bref, les ORM c'est comme toutes les autres technologies: il faut voir en fonction du projet si c'est utile.
1  0