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 facilement des modifications à venir 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 liés à 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. Quand 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 quand 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, consultez la page Fournisseur EntityClient pour Entity Framework.

Tâches de migration communes

Le chemin 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 quand vous migrez une application existante vers Entity Framework.

1. Mettez à niveau l'application.

   Un projet créé en utilisant une version antérieure de Visual Studio et du .NET Framework doit être mis à niveau pour utiliser Visual Studio 2008 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, consultez Procédure : définir manuellement les fichiers de modèle et de mappage.

   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, consultez Procédure : personnaliser les fichiers de modélisation et de mappage pour utiliser les objets personnalisés.

   Notes

   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, consultez 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 Guide pratique pour définir la chaîne de connexion.

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 Comment : configurer manuellement un projet Entity Framework.

Considérations relatives aux applications comportant des objets existants

À partir de .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 des entités POCO. 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 Guide pratique : utiliser l’Assistant Entity Data Model.

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 la page 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, consultez Utilisation des objets.

  Si Entity Framework ne fournit 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, consultez 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.

  Quand 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 quand 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<T>.

  Pour plus d’informations, consultez Liaison d’objets à des contrôles.

• 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, consultez Vue d’ensemble du contrôle serveur web EntityDataSource.

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, consultez Création d’applications multicouches.

• Applications qui utilisent des données XML.

  La sérialisation des objets vous permet de créer des services de 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 WCF Data Services. 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, consultez WCF Data Services 4.5.

  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, consultez Sérialisation d’objets.

  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, consultez LINQ to XML (C#) ou LINQ to XML (Visual Basic).

• 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, consultez Attachement et détachement d’objets.

Voir aussi

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