Par Frédéric Esnault, Directeur Technique Open Wide Technologies
Pourtant, la réalité est plus subtile et nous constatons sur les projets que si le principe de l’usage d’un ORM est moins discuté aujourd’hui, son application ne se fait pas sans douleur. Le problème essentiel, c’est que cette pratique donne bien l’illusion d’avoir une base de données orientée objet alors qu’il n’en est rien. Et la problématique de manipulation de données telle qu’elle a été couverte par les bases de données relationnelles est tellement spécifique qu’à un moment ou à un autre, cette fameuse « illusion » nous revient à la figure…
Un outil à ne pas mettre entre toutes les mains
En effet, qu’il s’agisse de la complexité du mapping d’une base existante ou à l’inverse, de l’inadaptation des schémas générés depuis un modèle objet aux exigences du relationnel, l’ORM c’est un peu le tapis sous lequel on cache la poussière : on croise les doigts pour n’avoir jamais à le soulever… D’après mon expérience, la grande majorité des problèmes de performance des applications de gestion en Java sont justement situés à ce niveau.
Beaucoup de développeurs Java n’ont pas une culture suffisante des bases de données relationnelles et de la manière dont leur outil de persistance va intéragir avec elles. Ils ont tendance à croire que ce n’est pas nécessaire puisque les ORM sont justement là pour éviter de s’en préoccuper. Et c’est là que l’erreur se situe souvent. Combien d’applications explosent-elles au moment de la recette, quand ce n’est pas directement à la mise en prod, parceque les développeurs ont consciencieusement décrit leur modèle objet avec toutes les relations possibles et imaginables, ce qui conduit au chargement de la moitié des données à la moindre requête ?
Alors vous me répondrez sans doute que ces problèmes sont souvent liés à une mauvaise utilisation de l’ORM.C’est vrai. Quand on sait faire les bons mappings, quand on écrit des requêtes de façon judicieuse, quand on sait éviter les pièges, ça se passe beaucoup mieux. Mais arriver à un résultat efficace nécessite une bonne connaissance de ces aspects et justement… une bonne maîtrise du fonctionnement des bases sous-jacentes. La question se pose alors : à quoi bon devoir utiliser un ORM s’il faut quand même bien connaître le SGBDR et en plus maîtriser l’ORMsur le bout des doigts ?
De fausses bonnes idées
Pour avoir connu l’époque où il fallait se contenter de JDBC, je ne peux que soutenir un outil qui permet d’éviter tout ce code rébarbatif pour copier mes données de Result Setvers mes objets ou pour écrire des requêtes de mise à jour en fonction des changements opérés sur un objet. Par contre, le besoin d’éviter à tout prix le SQL, de vouloir monter les relations de façon « automatique » ne m’est jamais apparu évident.J’ai l’impression qu’il est né d’une position dogmatique de développeurs Java qui ne voulaient pas voir le code pollué par un paradigme étranger. Ca part d’un bon sentiment mais force est de constater que quand on utilise un SGBDR, on ne peut pas faire comme s’il n’existait pas !
L’ORM apporte en outre des mécanismes délicats à maîtriser. Rien que l’option du « lazy loading » me semble une fausse bonne idée :cela présente un confort au départ mais l’exécution de requêtes masquées à des moments mal maîtrisés, alorsque la session peut se trouver dans un état inapproprié, se révèle gênante. Elle est de plus incompatible avec les architectures SOA et notamment peu utilisable avec des web services. Plus généralement, l’ORM considère le modèle objet au détriment de l’approche orientée services qui est pourtant la plus courante pour les applications n-tiers.
Conclusion
Bref, sans vouloir rejeter en bloc les ORMs, je pense utile d’insister sur les précautions à prendre quand on les utilise. J’aurais tendance à préconiser un pragmatisme fort visant à exploiter l’ORM simplement comme un outil permettant d’alléger le code tout en évitant les fonctionnalités incompatibles avec les choix d’architecture. En ce sens, un outil comme MyBatis (ex iBatis SQLMaps) me semble intéressant dans son positionnement par rapport à cette problématique.
Que les puristes m’excusent mais quitte à être puriste, autant faire de l’objet de bout en bout avec une base de données orientée objet. Et si la base de données relationnelle s’avère incontournable, faisons avec, ça n’est pas sale !
