Les premiers pas

En tant qu'ORM, Entity Framework est un cadre d'application d'accès aux données fourni par Microsoft permettant d'établir une relation entre les objets et la structure de données dans l'application. Il est construit sur ADO.NET traditionnel et agit comme un enveloppe sur ADO.NET et constitue une amélioration par rapport à ADO.NET fournissant un accès aux données de manière plus automatisée, réduisant ainsi les efforts d'un développeur pour lutter contre les connexions, les lecteurs de données ou les ensembles de données. C'est une abstraction sur tous ces éléments et est plus puissant par rapport aux offres qu'il propose. Un développeur peut avoir plus de contrôle sur les données dont il a besoin, sous quelle forme et en quelle quantité. Entity Framework fournit une API fiable, afin que les développeurs de logiciels puissent se concentrer sur la résolution de leurs problèmes commerciaux, sans se soucier de résoudre les problèmes de persistance des données. Un développeur n'ayant aucune expérience en développement de base de données ou n'ayant pas une connaissance très approfondie des bases de données peut tirer parti des capacités d'Entity Framework et de LINQ pour écrire une requête optimisée afin d'effectuer des opérations de base de données. Comme il supprime un grand nombre d'affectations d'association d'informations répétitives, Entity Framework peut améliorer l'efficacité d'un développeur. Il permet également d'assurer la cohérence des tâches qu'il effectue, au lieu d'avoir différents collègues d'une même équipe ayant leurs propres méthodes d'accès aux données. Entity Framework, bien sûr, a sa propre courbe d'apprentissage, en particulier si vous avez besoin de le comprendre plus en profondeur pour tirer parti de ses fonctionnalités avancées, mais cette courbe d'apprentissage est rapide car la technologie est très intéressante. L'exécution des requêtes SQL ou DB serait gérée par Entity Framework en arrière-plan et il s'occuperait de toutes les transactions et des problèmes de concurrence pouvant survenir.

Le modèle relationnel et le modèle objet

La cartographie objet-relationnel est une stratégie vous donnant la possibilité d'interroger et de contrôler/manipuler des données à partir d'une base de données en utilisant un paradigme orienté objet. Par conséquent, dans votre code, vous pouvez découper des objets au lieu de composer directement des requêtes SQL. Les modèles relationnels et les modèles objet ne fonctionnent pas très bien ensemble. Une base de données relationnelle choisit le format tabulaire pour représenter les données et les langages orienté objet les représentent sous la forme d'un graphique interconnecté d'objets. C'est la bibliothèque ORM implémentant la technique de cartographie objet-relationnel, comme Entity Framework, qui s'en charge. Dans la plupart des scénarios de base, ces objets sont directement cartographiés aux tables de la base de données. Mais dans des applications plus grandes et des scénarios complexes, cette technique orienté objet permet d'implémenter des fonctionnalités orienté objet telles que l'héritage. Une classe Personne de base et une classe Employer héritant de la personne peuvent être cartographiées aux données entreposées dans la même table de la base de données. Ou une meilleure granularité sans héritage, une table dans une base de données peut se traduire par un ensemble distinct de classes dans un modèle orienté objet. Les entités avec lesquelles l'ORM travaille sont différentes d'une cartographie 1 sur 1 vers des tables.

L'historique d'Entity Framework

La plupart des programmes que nous créons utilisent des informations et nous devons les entreposer dans la base de données, et à certains moments récupérer les mêmes informations pour les montrer aux utilisateurs finaux, leur permettre d'accéder, de modifier ou d'ajouter de nouvelles données ou informations. Ces tâches sont généralement secondaires par rapport aux problèmes que nous essayons de résoudre lors de la création de programmes, mais pendant assez longtemps, nous avons investi des efforts étranges dans la composition de code juste pour obtenir des informations dans notre magasin de données ou mieux appelé une base de données. Au cours de ces années, Microsoft a également connu diverses mises en avant de l'obtention d'informations via des API. ActiveX Data Objects, ou ADO, a existé pendant un certain temps et a finalement évolué pour devenir ADO.NET, mais ADO ou ADO.NET nous obligeait toujours à être exceptionnellement associés à la création de connexions et de commandes pour convertir les résultats des requêtes de base de données en entités compréhensibles, en tenant compte de la création de nos bases de données, et ce n'est que la pointe de l'iceberg. En 2008, Microsoft a déplacé sa stratégie d'accès aux données vers un cartographieur objet-relationnel ayant une implication automatisée avec les bases de données relationnelles et permettant de traduire les objets vers et depuis les données brutes. Cela ne nécessite pas qu'un développeur ait une connaissance approfondie de la base de données ou de son schéma. Cette innovation a été baptisée Entity Framework et est devenue l'API d'accès aux données principale de Microsoft. Cette API a évolué au fil des ans, puis la version la plus stable, à savoir EF 6, est sortie, avec plus de 48 000 000 téléchargements. La version actuelle est la 6.2.0, qui compte 3 700 700 téléchargements et plus à ce jour. Jetons un coup d'oeil sur l'histoire d'Entity Framework.

• La première version d'Entity Framework est sortie avec .Net Framework 3.5 SP1 avec VS 2008 SP1 le 11 août 2008. Cette version n'a pas du tout été acceptée par les développeurs.
• La deuxième version, EF4 (Entity Framework 4.0), faisait partie de .Net Framework 4.0, sortie le 12 avril 2010, et ayant considérablement évolué par rapport à sa première version.
• La troisième version, EF 4.1, a été publiée le 12 avril 2011, avec l'approche Code First. Une nouvelle mise à jour de la même version a été publiée le 25 juillet 2011, prenant en charge de nouveaux types et corrigeant des bogues antérieurs. Cette version a été largement acceptée.
• Une version mise à jour EF 4.3.1 est sortie le 29 février 2012, prenant également en charge les migrations.
• Le 11 août 2010, la version 5.0.0 a été publiée, ciblant .Net Framework 4.5, qui a également été mise à disposition pour .Net Framework 4.0.
• Le 17 octobre 2013, Microsoft a publié la version 6.0 d'Entity Framework, ayant été rendue open source et dont le code source a été mis à disposition sur Git. Elle présente une amélioration drastique par rapport à l'approche Code first de l'accès aux données.
• Conformément à la vision de Microsoft de moderniser les composantes et de les rendre plus multiplateformes pour fonctionner sur Linux ou toute autre plate-forme comme Mac OS X, ils ont publié Entity Framework Core 1.0 le 27 juin 2016 avec Asp.Net Core 1.0. Microsoft n'a pas mis à niveau la version antérieure d'EF, mais a plutôt lancé une nouvelle version, car il s'agissait peut-être d'une réécriture complète pour prendre en charge les composantes Core.
• Le 14 août 2017, avec Visual Studio 2017, EF Core 2.0 a été publié avec ASP.NET Core 2.0.
• L'EF Core 7 est sorti le 8 novembre 2022, ajoutant des fonctionnalités telles que les colonnes JSON et les mises à jour en masse.
• L'Entity Framework Core 8.0 (EF Core 8) est sorti le 14 novembre 2023, ajoutant des fonctionnalités telles que les objets Value utilisant des types complexes et des collections primitives.

Les avantages d'Entity Framework pour une Application

Bien qu'Entity Framework offre de nombreuses possibilités, dans des scénarios réels, dans quelle mesure peut-il être intégré dans des applications ? Prenons un scénario en temps réel. Supposons qu'une application Web ait été initialement écrite à l'aide d'ASP.NET traditionnel avec une approche ADO.NET d'accès aux données. Imaginez le type de problèmes auxquels elle peut être confrontée. Elle a un temps de développement pour maintenir les connexions et les commandes SQL, elle ne peut pas s'étendre à une nouvelle base de données en dehors de SQL, il y aurait un effort de développement supplémentaire pour transformer les données brutes en modèle ou entités souhaités, un développeur doit avoir une bonne connaissance de la base de données ainsi que connaître le schéma de la base de données, les objets de la base de données sont directement exposés dans le code, les opérations d'accès aux données seraient très étroitement couplées et spécifiques à la base de données utilisée, c'est-à-dire SQL. Désormais, en utilisant Entity Framework, tout cela pourrait être facilement réalisé dans une application, qu'il s'agisse d'une application de niveau entreprise ou d'une application de base. Par exemple, une entreprise avait un produit de niveau entreprise pour convertir des PDF en livres prenant en charge tous les formats de document et offrant également des fonctionnalités d'édition. Le produit a été écrit en ASP.NET avec ADO.NET. Leur exigence était de passer à l'échelle supérieure, ils ont donc choisi Entity Framework car il offrait également au logiciel la flexibilité d'écrire des microservices avec des bases de données indépendantes pour les services ayant leurs propres contextes. La base de données variait de SQL à MySQL à Oracle ou les trois bases de données pouvaient être utilisées en même temps avec Entity Framework, ce qui permettait d'avoir des contextes séparés et aucun changement de code du tout. Ces offres rendent Entity Framework plus fort.

L'Entity Framework pourrait donc également être utilisé dans les scénarios où, dans une application typique, l'interface utilisateur et le code d'accès aux données sont étroitement liés. C'est une perspective et pas le seul endroit où l'on peut utiliser Entity Framework. Il résout tous les problèmes limitant l'application ASP.NET typique avec l'application ADO.NET pour passer à l'échelle supérieure. L'Entity Framework facilite la manière de savoir quel objet de domaine fonctionnera dans un modèle. Cela pourrait être défini par un contexte séparé. Dans Entity Framework, cela s'appelle DbContext. Une application peut avoir plus d'un DbContext à utiliser indépendamment dans le grand logiciel selon les besoins. Il gère les objets, l'état et la relation des entités ainsi que la persistance des données. DbContext assume également la responsabilité de l'exécution de LINQ et du suivi des modifications en mémoire. Cela s'avère également être une abstraction d'Entity Framework à connaître directement par une application, ce qui n'est bien sûr pas du tout nécessaire.

L'architecture d'Entity Framework

L'image suivante montre l'architecture d'Entity Framework sur ADO.NET :