Considérations sur la migration (Entity Framework)

ADO.NET Entity Framework présente plusieurs avantages pour une application existante. La possibilité d'utiliser le modèle EDM (Modèle de données d'entité) 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 de l'utilisation d'Entity Framework, voir Présentation d'Entity Framework.

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 .NET Framework version 3.5 Service Pack 1 (SP1), la définition du modèle EDM et la configuration d'Entity Framework. Lorsque vous effectuez la migration d'une application vers Entity Framework, certains points 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 3.5 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 Visual Studio 2008. Pour plus d'informations, voir 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 Visual Studio 2008 SP1 et .NET Framework 3.5 SP1. Pour plus d'informations, voir Assistant Conversion de Visual Studio.

2. Définissez le modèle EDM (Modèle de données d'entité).

   Le modèle EDM définit 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 un modèle EDM (Entity Data Model) (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 un modèle EDM (Entity Data Model) pour travailler avec 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 Vue d'ensemble d'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 EDM. Cette chaîne de connexion encapsule des informations relatives aux fichiers de mappage EDM et à la connexion à la source de données. Pour plus d'informations, voir 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 au modèle EDM 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, voir Procédure : configurer manuellement un projet Entity Framework.

Considérations relatives aux applications comportant des objets existants

Lorsque vous effectuez la migration d'une application vers Entity Framework, la façon dont vous migrez des classes de données existantes dépend de la logique métier, des méthodes personnalisées et de la validation de propriété implémentées dans ces classes. Vous devez choisir l'une des approches suivantes pour utiliser des classes de données existantes.

• Si vos classes de données obtiennent et définissent seulement des propriétés de l'objet, remplacez vos classes de données existantes par les types d'entités générés par les outils Modèle de données d'entité. Pour plus d'informations, voir Procédure : utiliser l'Assistant Entity Data Model (Entity Framework).

• Si vos classes de données implémentent du code de validation personnalisé ou une autre logique métier, migrez cette logique vers les classes partielles qui sont générées par les outils Modèle de données d'entité. Les outils Modèle de données d'entité génèrent des types d'entités en tant que classes partielles. Cela vous permet de réutiliser des méthodes et des propriétés en convertissant vos classes existantes en classes partielles. Lorsque vous procédez ainsi, vous devez supprimer de l'application existante toutes les propriétés qui sont dupliquées dans la classe générée. Pour plus d'informations sur la création de classes partielles, voir Personnalisation des objets (Entity Framework).

  Pour chaque propriété d'une classe de données, les outils Entity Framework génèrent des méthodes partielles nommées OnPropertyNameChanging et OnPropertyNameChanged. Vous pouvez déplacer votre code de validation de propriété existant vers ces méthodes partielles. Pour plus d'informations, voir Procédure : exécuter la logique métier lors de la modification des propriétés (Entity Framework).

• Si vos classes de données existantes contiennent une quantité significative de code personnalisé ou si vous voulez garder vos classes de données existantes pour d'autres raisons, vous devez effectuer l'une des opérations suivantes :

  • Modifiez vos classes de données pour hériter de la classe EntityObject ou de la classe ComplexObject. Tous les types EDM générés héritent de la classe EntityObject ou de la classe ComplexObject, et Entity Framework vous permet d'utiliser des classes de données personnalisées en héritant de ces classes de base. Il s'agit de la méthode recommandée pour utiliser des classes de données personnalisées avec un modèle EDM. Pour plus d'informations, voir Personnalisation des objets (Entity Framework).

  • Modifiez vos classes de données pour implémenter un ensemble d'interfaces. Procédez de cette manière si vos classes de données ne peuvent pas hériter des classes EntityObject ou ComplexObject. Pour plus d'informations sur l'implémentation de ces interfaces, voir Personnalisation des objets (Entity Framework).

Remarque
Lorsque vous utilisez des classes de données existantes ou des classes partielles avec un modèle EDM, les noms des classes doivent correspondre aux noms des entités définis dans le modèle conceptuel. Utilisez le Concepteur d'entités pour renommer les entités. Pour plus d'informations, voir Procédure : créer et modifier des types d'entités.

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 Entité 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 les services Object Services 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, voir Fournisseur EntityClient pour Entity Framework.

• Utilisation de datasets.
  Dans Entity Framework, les services Object Services fournissent 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 Vue d'ensemble d'Object Services (Entity Framework).

  Si les services Object Services 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 EDM, les services Object Services retournent 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 Services Web et Entity Data Model (scénarios d'application).

• 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 et fournissent un accès dynamique à des 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 Framework.

  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 d'objets (Entity Framework).

Voir aussi

Concepts

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

Autres ressources

Tâches Entity Framework