Blog

ADO.NET Data Services (nom de code Astoria) est un framework permettant l’exposition de services d’accès au données accessibles à distance.

Ce type de service permet notamment aux applications riches internet (Silverlight, ASP.NET AJAX Framework) et desktop (Windows Forms) d’accéder à des données sans s’adresser directement à la base de données, ce qui est souvent impossible dans de tels scénarios.

La sortie d’ADO.NET Data Services est prévue pour juin ou juillet 2008.

Principes généraux

ADO.NET Data Services fournit un service générique permettant d’exposer des données issues d’ADO.NET Entity Framework, et éventuellement d’autres sources de données. La description des données exposées sont également décrites par des métadonnées publiées par le service. Le service générique est implémenté en s’appuyant sur WCF (Windows Communication Fondation) qui permet le support de JSON et d’Atom dans .NET 3.5.

On communique avec ce service générique en adressant des requêtes qui permettent de :

• Consulter les entités (filtres, tris …)
• Créer des entités
• Mettre à jour des entités
• Supprimer des entités

Ce service générique est fondé sur une architecture REST :

• Utilisation de HTTP et des verbes standards (POST, GET, PUT, DELETE)
• Utilisation de l’URL et de divers paramètres pour exprimer les requêtes de consultation des entités
• Utilisation des attributs du POST pour les requêtes de création, mise à jour, et suppression d’entités
• Utilisation de JSON (JavaScript Object Notation) ou d’Atom pour la réponse.

Le client du service utilise une API différente selon sa nature :

• Pour les clients Windows Forms et Silverlight 2.0, on peut accéder aux données en utilisant LINQ avec le provider LINQ for HTTP.
• Pour les clients Web ou Silverlight 1.0, il existe également un API client JavaScript qui permet d’accéder aux services ADO.NET Data Services.

Sécurité des données

Il est possible de restreindre l’accès aux entités, selon l’utilisateur, et de gérer les droits en consultation, modification, création et suppression. Il est également possible de filtrer les données, selon l’utilisateur, via un système à base d’intercepteur, très similaire à ce celui de Spring Security (ex Spring Acegi) dans le monde Java.

Le filtrage des données est formulé grâce à LINQ avec une rare élégance. C’est bluffant !

En guise de conclusion

ADO.NET Data Services est une technologie très prometteuse, à surveiller de prêt ! Rendez-vous en juin ou juillet, si tout va bien.

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 !

Google propose un nouveau framework d'injection, baptisé Guice (à prononcer juice), et fondé sur des annotations. Un débat très intéressant, initié suite à un blog de Craig Walls, a lieu entre la communauté Spring (le framework d'injection standard de fait) et les créateurs de Guice.

L'argumentaire de Craig Walls en faveur de Spring est, à mon avis, particulièrement convaincant, et l'essentiel des remarques est tout à fait justifié :

• Spring est bien moins intrusif. Guice oblige a annoter les classes, Spring non.
• L’injection de valeurs simples en Spring est beaucoup plus simple qu’avec Guice.
• Spring peut injecter dans des classes quelconques, pas seulement dans des classes annotées comme Guice. Il est vrai que Guice offre la notion d’adaptateur, mais cela nécessite d’écrire du code.

Dans la mythologie de l'heroic fantasy, le blob est un monstre gélatineux, de grande taille, dans lequel on ne parvient à distinguer aucune structure particulière. Tel un globule blanc, cette créature phagocyte tout ce qui s'en approche, et grossie à mesure qu'elle se nourrit. Le blob inspire la crainte, et personne ne souhaite vraiment s'en approcher.

Le code-blob, c'est une portion de code de l'application (généralement le corps d'une méthode ou d'une fonction) constituée d'un nombre important de lignes. Les blocs conditionnels et les boucle sont de grande, voire de très grande taille. Le niveau d'imbrication est élevé. L'ensemble n'est pas structuré, et aborde d'un seul tenant de très nombreuses considérations : écriture dans un fichier texte, accès à une base de données, parsing d'un fichier XML, traitement métier, délimitation du périmètre transactionnel, libération des ressources, gestion d'erreur ...

L'ensemble est très peu compréhensible. Certes, avec du temps et de l'énergie, on n'arrive effectivement à en acquérir une compréhension grossière. Le code 'blob' reste cependant très difficile à faire évoluer, à déboguer et à tester unitairement. En cas de problèmes de performances, le diagnostic est également considérablement complexifié.

Bien-sûr, personne ne souhaite vraiment intervenir dans un tel code. Ceux qui s'y frotte ajoutent généralement quelque lignes à la marge, et accumule les astuces pour ne pas risquer de perturber le fonctionnement de ce fragile édifice. Ce faisant, on nourrit le blob et il devient plus gros encore. Mais alors, pourquoi ne pas tuer le blob, plutôt que de le nourrir ?

Le problème est qu'en tuant le blob d'un coup net, il faut trouver une solution de rechange. Il faut soit réécrire, soit se lancer dans un refactoring plutôt ambitieux. Le coût d'une telle opération est difficile à justifier, d'autant plus qu'elle aboutit à des fonctionnalités strictement identiques. Cette approche contribue également à présenter la qualité uniquement sous la forme d'un coût, avec des bénéfices apparemment faibles.

Clairement, il est préférable de tuer le blob à petit feu : organiser progressivement l'intérieur du bloc, sortir progressivement les parties saines et les péreniser. Un tel travail n'est pas une tâche spécifique dans un planning, c'est un effort continu disséminé tout au long du projet. Au même titre que les tests unitaires, le maintien de la qualité du code est un effort réalisé lors de chaque tâche de développement.

Certes, on peut se trouver toutes les bonnes raisons du monde de remettre ce travail au lendemain. Mais il faut bien se dire qu'un code-blob nait de l'accumulation de petits efforts jamais entrepris. Annihiler un blob naissant ne prend que quelques minutes, tout au plus une demi-heure. Pas de quoi justifier un tâche dans un planning.

Les consultants Neoxia présentent leur vision et apportent leur avis sur les grands thèmes d'architecture IT du moment :

• Architecture générale
• Architectures Orientées Services (SOA)
• Client riche (AJAX, Laszlo, XUL, XAML, Eclipse RCP, JDNC, ...)
• Java/J2EE
• .Net
• Open Source
• ...