Etude exploratoire de Linq - CoDE - de l'Université libre de Bruxelles

que les attributs de cette table doivent être accédés par la méthode Field en précisant
explicitement la nature de T, car le compilateur ne pourrait réaliser l’inférence depuis un champ
d’une DataTable. Ceci n’est simplement pas prévu. Peut-être cela changera-t-il dans le futur, mais
pour l’heure nous devons nous-mêmes fournir les informations qui sont en réalité des informations
de mapping encore une fois. Pour en revenir à l’opérateur AsEnumerable, il s’agit d’un opérateur
réalisant la conversion à la volée. Il s’applique à une séquence d’éléments et va les encapsuler dans
une nouvelle séquence d’objets implémentant IEnumerable. Cet opérateur peut être redéfini,
offrant ainsi la possibilité de créer des variantes adaptées au contexte.
En ce qui concerne les performances, la question est de mettre en balance ce que Linq apporte et les
délais introduits. Le mapping est réalisé par le DataSet lui-même et des instructions explicites au
niveau du code. Aucune logique de mapping automatique ne vient alourdir l’usage classique d’un
DataSet. Les performances en termes de temps de réponses seront fonction du contexte et non du
choix d’avoir ou non utilisé Linq. Notons tout de même que l’utilisation de telles structures n’est pas
toujours aisée et en particulier traduire une requête en langage naturel devrait être beaucoup plus
simple en utilisant Linq.
Avec Linq to DataSet, nous avons une solution portable vers tout type de base de données et même
vers d’autres systèmes de persistance car, rappelons-le, un DataSet représente simplement une
collection de données. Cela permet d’utiliser le confort lié aux requêtes de Linq, certes, mais Linq to
DataSet demande pas mal de réglages de la part du développeur, notamment d’assurer le suivi entre
le DataSet et la base de données. Il s’agit là d’un inconvénient majeur puisque cela peut amener des
problèmes liés à la synchronisation ainsi que toute la panoplie d’erreurs classiques liées à l’accès aux
données en Sql. Ceci ne constitue pas alternative à Linq to Sql mais plutôt comme un complément
pour répondre aux besoins des développeurs ayant choisi de manipuler des DataSets ou ayant à
maintenir des applications qui en font toujours usage. [4] maintient que « les DataSets sont une
composante importante de la couche ADO.NET », ce qui fait de Linq to DataSet un outil appréciable.
4.4 Linq to Entities
Une autre implémentation ayant pour cible des données relationnelles s’appelle Linq to Entities. Le
terme Entities dans son nom fait référence à la technologie Entity Framework, qui est une évolution
de la couche ADO.NET que nous appellerons par raccourci EF. EF est légèrement plus récent encore
que Linq. Nous allons brièvement introduire les idées fondatrices de cette technologie ainsi que ses
principaux concepts. Nous tenterons ensuite de mettre en lumière les forces et faiblesses de ce
framework, tout en particularisant cela aux contributions de Linq to Entities. Cette section puise ses
informations principalement de [5] pour EF et de [1] pour Linq to Entities.
4.4.1 Concepts fondateurs
L’idée au départ de l’EF est celle-là même qui a amené Linq. Nous pourrions résumer cette idée de
base en « une application orientée objet ne devrait pas dépendre des mécanismes de persistance ».
Nous n’allons pas expliquer à nouveau le problème de correspondance entre l’orienté objet et le
relationnel mais nous allons plutôt ce problème dans le contexte de la deuxième édition du
framework .NET. A cette époque pas si lointaine d’ailleurs, les accès relationnels se faisaient en
utilisant les services de la couche ADO.NET, elle-même une évolution des premiers services ADO
(ADO signifie ActiveX Data Object). Cette nouvelle couche apportait son lot de nouveautés, parmi
lesquelles l’interface IDbConnection, qui permettait de considérer une connexion générique à une