J'aime bien l'approche ADO.NET Data Services (anciennement Astoria), qui consiste à générer une couche d'API REST au dessus de l'accès aux données, plus précisément au-dessus de tout accès aux données qui implémente IQueryable et optionnellement IUpdateable (oui c'est bien IUpdateable, pas IUpdatable).
Ces deux interfaces, aujourd'hui implémentées par Entity Framework, sont le moyen par lequel d'autres systèmes de persistance pourront être exposés à la mode "ADO.NET Data Services" (encore un nom à rallonge qui va finir en acronyme obscur, Astoria c'était quand même plus facilement écrit et retenu). Nhibernate notamment pourrait bien être un des premiers ORM open-source à pouvoir être exposé en REST par ADO.NET Data Services. Shawn Wildermuth y travaille.
Ayende Rahien a annoncé samedi sur son blog la sortie de la version 2.0 de NHibernate. Cette version propose les mêmes fonctionnalités que son pendant Java (Hibernate 3.2) , plus quelques particularités uniques à .Net.
Pendant ce temps, Microsoft livre la première version release de son outil ORM Entity Framework en le joignant au SP1 de .Net 3.5.
C'est donc le moment de savourer la liberté de choisir son ORM. Et de prendre le temps de comparer.
Hibernate et son cousin .Net NHibernate souffrent d’un handicap qui nuit à leur réputation. Dès 2006 Sami Jaber constatait que les premiers retours terrain étaient plutôt désastreux : "[...] des requêtes SQL générées de 70 pages imprimées (véridique), parfois 300 ou 400 requêtes par formulaires et des DBA qui crient au scandale".
Implicit Lazy loading
Le lazy loading implicite (littéralement "chargement paresseux") mis en œuvre par (N)Hibernate est en grande partie responsable de cette notoriété reprochable. Typiquement en lazy loading, un objet (disons client) dont les propriétés ont été renseignées par NHibernate verra ses objets associés (disons client.Commandes) initialisés paresseusement par une requête SQL, c'est-à-dire seulement quand nécessaire et si nécessaire.
Lazy road crossing. Rien à voir. Désolé.
Jusque là tout va bien, le lazy loading c'est plutôt bien pour éviter que toute la base de données ne se retrouve en mémoire par le biais de plusieurs associations.
Le hic, c'est que toute cette mécanique de requêtage automatique de la base de données se produit implicitement, presque à l'insu du développeur. Par exemple si le développeur doit écrire une itération sur tous les client.Commandes pour calculer le total des commandes, il écrira une boucle foreach (Commande commande in client.Commandes), et NHibernate va silencieusement générer et exécuter autant de requêtes SQL que de commandes associées à cet objet client. 150 commandes ? 150 requêtes envoyées une-à-une à la base de données...
D'un côté c'est génial parce que le développeur peut manipuler des objets C# purs et durs en ignorant qu'une base de données est à l'œuvre derrière le décor, orchestrée par NHibernate. De l'autre, et pour les même raisons, c'est une catastrophe. En ignorant la réalité du SGDB, les performances chutent et les DBA crient au scandale, parce que la façon optimale de charger des données en mémoire dépend, au cas par cas, de l'usage que l'on s'apprête à en faire. NHibernate n'ayant aucune vision de cet usage, l'optimisation des requêtes ne peut être menée que par le développeur grâce aux outils (join fetch par exemple) de NHibernate.
Malheureusement, quelles que soient les possibilités qu'offre NHibernate pour forcer le chargement d'une collection d'objets en un seul aller-retour SQL, le seul fait que le développeur ait la possibilité d'ignorer le moyen par lequel les objets persistent (conformément au principe de Persistence Ignorance –PI– de l'approche Domain Driven Design –DDD) promet quelques utilisateurs énervés par la lenteur de certains traitements, des DBA scandalisés et finalement des clients mécontents. Bref une sale réputation.
Explicit loading
Et c'est donc une décision marketing qui a conduit l'équipe Microsoft responsable d'Entity Framework à choisir le chargement explicite (explicit loading) plutôt qu'implicite. Dans le dernier numéro de MSDN Magazine, l'encart intitulé "Insights: Entity Framework Data Loading" et signé DiegoVega est clair à ce propos : " Following the "no hidden network roundtrips" principle, Entity Framework avoids automatic lazy loading".
Aucun aller-retour avec le SGBD n'aura lieu sans que le développeur ne le sache.
Le principe de l'explicit loading est simple : tant que le développeur n'a pas écrit le nécessaire pour charger une Commande de notre association client.Commandes, l'accès à une de ces commandes déclenche une exception. En explicit loading, les développeurs se soucient du SGBD, les DBA sont heureux, et l'image de Microsoft est sauve.
Entity Framework, la couche de mapping objets/base de données relationelle (ORM) de .Net actuellement en beta 3, sera multi-database comme l'est Nhibernate. On pourra basculer de SQL Server vers MySql aussi facilement qu'on change de T-shirt (oui, vous faites bien de vous méfier de ce genre de promesses...).
Pour preuve, ces éditeurs cités par InfoQ prévoient de livrer des providers ADO.Net compatibles Entity Framework pour Oracle, MySQL, PostgreSQL, SQLite et DB2 : http://www.infoq.com/news/2008/05/ADO.NETProvider
MSDN Magazine de septembre contient deux articles sur l'accès aux données depuis une application Silverlight. Ils proposent deux voies différentes :
Les commentaires récents