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

Hibernate est un choix lié au monde relationnel offrant un ensemble de fonctionnalités pas toujours
aisées à maîtriser. Précisons tout de même qu’Hibernate est bien plus ancien que Linq, puisque sa
création remonte à 2001. Bien que les interfaces JPA aient été créées pour englober plusieurs
utilitaires de persistance dont Hibernate, ce dernier reste davantage un ORM qu’une solution
intégrée au langage. De manière générale, le rôle des implémentations de JPA reste borné à
effectuer une persistance plus simple lorsque les données sont stockées sous forme relationnelle.
6.3.2 .NET
Bien que Linq y soit récent et que, au contraire de Java, ce langage ne s’enrichisse pas directement
sur la base d’une communauté de contributeurs, .NET et C# en particulier proposent d’autres
alternatives pour réaliser la persistance des données sans passer par toute la panoplie des
commandes ADO.NET. Les autres méthodes que nous allons aborder sont, de manière générale,
destinées à un autre public que celui prévu pour Linq.
6.3.2.1 NHibernate
Comme son nom l’indique, il s’agit là d’une version d’Hibernate adaptée au langage C# (le N est une
abréviation courante en préfixe d’une technologie pour signifier qu’elle s’applique à .NET). Les
informations relatives à NHibernate émanent de [17]. Le cœur d’Hibernate a été porté vers .NET et
son utilisation a été quelque peu adaptée pour mieux répondre aux attentes des développeurs .NET.
Cet outil a été développé par la même équipe que celle en charge de la version Java. De par sa
structure et son mode de fonctionnement, il s’agit encore une fois d’un ORM qui vient se greffer sur
une architecture déjà existante, celle de l’incontournable couche ADO.NET. NHibernate est présenté
comme une solution mature, capable de réaliser la correspondance objet relationnel de manière
transparente pour le développeur. NHibernate répond à une demande particulière : ne pas être
limité par l’ORM en étant sûr que, de toute façon, les données seront sauvées dans une base de
données relationnelle. Il s’agit là d’une optique quelque peu hors des objectifs de Linq qui souhaite
créer une abstraction avec le stockage tout en mettant davantage en avant la facilité de mise en
œuvre. A noter que depuis peu, NHibernate propose un module complémentaire Linq to NHibernate
permettant d’utiliser la syntaxe Linq pour réaliser des requêtes avec NHibernate [18].
6.3.2.2 Entity Framework
Voici une figure connue, les informations à son sujet sont toujours majoritairement issues de [5].
L’Entity Framework, que nous avions brièvement introduit dans la section Linq to Entities, est lui
aussi en soi une alternative à Linq. Il serait mieux de parler de complémentarité entre ces deux outils
que de concurrence, néanmoins il reste possible d’utiliser l’un sans l’autre. L’Entity Framework
permet essentiellement deux choses : choisir la forme des entités à manipuler et automatiser toute
la cuisine interne nécessaire pour pouvoir fournir des entités personnalisées de manière efficace.
Comme nous l’avions vu, cela ajoute également un niveau d’abstraction vis-à-vis de la base de
données, car le code manipulant les entités est bien séparé des manipulations relationnelles. Linq
apporte quant à lui la puissance et la simplicité d’utilisation de son langage de requêtes. L’Entity
Framework a donc pour vocation d’aider à définir la « business logic » de l’application sans entrave
de la part du stockage des données, alors que Linq permet de récupérer des éléments précis plus
aisément. Il est tout à fait envisageable de vouloir garder la main sur le langage de requêtes car, en
effet, celles-ci seront traduites tôt ou tard en Sql. Dans cette optique-là, l’utilisation de l’Entity
Framework se fera sans l’aide de Linq. En résumé, si la difficulté se situe au niveau de l’architecture
du code ou de la jonction entre la logique métier et la couche de persistance des données, Entity