Blog ENI : Toute la veille numérique !
Jusqu'à ce soir ! : -25€ dès 75€ sur les livres en ligne, vidéos... code FUSEE25. J'en profite !
Accès illimité 24h/24 à tous nos livres & vidéos ! 
Découvrez la Bibliothèque Numérique ENI. Cliquez ici
  1. Livres et vidéos
  2. Entity Framework Core
  3. .NET et l’accès aux données
Extrait - Entity Framework Core Maîtrisez la solution de Mappage Objet-Relationnel de Microsoft
Extraits du livre
Entity Framework Core Maîtrisez la solution de Mappage Objet-Relationnel de Microsoft Revenir à la page d'achat du livre

.NET et l’accès aux données

ADO.NET

Depuis sa toute première version, la bibliothèque de classes fournie par la plateforme .NET dispose d’une brique dédiée à la récupération d’informations enregistrées en base de données, ainsi qu’à leur manipulation et à la persistance des modifications qui leur sont apportées. Cet ensemble d’API a pour nom ADO.NET, en référence à l’API ADO (ActiveX Data Objects) utilisée en conjonction avec les technologies antérieures à la plateforme .NET.

Bien que leurs noms soient similaires, des différences fondamentales séparent ces deux technologies. Une des plus importantes se trouve dans la manière dont sont définies les interactions entre le cœur de la librairie et les sources de données extérieures. ADO utilise un mécanisme basé sur COM (Component Object Model) pour interagir avec des drivers natifs, installés sur la machine. Ceci implique que l’utilisation d’une source de données nécessite, au mieux, d’installer un pilote natif, et dans un cas moins glorieux, de l’écrire avec un langage comme C ou C++, puis de l’installer. Les liens entre les sources de données et le cœur d’ADO.NET sont logés dans des librairies écrites en code managé et respectant un contrat prédéfini : les fournisseurs de données. Ce point permet à cette brique logicielle d’être facilement étendue pour supporter de nouvelles sources de données.

Chaque fournisseur de données encapsule les différents éléments essentiels pour les interactions avec une source de données au sein de quelques classes centrales. Pour le fournisseur de données SQL Server intégré...

Mappage objet-relationnel

Les faiblesses du modèle traditionnel de manipulation des données, tel qu’il est implémenté dans de nombreuses technologies (.NET, Java, PHP, etc.), ont poussé de nombreux acteurs du monde du développement logiciel à l’élaboration d’un modèle différent, permettant de manipuler les données en suivant le paradigme de la programmation orientée objet (POO) : le mappage objet-relationnel (ORM ou Object/Relational Mapping).

Cette technique vise à transformer de manière automatique des données issues de sources de données externes, comme des bases de données, en objets utilisables dans le langage cible. La manipulation de ces objets permet également de générer et d’exécuter de manière automatique les instructions nécessaires à la répercussion des modifications dans la source de données. Ainsi, les actions associées à la source de données sont entièrement encapsulées derrière une façade objet, simplifiant les traitements, et par là même, réduisant les coûts associés au développement d’une solution logicielle couplée à une ou plusieurs sources de données.

Avec l’utilisation d’une solution de mappage objet-relationnel, l’ensemble...

LINQ to SQL

Consciente des défauts d’ADO.NET et de l’évolution en cours au niveau des techniques d’accès aux données, l’équipe en charge du langage C# a travaillé sur la simplification de l’accès aux données par l’intégration du requêtage au langage C#. Le résultat de cet effort est une librairie de mappage objet-relationnel dévoilée à la fin de l’année 2005 sous le nom de DLINQ, et renommée par la suite en LINQ to SQL, qui fait partie intégrante du framework .NET depuis sa version 3.5.

LINQ to SQL tire son nom de la brique logicielle qui lui est associée pour l’écriture de requêtes de sélection : LINQ (Language-INtegrated Query). Cette librairie permet de manipuler des données par l’utilisation d’éléments intégrés au langage C# (ou VB.NET), et de manière complètement agnostique : la source des données pourrait aussi bien être un fichier CSV (Comma-Separated Values) ou XML, une collection .NET en mémoire ou une base de données.

LINQ to SQL se positionne justement sur ce dernier créneau en fournissant une infrastructure logicielle qui permet de retranscrire les instructions LINQ en instructions SQL compréhensibles par une base de données SQL Server (uniquement).

Nous reviendrons plus en détail sur LINQ et son fonctionnement au chapitre Des objets au SQL.

Les outils associés à LINQ to SQL (SQLMetal et le designer intégré à Visual Studio) facilitent la génération d’un fichier au format XML qui décrit les relations entre les objets .NET et les éléments de la source de données. À partir du contenu de ce fichier, ils peuvent ensuite passer à l’étape de génération du code C#/VB.NET exploitable au sein de l’application. Ainsi, pour un modèle simple, dans lequel une seule table de la base de données Northwind de Microsoft est intégrée, au moins deux fichiers sont créés : un fichier de description (extension .dbml) et un fichier de code contenant deux classes. Avec l’utilisation du designer de Visual Studio, deux fichiers supplémentaires liés à l’aspect...

Entity Framework

En parallèle du développement de LINQ to SQL, l’équipe responsable des technologies d’accès aux données avec .NET travaillait également à la mise au point d’un outil de mappage objet-relationnel : Entity Framework. Celui-ci a également été introduit avec le framework .NET 3.5, de sorte que les deux technologies de l’éditeur étaient placées en position de concurrence. Entity Framework, avec notamment sa capacité à agir pour le compte de plusieurs fournisseurs de données là ou LINQ to SQL n’est compatible qu’avec SQL Server, a été préféré par les développeurs, et ce malgré les défauts de jeunesse que l’on pouvait lui trouver dans la première version de cette librairie. Par la suite, les efforts de Microsoft se sont concentrés sur Entity Framework, ce qui lui a permis d’évoluer jusqu’à aujourd’hui.

Au fil des versions, le panel de fonctionnalités proposées par cet outil s’est étoffé. Ainsi ont été ajoutés (liste non exhaustive) :

  • La personnalisation du code C# généré par l’utilisation de templates T4.

  • Le lazy loading, ou chargement paresseux, qui permet de naviguer dans un graphe d’entités en générant les requêtes SQL à la demande.

  • L’approche Model First, qui s’ajoute à l’approche Database First présente depuis la première version d’Entity Framework. Model First offre la possibilité de générer la base de données à partir du modèle, plutôt que l’inverse.

  • L’approche Code First, qui permet aux développeurs d’écrire leur propre modèle avec C# ou VB.NET pour le connecter à une base de données existante ou créée à la volée par Entity Framework.

  • Les migrations, qui assouplissent l’utilisation de Code First par la mise à jour incrémentale de la structure de base de données en fonction du modèle codé.

  • Les conventions personnalisées pour Code First.

  • Le support de l’injection de dépendances, pour offrir des possibilités de découplage...

D’Entity Framework 7 à Entity Framework Core

Initialement révélée au monde sous le nom d’Entity Framework 7, cette version de l’outil de mappage objet-relationnel est conçue sur des fondations bien différentes de la version précédente. Elle répond à des besoins nouveaux, dans un monde nouveau fait de mobilité, d’ouverture et de performance.

1. Genèse

Parmi les objectifs de cette nouvelle version, on trouve notamment le souhait de cibler des sources de données non relationnelles (bases de données NoSQL, par exemple), mais aussi de cibler des plateformes logicielles plus nombreuses : applications Windows Store (Desktop + Mobile), applications .NET Core sur Windows, mais aussi sur Linux et Mac OS X.

Les challenges à surmonter pour faire évoluer Entity Framework 6 vers l’objectif fixé étaient principalement liés à l’historique de la librairie. Elle a été conçue pour être intégrée à un framework .NET monolithique, et sa structure a par conséquent ce même défaut. En interne, elle fait également un usage intensif d’API et de patrons de conception vieillissants, ce qui complique la maintenance et diminue l’évolutivité. Enfin, certains des concepts que cette librairie utilise sont étroitement liés...