Cadre d'entité - Entity Framework

Entity Framework ( EF ) est un framework de mappage objet-relationnel (ORM) open source pour ADO.NET . Il a été initialement livré en tant que partie intégrante de .NET Framework . À partir de la version 6 d'Entity Framework, il a été fourni séparément du .NET Framework.

Aperçu

Entity Framework est un ensemble de technologies dans ADO.NET qui prend en charge le développement d'applications logicielles orientées données. Les architectes et les développeurs d'applications orientées données ont généralement eu du mal à atteindre deux objectifs très différents. Ils doivent modéliser les entités, les relations et la logique des problèmes métier qu'ils résolvent, et ils doivent également travailler avec les moteurs de données utilisés pour stocker et récupérer les données. Les données peuvent s'étendre sur plusieurs systèmes de stockage, chacun avec ses propres protocoles ; même les applications qui fonctionnent avec un seul système de stockage doivent équilibrer les exigences du système de stockage par rapport aux exigences d'écriture de code d'application efficace et maintenable. Ce problème est généralement appelé " désadaptation d'impédance objet-relationnelle ".

De nombreux outils de mappage objet-relationnel (ORM) (alias « gestionnaires objet-relationnel ») ont été développés pour permettre aux développeurs de travailler avec des données sous la forme d'objets et de propriétés spécifiques au domaine, tels que les clients et les adresses des clients, sans avoir à se soucier eux-mêmes avec les tables et colonnes de base de données sous-jacentes où ces données sont stockées. Avec un ORM, les développeurs peuvent travailler à un niveau d'abstraction plus élevé lorsqu'ils traitent des données, et peuvent créer et maintenir des applications orientées données avec moins de code que dans les applications traditionnelles. Entity Framework est la solution ORM actuellement promue pour une utilisation dans la pile de développement Microsoft.

Histoire

La première version d'Entity Framework (EFv1) était incluse avec .NET Framework 3.5 Service Pack 1 et Visual Studio 2008 Service Pack 1, publié le 11 août 2008 (il y a 13 ans) . Cette version a été largement critiquée, attirant même un « vote de défiance » signé par au moins un millier de développeurs.  ( 2008-08-11 )

La deuxième version d'Entity Framework, nommée Entity Framework 4.0 (EFv4), a été publiée dans le cadre de .NET 4.0 le 12 avril 2010 et a répondu à de nombreuses critiques formulées à l'encontre de la version 1.

Une troisième version d'Entity Framework, la version 4.1, a été publiée le 12 avril 2011, avec la prise en charge de Code First.

Une actualisation de la version 4.1, nommée Entity Framework 4.1 Update 1, a été publiée le 25 juillet 2011. Elle inclut des corrections de bogues et de nouveaux types pris en charge.

La version 4.3.1 est sortie le 29 février 2012. Il y a eu quelques mises à jour, comme la prise en charge de la migration.

La version 5.0.0 a été publiée le 11 août 2012 et est destinée au framework .NET 4.5. De plus, cette version est disponible pour .Net Framework 4, mais sans aucun avantage d'exécution par rapport à la version 4.

La version 6.0 a été publiée le 17 octobre 2013 et est maintenant un projet open source sous licence Apache License v2. Comme ASP.NET MVC , son code source est hébergé sur GitHub à l' aide de Git. Cette version comporte un certain nombre d'améliorations pour la prise en charge du code d'abord .

Microsoft a ensuite décidé de moderniser, de composer et d'apporter .NET multiplateforme à Linux, OSX et ailleurs, ce qui signifie que la prochaine version d'Entity Framework serait une réécriture complète. Le 27 juin 2016, il a été publié sous le nom d'Entity Framework Core 1.0, aux côtés d'ASP.NET Core 1.0 et .NET Core 1.0. Il s'appelait à l'origine Entity Framework 7, mais a été renommé pour souligner qu'il s'agissait d'une réécriture complète plutôt que d'une mise à niveau incrémentielle et qu'il ne remplace pas EF6.

Entity Framework Core 1.0 est sous licence Apache License v2 et est entièrement construit à l'air libre sur GitHub . Bien qu'Entity Framework Core 1.0 partage certaines similitudes conceptuelles avec les versions précédentes d'Entity Framework, il s'agit d'une toute nouvelle base de code conçue pour être plus efficace, puissante, flexible et extensible, fonctionnera sur Windows, Linux et OSX, et prendra en charge une nouvelle gamme de magasins de données relationnelles et NOSQL.

Entity Framework Core 2.0 est sorti le 14 août 2017 (il y a 4 ans) avec Visual Studio 2017 15.3 et ASP.NET Core 2.0  ( 2017-08-14 )

Entity Framework Core 3.0 est sorti le 23 septembre 2019 (il y a 2 ans) avec Visual Studio 2019 16.3 et ASP.NET Core 3.0,  ( 2019-09-23 )

Entity Framework Core 3.1 (EF Core 3.1) a été officiellement publié pour une utilisation en production le 3 décembre 2019 (il y a 22 mois) et sera la version préférée prise en charge à long terme jusqu'au 3 décembre 2022 au moins.  ( 2019-12-03 )

Le plus récent Entity Framework Core 5.0.2 (EF Core 5) a été publié pour une utilisation en production le 12 janvier 2021 (il y a 9 mois) .  ( 2021-01-12 )

Architecture

Pile ADO.NET Entity Framework.

L'architecture d'ADO.NET Entity Framework, de bas en haut, se compose des éléments suivants :

• Fournisseurs spécifiques à la source de données , qui font abstraction des interfaces ADO.NET pour se connecter à la base de données lors de la programmation par rapport au schéma conceptuel.
• Map provider , un fournisseur spécifique à la base de données qui traduit l'arborescence de commandes Entity SQL en une requête dans la version SQL native de la base de données. Il inclut le pont spécifique au magasin , qui est le composant responsable de la traduction de l'arborescence de commandes générique en une arborescence de commandes spécifique au magasin.
• Analyseur EDM et mappage de vues , qui prend la spécification SDL du modèle de données et la façon dont il est mappé sur le modèle relationnel sous-jacent et permet la programmation par rapport au modèle conceptuel. A partir du schéma relationnel, il crée des vues des données correspondant au modèle conceptuel. Il agrège les informations de plusieurs tables afin de les agréger en une entité et divise une mise à jour d'une entité en plusieurs mises à jour de la ou des tables ayant contribué à cette entité.
• Pipeline de requête et de mise à jour , traite les requêtes, filtre et met à jour les requêtes pour les convertir en arborescences de commandes canoniques qui sont ensuite converties en requêtes spécifiques au magasin par le fournisseur de carte.
• Services de métadonnées , qui gèrent toutes les métadonnées liées aux entités, aux relations et aux mappages.
• Transactions , à intégrer aux capacités transactionnelles du magasin sous-jacent. Si le magasin sous-jacent ne prend pas en charge les transactions, sa prise en charge doit être implémentée à cette couche.
• API de couche conceptuelle , l'environnement d'exécution qui expose le modèle de programmation pour le codage par rapport au schéma conceptuel. Il suit le modèle ADO.NET consistant à utiliser des objets Connection pour faire référence au fournisseur de carte, à utiliser des objets Command pour envoyer la requête et à renvoyer des EntityResultSets ou des EntitySets contenant le résultat.
• Composants déconnectés , qui mettent en cache localement des ensembles de données et des ensembles d'entités pour l'utilisation d'ADO.NET Entity Framework dans un environnement occasionnellement connecté.
• Base de données intégrée : ADO.NET Entity Framework comprend une base de données intégrée légère pour la mise en cache et l'interrogation de données relationnelles côté client.
• Des outils de conception , tels que Mapping Designer, sont également inclus avec ADO.NET Entity Framework, ce qui simplifie le mappage d'un schéma conceptuel au schéma relationnel et de spécification des propriétés d'un type d'entité correspondant à quelle table de la base de données.
• Couche de programmation , qui expose l'EDM en tant que constructions de programmation pouvant être utilisées par les langages de programmation.
  • Les services d'objets génèrent automatiquement du code pour les classes CLR qui exposent les mêmes propriétés qu'une entité, permettant ainsi l'instanciation d'entités en tant qu'objets .NET.
  • Services Web , qui exposent des entités en tant que services Web.
• Services de haut niveau , tels que les services de reporting qui fonctionnent sur des entités plutôt que sur des données relationnelles.

Modèle de données d'entité

L' Entity Data Model ( EDM ) spécifie le modèle conceptuel (CSDL) des données, en utilisant une technique de modélisation qui est elle-même appelée Entity Data Model, une version étendue du modèle entité-relation . Le modèle de données décrit principalement les entités et les associations auxquelles elles participent. Le schéma EDM est exprimé dans le langage de définition de schéma (SDL), qui est une application de XML (langage de balisage étendu). De plus, le mappage (MSL) des éléments du schéma conceptuel (CSDL) vers le schéma de stockage (SSDL) doit également être spécifié. La spécification de mappage est également exprimée en XML.

Visual Studio fournit également le concepteur d'entités pour la création visuelle de l'EDM et de la spécification de mappage. La sortie de l'outil est le fichier XML (*.edmx) spécifiant le schéma et le mappage. Le fichier Edmx contient des artefacts de métadonnées EF (contenu CSDL/MSL/SSDL). Ces trois fichiers (csdl, msl, ssdl) peuvent également être créés ou édités à la main.

Cartographie

Entity Data Model Wizard dans Visual Studio génère initialement un mappage un-à-un (1:1) entre le schéma de base de données et le schéma conceptuel dans la plupart des cas. Dans le schéma relationnel, les éléments sont composés des tables, les clés primaire et étrangère collant les tables liées ensemble. En revanche, les types d'entité définissent le schéma conceptuel des données.

Les types d'entités sont une agrégation de plusieurs champs typés - chaque champ correspond à une certaine colonne de la base de données - et peuvent contenir des informations provenant de plusieurs tables physiques. Les types d'entités peuvent être liés les uns aux autres, indépendamment des relations dans le schéma physique. Les entités liées sont également exposées de la même manière - via un champ dont le nom indique la relation à laquelle elles participent et à laquelle elles accèdent qui, au lieu de récupérer la valeur d'une colonne de la base de données, parcourt la relation et renvoie l'entité (ou une collection d'entités) avec auquel il est lié.

Les types d'entités forment la classe d'objets auxquels les entités se conforment, les entités étant des instances des types d'entités. Les entités représentent des objets individuels qui font partie du problème résolu par l'application et sont indexés par une clé. Par exemple, en convertissant le schéma physique décrit ci-dessus, nous aurons deux types d'entités :

• CustomerEntity , qui contient le nom du client de la table Customers et l'adresse du client de la table Contacts .
• OrderEntity , qui encapsule les commandes d'un certain client, les récupérant à partir de la table Orders .

Le schéma logique et son mappage avec le schéma physique sont représentés sous la forme d'un modèle de données d'entité (EDM), spécifié sous la forme d'un fichier XML. ADO.NET Entity Framework utilise l'EDM pour effectuer réellement le mappage permettant à l'application de fonctionner avec les entités, tout en faisant abstraction en interne de l'utilisation des constructions ADO.NET telles que DataSet et RecordSet . ADO.NET Entity Framework effectue les jointures nécessaires pour avoir des informations de référence d'entité à partir de plusieurs tables ou lorsqu'une relation est traversée. Lorsqu'une entité est mise à jour, elle retrace la table d'où proviennent les informations et émet des instructions de mise à jour SQL pour mettre à jour les tables dans lesquelles certaines données ont été mises à jour. ADO.NET Entity Framework utilise eSQL, un dérivé de SQL, pour effectuer des requêtes, des opérations de théorie des ensembles et des mises à jour sur les entités et leurs relations. Les requêtes dans eSQL, si nécessaire, sont ensuite traduites dans la version SQL native de la base de données sous-jacente.

Les types d'entités et les ensembles d'entités forment simplement le schéma EDM logique et peuvent être exposés comme n'importe quoi. ADO.NET Entity Framework inclut le service d'objets qui présente ces entités en tant qu'objets avec les éléments et les relations exposés en tant que propriétés. Ainsi, les objets Entity sont simplement frontaux pour les instances des types d'entité EDM, ce qui permet aux langages orientés objet d'y accéder et de les utiliser. De même, d'autres frontaux peuvent être créés, qui exposent les entités via des services Web (par exemple, WCF Data Services ) ou XML qui est utilisé lorsque les entités sont sérialisées pour le stockage persistant ou le transfert sans fil.

Entités

Les entités** sont des instances de EntityType s ; ils représentent les instances individuelles des objets (tels que client , commandes ) auxquels les informations se rapportent. L'identité d'une entité est définie par le type d'entité dont elle est une instance ; en ce sens, un type d'entité définit la classe à laquelle appartient une entité et définit également les propriétés qu'une entité aura. Les propriétés décrivent certains aspects de l'entité en lui donnant un nom et un type. Les propriétés d'un type d'entité dans ADO.NET Entity Framework sont entièrement typées et sont entièrement compatibles avec le système de types utilisé dans un système de SGBD, ainsi qu'avec le Common Type System du .NET Framework. Une propriété peut être SimpleType ou ComplexType , et peut être à plusieurs valeurs aussi bien. Tous les EntityType appartiennent à un espace de noms et ont une propriété EntityKey qui identifie de manière unique chaque instance du type d'entité. Les différents types de propriétés se distinguent comme suit :

• SimpleType , correspond aux types de données primitifs tels que les entiers , les caractères et les nombres à virgule flottante .
• ComplexType , est un agrégat de plusieurs propriétés de type SimpleType ou ComplexType . Contrairement aux EntityType s, cependant, les ComplexTypes ne peuvent pas avoir de EntityKey . Dans Entity Framework v1, les ComplexTypes ne peuvent pas être hérités.

Toutes les instances d'entité sont hébergées dans des EntityContainers, qui sont des conteneurs par projet pour les entités. Chaque projet a un ou plusieurs EntityContainers nommés, qui peuvent référencer des entités dans plusieurs espaces de noms et types d'entités. Plusieurs instances d'un même type d'entité peuvent être stockées dans des collections appelées EntitySets. Un type d'entité peut avoir plusieurs EntitySets.

Types primitifs EDM (types simples) :

Des relations

Deux types d'entités peuvent être liés, soit par une relation d' association , soit par une relation de confinement . Par exemple, une expédition facturée à un client est une association alors qu'une commande contenant les détails de la commande est une relation de confinement. Une relation de confinement peut également être utilisée pour modéliser l'héritage entre entités. La relation entre deux types d'entité est spécifiée par un Type de relation , dont les instances, appelées Relations , relient les instances d'entité. Dans les versions futures, d'autres types de types de relations, tels que Composition , ou Identification , pourront être introduits.

Les types de relations sont caractérisés par leur degré (arité) ou le nombre de types d'entités qu'ils relient et leur multiplicité. Cependant, dans la version initiale d'ADO.NET Entity Framework, les relations sont limitées à une relation bidirectionnelle binaire (de degré 2). La multiplicité définit le nombre d'instances d'entités pouvant être liées entre elles. Basées sur la multiplicité, les relations peuvent être soit un à un, un à plusieurs ou plusieurs à plusieurs. Les relations entre les entités sont nommées ; le nom est appelé un Rôle. Il définit le but de la relation.

Un type de relation peut également avoir une opération ou une action qui lui est associée, ce qui permet d'effectuer une action sur une entité dans le cas où une action est effectuée sur une entité liée. Une relation peut être spécifiée pour effectuer une action lorsqu'une opération est effectuée sur une entité liée. Par exemple, lors de la suppression d'une entité faisant partie d'une relation ( opération OnDelete ), les actions pouvant être entreprises sont :

• Cascade , qui demande de supprimer l'instance de relation et toutes les instances d'entité associées.
• Aucun .

Pour les relations d'association, qui peuvent avoir une sémantique différente aux deux extrémités, différentes actions peuvent être spécifiées pour chaque extrémité.

Langage de définition de schéma

ADO.NET Entity Framework utilise un langage de définition de données basé sur XML appelé Schema Definition Language (SDL) pour définir le schéma EDM. Le SDL définit les SimpleTypes similaires aux types primitifs CTS , notamment String , Int32 , Double , Decimal , Guid et DateTime , entre autres. Une énumération , qui définit une carte de valeurs et de noms primitifs, est également considérée comme un type simple. Les énumérations ne sont prises en charge qu'à partir de la version 5.0 du framework. Les ComplexTypes sont créés à partir d'une agrégation d'autres types. Une collection de propriétés de ces types définit un type d'entité. Cette définition peut être écrite dans la grammaire EBNF comme :

  EntityType ::= 
    ENTITYTYPE entityTypeName [BASE entityTypeName]
      [ABSTRACT true|false] KEY propertyName [, propertyName]*
      {(propertyName PropertyType [PropertyFacet]*) +}

  PropertyType ::= (
        (PrimitiveType [PrimitiveTypeFacets]*)
        | (complexTypeName)
        | RowType
    
      PropertyFacet ::= (
        [NULLABLE true | false]
        | [DEFAULT defaultVal] 
        | [MULTIPLICITY [1|*]]
      )
    
      PropertyTypeFacet ::= 
        MAXLENGTH | PRECISION | SCALE 
        | UNICODE | FIXEDLENGTH | COLLATION
        | DATETIMEKIND | PRESERVESECONDS
    
      PrimitiveType ::= 
        BINARY | STRING | BOOLEAN
        | SINGLE | DOUBLE | DECIMAL | GUID
        | BYTE | SBYTE | INT16 | INT32 | INT64
        | DATETIME | DATETIMEOFFSET | TIME
  )

Les facettes sont utilisées pour décrire les métadonnées d'une propriété, par exemple si elle est nullable ou a une valeur par défaut, ainsi que la cardinalité de la propriété, c'est-à-dire si la propriété est à valeur unique ou à valeurs multiples. Une multiplicité de « 1 » désigne une propriété à valeur unique ; un « * » signifie qu'il s'agit d'une propriété à plusieurs valeurs. À titre d'exemple, une entité peut être désignée en SDL par :

<ComplexType Name="Addr">
    <Property Name="Street" Type="String" Nullable="false" />
    <Property Name="City" Type="String" Nullable="false" />
    <Property Name="Country" Type="String" Nullable="false" />
    <Property Name="PostalCode" Type="Int32" />
</ComplexType>
<EntityType Name="Customer">
    <Key>
        <PropertyRef Name="Email" />
    </Key>
    <Property Name="Name" Type="String" />
    <Property Name="Email" Type="String" Nullable="false" />
    <Property Name="Address" Type="Addr" />
</EntityType>

Un type de relation est défini comme spécifiant les points d'extrémité et leurs multiplicités. Par exemple, une relation un-à-plusieurs entre le client et les commandes peut être définie comme

<Association Name="CustomerAndOrders">
    <End Type="Customer" Multiplicity="1" />
    <End Type="Orders" Multiplicity="*">
        <OnDelete Action="Cascade" />
    </End>
</Association>

Interrogation des données

SQL d'entité

ADO.NET Entity Framework utilise une variante du langage de requête structurée , nommée Entity SQL , qui vise à écrire des requêtes déclaratives et des mises à jour sur les entités et les relations d'entités - au niveau conceptuel. Il diffère de SQL en ce qu'il n'a pas de constructions explicites pour les jointures, car l'EDM est conçu pour faire abstraction des données de partitionnement entre les tables.

L'interrogation par rapport au modèle conceptuel est facilitée par les classes EntityClient , qui accepte une requête Entity SQL. Le pipeline de requête analyse la requête Entity SQL dans une arborescence de commandes, en séparant la requête sur plusieurs tables, qui est remise au fournisseur EntityClient. Comme les fournisseurs de données ADO.NET, un fournisseur EntityClient est également initialisé à l'aide d'un objet Connection qui, en plus des paramètres habituels du magasin de données et des informations d'authentification, requiert le schéma SDL et les informations de mappage. Le fournisseur EntityClient transforme à son tour l'arborescence de commandes Entity SQL en une requête SQL dans la version native de la base de données. L'exécution de la requête renvoie alors un Entity SQL ResultSet, qui n'est pas limité à une structure tabulaire, contrairement aux ResultSets ADO.NET.

Entity SQL améliore SQL en ajoutant une prise en charge intrinsèque pour :

• Types , car les entités ADO.NET sont entièrement typées.
• EntitySets , qui sont traités comme des collections d'entités.
• Composability , qui supprime les restrictions sur l'endroit où les sous-requêtes peuvent être utilisées.

Fonctions canoniques Entity SQL

Les fonctions canoniques sont prises en charge par tous les fournisseurs de données conformes à Entity Framework. Ils peuvent être utilisés dans une requête Entity SQL. En outre, la plupart des méthodes d'extension dans LINQ to Entities sont traduites en fonctions canoniques. Ils sont indépendants de toute base de données spécifique. Lorsque le fournisseur de données ADO.NET reçoit une fonction, il la convertit en l'instruction SQL souhaitée.

Mais tous les SGBD n'ont pas des fonctionnalités équivalentes et un ensemble de fonctions intégrées standard. Il existe également des différences dans la précision des calculs. Par conséquent, toutes les fonctions canoniques ne sont pas prises en charge pour toutes les bases de données, et toutes les fonctions canoniques ne renvoient pas les mêmes résultats.

LINQ aux entités

Le fournisseur LINQ to Entities permet à LINQ d'être utilisé pour interroger diverses sources de données SGBDR . Plusieurs fournisseurs spécifiques au serveur de base de données avec prise en charge d'Entity Framework sont disponibles.

SQL natif

Dans Entity Framework v4, les nouvelles méthodes ExecuteStoreQuery() et ExecuteStoreCommand() ont été ajoutées à la classe ObjectContext.

Visualiseurs

Visual Studio a une fonctionnalité appelée Visualizer. Une requête LINQ écrite dans Visual Studio peut être visualisée en tant que SQL natif à l'aide d'un visualiseur pendant la session de débogage. Un visualiseur pour LINQ to Entities (Object Query) ciblant tous les SGBDR est disponible dans la "VisualStudioGallery".

Profileur de structure d'entité

Entity Framework Profiler est un outil de mappage objet-relationnel (ORM) qui résoudra les problèmes de performances dans une application ASP.NET à l' aide d'Entity Framework. Il recherche les inefficacités courantes des requêtes de base de données comme le problème SELECT N + 1.

Voir également

• Liste des logiciels de cartographie objet-relationnelle
• LINQ à SQL
• API de persistance .NET (NPA)

Les références

Bibliographie

Liens externes

• L'ADO.NET Entity Framework (au Data Developer Center)
• Le code source de l'Entity Framework version 6 hébergé sur GitHub
• EntityFramework sur GitHub