Êtes-vous pour ou contre les ORM ?

Un blogueur invite à tenir le bâton par le milieu

S'il y a bien une constante dans la nature humaine, c'est celle qui rend tellement rare qu'un choix ou un avis particulier fasse partout l'unanimité.
Le monde de l'informatique et du développement ne dérogent pas à cette règle. C'est même un domaine où les guéguerres idéologiques peuvent être les plus enflammées et les opinions des plus tranchées.

Des décennies durant, de vifs débats reviennent encore et encore dans les communautés de développement : Big Endian vs Little Endian, EMACS vs Vi(m) ou Java vs .NET, pour ne citer que les plus notables.

Mais au-delà du débat, constructif ou répétitif, il est incontestable que le vrai gagnant est celui qui arrive à synthétiser les qualités et les faiblesses de chaque opinion dans un contexte précis. Qui arrive à en extraire l'essence pour adapter son choix au besoin particulier de chacun.

C'est avec cette philosophie qu'aborde Andy Boothe le débat sur les ORM dans un billet de son blog SIGPWNED.

L'ORM (mapping objet-relationnel) est une technique 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é.



Andy Boothe commence par étayer les avis de chacun, pour nous laisser les meilleures pratiques pour la fin. Entre les modeleurs (les pro-ORM) et les persistants (les anti-ORM), Andy préconise les habitudes suivantes :

• Utilisez des objets modèles les plus simples possible, lors de l'utilisation de l'ORM. Il faut être vigilant de ne pas sur-simplifier et s'assurer que les modèles reflètent tout simplement l'ancien modèle de données. Autrement on fera face à un effort non négligeable avec l'ORM pour s'assurer que la persistance marche comme prévu pour ne pas chercher des méthodes et des propriétés manquantes.
• Si vous n'utilisez pas l'ORM, vous devez probablement définir des DAO (Data Access Objects) ou des méthodes de requête et de persistance, pour éviter un couplage fort entre la couche modèle et la couche persistance. Sinon, vous vous retrouverez avec du SQL dans les objets modèles et avec une dépendance forcée.
• Si vous savez que les schémas d'accès aux données seront simples, mais vous ne les cernez pas entièrement, vous devriez songer à utiliser un ORM. Même si les ORM peuvent rendre difficile de créer et de déboguer les requêtes complexes, ils s'avèrent efficaces et permettent de gagner beaucoup de temps pour des requêtes simples.
• Si vous savez que les schémas d'accès aux données seront complexes ou que divers mécanismes spécifiques à un SGBD particulier seront utilisés, il est préférable d'éviter les ORM. Même si certains ORM, tels que Hibernate, permettent un accès facile à la connexion sous-jacente, les avantages seront perdus si vous vous retrouvez à utiliser beaucoup de SQL personnalisé.
• Si la rapidité d'accès devient critique, évitez si possible l'ORM. La seule façon d'être sûr que les requêtes s'exécutent rapidement est de bien structurer votre base de données, de gérer votre schéma d'accès aux données avec un soin extrême, de s'engager à utiliser un seul SGBD et d'optimiser les requêtes pour ce dernier. Néanmoins, c'est rare de trouver des logiciels qui ont vraiment besoin d'un tel besoin extrême de rapidité d'accès aux données.

Et vous ?

Êtes-vous pour ou contre les ORM ?
Pouvez-vous justifier votre choix ?
Votre choix s'adapte-t-il au type de développement que vous faites ?

Source : Billet de blog de sigpwned