Considérations sur la migration (Entity Framework)

ADO.NET Entity Framework présente plusieurs avantages pour une application existante. La possibilité d'utiliser un modèle conceptuel pour séparer des structures de données utilisées par l'application du schéma de la source de données constitue l'un de ces avantages les plus importants. Cela vous permet d'apporter aisément des modifications au modèle de stockage ou à la source de données eux-mêmes sans apporter de modifications de compensation à l'application. Pour plus d'informations sur les avantages de l'utilisation d'Entity Framework , consultez Vue d'ensemble d'Entity Framework et Entity Data Model.

Pour tirer parti des avantages d'Entity Framework , vous pouvez effectuer la migration d'une application existante vers Entity Framework . Certaines tâches sont communes à toutes les applications migrées. Ces tâches communes incluent la mise à niveau de l'application pour utiliser le .NET Framework à partir de la version 3.5 Service Pack 1 (SP1), la définition des modèles et du mappage, et la configuration d'Entity Framework. Lorsque vous effectuez la migration d'une application vers Entity Framework , des points supplémentaires sont à prendre en considération. Ces points dépendent du type d'application qui est migrée et des fonctionnalités spécifiques de l'application. Cette rubrique fournit des informations vous permettant de choisir la meilleure approche à utiliser lorsque vous mettez à niveau une application existante.

Considérations générales sur la migration

Les considérations suivantes s'appliquent lorsque vous effectuez la migration d'une application vers Entity Framework  :

• Toute application qui utilise .NET Framework à partir de la version 3.5 SP1 peut être migrée vers Entity Framework, à condition que le fournisseur de données pour la source de données utilisée par l'application prenne en charge Entity Framework.

• Il est possible qu'Entity Framework ne prenne pas en charge toutes les fonctionnalités d'un fournisseur de source de données, même si ce fournisseur prend en charge Entity Framework.

• Pour une application volumineuse ou complexe, vous n'êtes pas obligé de migrer la totalité de l'application vers Entity Framework à la fois. Toutefois, toute partie de l'application qui n'utilise pas Entity Framework doit néanmoins être modifiée lorsque la source de données change.

• La connexion de fournisseur de données utilisée par Entity Framework peut être partagée avec d'autres parties de votre application car Entity Framework utilise des fournisseurs de données ADO.NET pour accéder à la source de données. Par exemple, le fournisseur SqlClient est utilisé par Entity Framework pour accéder à une base de données SQL Server. Pour plus d'informations, voir Fournisseur EntityClient pour Entity Framework.

Tâches de migration communes

Le chemin d'accès pour effectuer la migration d'une application existante vers Entity Framework dépend à la fois du type d'application et de la stratégie d'accès aux données existante. Toutefois, vous devez toujours effectuer les tâches suivantes lorsque vous migrez une application existante vers Entity Framework .

Remarque :
Toutes ces tâches sont effectuées automatiquement lorsque vous utilisez les outils Entity Data Model avec ou version ultérieure.Pour plus d'informations, consultez Procédure : utiliser l'Assistant Entity Data Model (Entity Framework).

1. Mettez à niveau l'application.

   Un projet créé à l'aide d'une version antérieure de Visual Studio et du .NET Framework doit être mis à niveau pour utiliser SP1 et .NET Framework 3.5 SP1 ou version ultérieure.

2. Définissez les modèles et le mappage.

   Les fichiers de modèle et de mappage définissent des entités dans le modèle conceptuel, des structures dans la source de données (telles que des tables, des procédures stockées et des vues), ainsi que le mappage entre les entités et les structures de la source de données. Pour plus d'informations, voir Procédure : définir manuellement les fichiers du modèle et les fichiers de mappage (Entity Framework).

   Les types définis dans le modèle de stockage doivent correspondre aux noms des objets présents dans la source de données. Si l'application existante expose des données en tant qu'objets, vous devez vous assurer que les entités et les propriétés définies dans le modèle conceptuel correspondent aux noms de ces classes de données et propriétés existantes. Pour plus d'informations, voir Procédure : personnaliser des fichiers de modèle et de mappage pour utiliser des objets personnalisés (Entity Framework).

   Remarque :
   Entity Data Model Designer peut être utilisé pour renommer des entités du modèle conceptuel afin qu'elles correspondent à des objets existants.Pour plus d'informations, voir ADO.NET Entity Data Model Designer.

3. Définissez la chaîne de connexion.

   Entity Framework utilise une chaîne de connexion spécialement mise en forme lors de l'exécution de requêtes sur un modèle conceptuel. Cette chaîne de connexion encapsule des informations relatives aux fichiers de modèle et de mappage et à la connexion à la source de données. Pour plus d'informations, consultez Procédure : définir la chaîne de connexion (Entity Framework).

4. Configurez le projet Visual Studio.

   Les références à des assemblys Entity Framework et aux fichiers de modèle et de mappage doivent être ajoutées au projet Visual Studio. Vous pouvez ajouter ces fichiers de mappage au projet pour garantir qu'ils sont déployés avec l'application dans l'emplacement indiqué dans la chaîne de connexion. Pour plus d'informations, consultez Procédure : configurer manuellement un projet Entity Framework.

Considérations relatives aux applications comportant des objets existants

À partir du .NET Framework 4, Entity Framework prend en charge des objets CLR (POCO) « simples », également appelés « objets ignorant la persistance ». Dans la plupart des cas, vos objets existants peuvent fonctionner avec Entity Framework en effectuant des changements mineurs. Pour plus d'informations, consultez Utilisation d'entités POCO (Entity Framework). Vous pouvez également migrer une application vers Entity Framework et utiliser les classes de données générées par les outils Entity Framework. Pour plus d'informations, consultez Procédure : utiliser l'Assistant Entity Data Model (Entity Framework).

Considérations relatives aux applications qui utilisent des fournisseurs ADO.NET

Les fournisseurs ADO.NET, tels que SqlClient, vous permettent d'interroger une source de données pour retourner des données tabulaires. Les données peuvent également être chargées dans un dataset ADO.NET. La liste suivante décrit des considérations relatives à la mise à niveau d'une application qui utilise un fournisseur ADO.NET existant :

• Affichage de données tabulaires à l'aide d'un lecteur de données.
  Vous pouvez envisager d'exécuter une requête Entity SQL à l'aide du fournisseur EntityClient et de passer en revue l'objet EntityDataReader retourné. Procédez de cette manière si votre application affiche des données tabulaires à l'aide d'un lecteur de données et ne requiert pas les fonctionnalités fournies par Entity Framework pour la matérialisation des données dans des objets, le suivi des modifications et l'exécution des mises à jour. Vous pouvez continuer à utiliser le code d'accès aux données existant qui effectuer des mises à jour dans la source de données, mais vous pouvez utiliser la connexion existante accessible à partir de la propriété StoreConnection de l'objet EntityConnection. Pour plus d'informations, consultez Fournisseur EntityClient pour Entity Framework.

• Utilisation de DataSets.
  Entity Framework inclut de nombreuses fonctionnalités fournies par le DataSet, y compris la persistance en mémoire, le suivi des modifications, la liaison de données et la sérialisation des objets en tant que données XML. Pour plus d'informations, voir Utilisation d'objets (Entity Framework).

  Si Entity Framework ne fournissent pas les fonctionnalités du DataSet requises par votre application, vous pouvez quand même tirer parti des avantages des requêtes LINQ en utilisant LINQ to DataSet . Pour plus d'informations, voir LINQ to DataSet.

Considérations relatives aux applications qui lient des données à des contrôles

Le .NET Framework vous permet d'encapsuler des données dans une source de données, telle qu'un DataSet ou un contrôle de source de données ASP.NET, puis lie des éléments d'interface utilisateur à ces contrôles de données. La liste suivante décrit les considérations concernant la liaison de contrôles à des données Entity Framework.

• Liaison de données à des contrôles.
  Lorsque vous interrogez le modèle conceptuel, Entity Framework retourne les données sous forme d'objets qui sont des instances de types d'entités. Ces objets peuvent être liés directement à des contrôles, et cette liaison prend en charge les mises à jour. Cela signifie que les modifications apportées aux données dans un contrôle, telles qu'une ligne dans un objet DataGridView, sont automatiquement enregistrées dans la base de données lorsque la méthode SaveChanges est appelée.

  Si votre application énumère les résultats d'une requête pour afficher des données dans un objet DataGridView ou un autre type de contrôle que prend en charge la liaison de données, vous pouvez modifier votre application pour lier le contrôle au résultat d'un objet ObjectQuery.

  Pour plus d'informations, voir Liaison d'objets à des contrôles (Entity Framework).

• Contrôles de source de données ASP.NET.
  Entity Framework inclut un contrôle de source de données conçu pour simplifier la liaison de données dans les applications Web ASP.NET. Pour plus d'informations, voir Contrôle de source de données Entity Framework.

Autres considérations

Les remarques suivantes peuvent s'appliquer lorsque vous effectuez une migration de types spécifiques d'applications vers Entity Framework.

• Applications qui exposent des services de données.
  Les services Web et les applications basées sur Windows Communication Foundation (WCF) exposent les données d'une source de données sous-jacente en utilisant un format de messagerie de demande/réponse XML. Entity Framework prend en charge la sérialisation d'objets entité en utilisant la sérialisation de contrat de données binaire, XML ou WCF. La sérialisation binaire et la sérialisation WCF prennent tous les deux en charge la sérialisation complète de graphiques d'objets. Pour plus d'informations, voir Génération d'applications multicouches (Entity Framework).

• Applications qui utilisent des données XML.
  La sérialisation des objets vous permet de créer des services des données Entity Framework . Ces services fournissent des données à des applications qui utilisent des données XML, telles que les applications Internet AJAX. Dans ces cas, envisagez d'utiliser les services de données ADO.NET. Ces services de données sont basés sur le modèle EDM (Entity Data Model) et fournissent un accès dynamique aux données d'entité à l'aide d'actions HTTP REST (Representational State Transfer) standard, telles que GET, PUT et POST. Pour plus d'informations, voir ADO.NET Data Services.

  Entity Framework ne prend pas en charge le type de données XML natif. Cela signifie que, lorsqu'une entité est mappée à une table avec une colonne XML, la propriété d'entité équivalente de la colonne XML est une chaîne. Les objets peuvent être déconnectés et sérialisés sous forme de données XML. Pour plus d'informations, voir Sérialisation d'objets (Entity Framework).

  Si votre application nécessite la possibilité d'interroger des données XML, vous pouvez tout de même tirer parti des avantages des requêtes LINQ en utilisant LINQ to XML. Pour plus d'informations, voir LINQ to XML.

• Applications qui gèrent l'état.
  Les applications Web ASP.NET doivent fréquemment gérer l'état d'une page Web ou d'une session utilisateur. Les objets d'une instance de ObjectContext peuvent être stockés dans l'état d'affichage client ou dans l'état de session sur le serveur, et être ensuite récupérés et rattachés à un nouveau contexte de l'objet. Pour plus d'informations, voir Attachement et détachement d'objets (Entity Framework).

Voir aussi

Concepts

Points à prendre en considération pour le déploiement (Entity Framework)
Terminologie Entity Framework