ADO.NET est un framework de mapping objet / relationnel similaire à Hibernate ou TopLink, même si Microsoft s’en défend quelque peu. Sa sortie est prévue pour juin ou juillet 2008.

Modélisation

Dans ADO.NET Entity Framework, l’objectif est de modéliser et manipuler les données non plus sous forme de tables, mais sous forme d’entités.

La modélisation est effectuée selon 3 points de vue distincts :

  • le Conceptual model (modèle conceptuel), appelé aussi EDM (Entity Data Model), qui décrit les entités (attributs, et opérations) et les associations,
  • le Storage model (modèle physique), qui décrit les tables (colonnes, références) et les procédures stockées,
  • le Mapping entre conceptual model et le storage model, qui décrit la correspondance (mapping) entre les tables et les entités.

Chacun de ces 3 points de vue est décrit sous forme d’un document XML (ou d’un fragment XML).

À mon sens, l’existence d’un EDM indépendant du code est un atout du framework.

Génération de code

À partir de l’EDM, il est possible de générer des classes représentant les entités sous forme d’objets. Cette génération produit également une classe qui représente le modèle dans son ensemble, et fournit des ensembles permettant d’interroger les différents types d’entité (entity set). Ces classes sont des classes partielles.

Langages de requêtes

L’EDM peut être interrogé en formulant des requêtes :

  • en Entity SQL (eSQL), langage de requête textuel de type SQL,
  • en LINQ, langage de requête fortement typé (donc vérifié à la compilation) et intégré directement au langage de programmation (C#, VB.NET …).

Fonctionnalités de mapping

Les fonctionnalités de mapping sont riches et assez classiques :

  • mapping des champs,
  • mapping des associations,
  • mapping de l’héritage,
  • mapping des types complexes,
  • mapping des opérations sur des procédures stockées.

Suivi des modifications

Les changements effectués sur le modèle doivent être déclarés auprès du cache de tracking associé au modèle.

  • Les entités nouvellement créé doivent être déclarées auprès du cache.
  • Les entités modifiées doivent, semble-t-il, être déclarées auprès du cache, également.

Une méthode du modèle permet de jouer sur la base de données tous les changements déclarés auprès du cache de tracking.

À mon sens, cette séparation claire du suivi des changements semble être un atout de framework.

Optimisation du chargement des données

Dans une requête, il est possible de déclarer les données à charger en même temps que les entités requêtées. Il s’agit en fait d’entités connectées aux entités requêtées via des associations. Par exemple, si l’on requête des clients, il est possible de dire, par la même occasion, que l’on souhaite ramener les commandes de ces clients.

Pour les connaisseurs, à ce jour, il n’y a pas de ‘lazy loading ». À la traversée d’une association, les entités ne sont pas chargées automatiquement à la demande. Lorsqu’on accède à la propriété correspondant à un sens de circulation de l’association, tout se passe comme s’il n’y avait pas d’entités associées. Il n’y a aucune erreur. Pour charger les entités associées, il faut le faire explicitement en appelant une méthode sur la propriété. Il y a également une propriété permettant de savoir si l’association a déjà été chargée.

À surveiller de prêt !

Billets sur le même thème