Magazine

Pourquoi utiliser un ORM et sur quels critères le choisir ?

Publié le 19 mai 2008 par Olivier Duval

Introduction

Dans un environnement 100 % objet, il convient de ne manipuler que des objets, que cela soit des classes métiers, ou toutes autres classes de type traitements (contrôleurs), pour plusieurs raisons :

  • cela facilite le développement en apportant une sémantique aux classes (par exemple on manipulera un objet Client qui représente un...client, et non un tableau contenant des champs issus de la base),
  • apporte des fonctionnalités en termes de collections d'objets (itérations, manipulation de type tris, ...),
  • l'accès aux propriétés (ie: champ d'une table) est fortement typé

Un ORM permet tout cela avec en plus une abstraction à l'accès aux données, ainsi que des fonctions que le développeur n'a plus ou pas à gérer et qui lui facilitent la vie : connexion à la base, instanciations des objets (ie : mapping avec prise en compte de l'héritage ou des collections pour les relations 1-n ou n-m), lazy loading, CRUD, moindre utilisation du langage SQL...on s'affranchit de beaucoup de traitements et c'est appréciable !

Une définition de Wikipédia :

L'object-relational mapping (ORM), que l'on pourrait traduire par « correspondance entre monde objet et monde relationnel » est une technique de programmation informatique qui crée l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle en définissant des correspondances entre cette base de données et les objets du langage utilisé.

Quel choix ?

Le choix est souvent difficile parmi la pléthore de framework ORM sur le marché.

Après plusieurs expériences et d'implémentations de plusieurs architectures sur des projets Web, un peu de retour d'expérience : ci-après quelques critères que l'on pourrait énumérer selon des besoins qui seront spécifiques aux projets développés et à l'architecture mise en place :

  • non polluant : personnellement, afin d'éviter d'utiliser des objets DTO qui relient les différentes couches, j'aime que les classes utilisées par l'ORM soient directement sérialisables par celui-ci et utilisables directement par les différentes couches (présentation notamment) : cela évite d'avoir une couche service par laquelle on devra mapper les objets de l'ORM vers des objets entités (objets métiers), ceci afin de conserver une astraction entre les couches supérieure et la DAO. Beaucoup d'ORM utilisent une combinaison d' attributs et d'héritage de classe pour gérer leur mapping (sur les champs, sur les tables), en cas de changement de framework, on risque de se faire coincer si on n'a pas suffisamment abstrait les classes entités.
  • SGBDR, CRUD, lazy-loading, collections, cache, héritage, transactionnel, langage d'interrogation objet
  • communauté existante : pour la correction de bugs ou tout simplement pouvoir se débloquer d'un problème d'implémentation, une communauté reste primordiale, comme tout logiciel Opensource
  • simple (si ce terme est réaliste) à mettre en oeuvre et qui s'intégre de façon transparente à la plateforme

SGBDR & CRUD

L'ORM devra fournir des mécanismes simples pour le CRUD (Create, Read, Update, Delete) des objets manipulés ainsi qu'une compatibilité avec plusieurs bases de données (MySQL, MSSQL, Oracle, PostgreSQL, ...) et aussi ne pas se soucier des identifiants (l'ID système dans nos tables).

Lors d'un développement, certaines opérations de mise à jour des données nécessitent des contraintes d'intégrités afin de ne pas avoir d'incohérences dans les données, les contraintes sont faites pour ça. L'ORM doit alors mettre en place les transactions afin d'actionner le rollback le cas échéant en cas de soucis d'insertion, de suppression ou de mise à jour d'une entité.

Lazy-loading & cache

Egalement, la gestion des collections d'objets (typiquement les relations 1-n ou n-m) devra dans la mesure du possible utiliser le lazy-loading, cela permettra d'optimiser les accès à la base, notamment pour les relations, ou les gros champs (type text / blob) : ne charger les objets uniquement lors de leur accès, économie de ressource mémoire et de charge serveur côté SGBDR, et surtout ce qui induit une réduction de temps lors de l'initialisation d'une application. Avec le même objectif d'amélioration des performances, au lieu de gérer un cache de nos objets côté présentation, l'ORM peut offrir des mécanismes évolués pour le gérer.

Mapping entités, héritage

Souvent, 1 table = 1 classe, mais on peut avoir des objets non contenus dans la même table (une adresse par exemple), mais d'une représentation strictement objet, l'information sera insérée dans un objet plus globale (un individu ayant une adresse), cela facilite les manipulations. Egalement, l'héritage peut s'avèrer très utile, l'ORM devra alors prendre en compte (ie : instancier, souvent grâce à un discriminant) les différents types qui dérivent d'une entité mère, ceux-là étant stockées dans des tables différentes que celle représentant les informations communes.

Divers

Si on veut totalement s'abstraire de la base, il convient que l'ORM implémente son propre langage d'interrogation : soit par une constructions de critères ou filtres, soit grâce à un véritable langage d'interrogation objet. Dans ce cas, on s'affranchit totalement du SQL, ce dernier peut avoir des instructions spécifiques selon le serveur de bases de données, l'ORM traduira selon la cible les bonnes instructions.

And the winner is...

Après avoir testé plusieurs types d'architectures et d'ORMs, celui qui répond le plus à nos besoins précédemment cités est : NHibernate. Je ne suis pas très attiré par les ORMs qui génére toute une couche DAO, dès qu'il faut coder du spécifique, cela peut devenir très contraignant, sans compter les milliers de lignes de code plus ou moins compréhensibles. NHibernate a une forte communauté, très active, et on trouve bon nombre de blogs spécialisés pour décortiquer la bête.

Quelques ressources

  • Optimisation et de l'intêret du lazy-loading avec NHibernate
  • Un livre blanc sur les ORM
  • NHibernate en environnement ASP.NET, les bonnes pratiques
  • La problèmatique du chargement N+1
  • FAQ NHibernate

Vous pourriez être intéressé par :

Retour à La Une de Logo Paperblog

Ces articles peuvent vous intéresser :

  • Mai pourquoi?!

    Voilà un billet d’humeur, ça va être très court je vous préviens… Mais là ça peut plus durer : Pourquoi on m’appelle au téléphone systématiquement quand je... Lire la suite

    Par  Zenstyle
    A CLASSER
  • Pourquoi…

    …la vue en direct de la misère me perturbe-t-elle autant?Chaque fois que je vois un itinérant, un vagabond, un errant déambuler sur la rue, mon cœur chamboule e... Lire la suite

    Par  Lawrence Desrosiers
    A CLASSER
  • ORM / NHibernate : mapper des sous-collections ou pas ?

    NHibernate mapper sous-collections

    Préambule Actuellement, je gère un projet de mutualisation de newsletters, celles-ci seront intégrées à notre plateforme extranet, les abonnés gérés par des... Lire la suite

    Par  Olivier Duval
    A CLASSER
  • Mais enfin.... pourquoi?

    Avec un titre aussi énigmatique, vous vous demandez bien où je veux en venir.... hein? Et bien, j'ai inauguré une rubrique reprise, mais il me reste ces... Lire la suite

    Par  Sand81
    A CLASSER
  • ~Pourquoi ? ~

    Coucou , j'allais beaucoup mieux , me posais plus de questions ; C'est vrai , tu te poses des questions t'as les réponses et rien ne change . . . Donc j'ai... Lire la suite

    Par  Girlyparadise
    A CLASSER
  • Pourquoi?

    POURQUOI ?POURQUOI ? Pourquoi en est-il ainsi? On ne le saura jamais. Les français sont des êtres profondément négatifs et mesquins. Jaloux et psychotiques. Lire la suite

    Par  Xavier1
    A CLASSER
  • Pourquoi j'aime les télénovelas

    Bonjour, Avant de commencer ce billet qui traitera de "pourquoi j'aime les télénovelas", je vais d'abord rassurer la quinzaine de personnes, fans de Secret Stor... Lire la suite

    Par  Olgablog
    A CLASSER

A propos de l’auteur


Olivier Duval 4 partages Voir son profil
Voir son blog

l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte l'auteur n'a pas encore renseigné son compte

Dossier Paperblog