Framework d'entité et regroupement de connexions

J'ai récemment commencé à utiliser Entity Framework 4.0 dans mon application .NET 4.0 et je suis curieux de savoir certaines choses concernant le pooling.

1. Le pool de connexions que je connais est géré par le fournisseur de données ADO.NET, dans mon cas, celui du serveur MS SQL. Cela s'applique-t-il lorsque vous instanciez un nouveau contexte d'entités ( ObjectContext), c'est-à-dire sans paramètre new MyDatabaseModelEntities()?

2. Quels sont les avantages et les inconvénients de a) créer un contexte d'entités globales pour l'application (c'est-à-dire une instance statique) ou b) de créer et d'exposer un contexte d'entités pour chaque opération / méthode donnée, avec un usingbloc.

3. Y a-t-il d'autres recommandations, meilleures pratiques ou approches communes pour certains scénarios que je devrais connaître?

1. Le regroupement de connexions est géré comme dans toute autre application ADO.NET. La connexion d'entité utilise toujours une connexion de base de données traditionnelle avec une chaîne de connexion traditionnelle. Je crois que vous pouvez désactiver le regroupement de connexions dans la chaîne de connexion si vous ne souhaitez pas l'utiliser. (en savoir plus sur le regroupement de connexions SQL Server (ADO.NET) )
2. N'utilisez jamais le contexte mondial. ObjectContext implémente en interne plusieurs modèles, y compris la carte d'identité et l'unité de travail. L'impact de l'utilisation du contexte global est différent selon le type d'application.
3. Pour les applications Web, utilisez un seul contexte par demande. Pour les services Web, utilisez un seul contexte par appel. Dans les applications WinForms ou WPF, utilisez un seul contexte par formulaire ou par présentateur. Il peut y avoir des exigences spéciales qui ne permettront pas d'utiliser cette approche mais dans la plupart des situations, cela suffit.

Si vous voulez savoir quel impact a le contexte d'objet unique pour l'application WPF / WinForm, consultez cet article . Il s'agit de NHibernate Session mais l'idée est la même.

Éditer:

Lorsque vous utilisez EF, il charge par défaut chaque entité une seule fois par contexte. La première requête crée une instance d'entité et la stocke en interne. Toute requête ultérieure qui nécessite une entité avec la même clé renvoie cette instance stockée. Si les valeurs du magasin de données ont changé, vous recevez toujours l'entité avec les valeurs de la requête initiale. C'est ce qu'on appelle le modèle de carte d'identité . Vous pouvez forcer le contexte de l'objet à recharger l'entité mais il rechargera une seule instance partagée.

Les modifications apportées à l'entité ne sont pas conservées jusqu'à ce que vous appeliez SaveChangesle contexte. Vous pouvez effectuer des modifications dans plusieurs entités et les stocker simultanément. C'est ce qu'on appelle le modèle d'unité de travail . Vous ne pouvez pas dire de manière sélective l'entité attachée modifiée que vous souhaitez enregistrer.

Combinez ces deux modèles et vous verrez des effets intéressants. Vous n'avez qu'une seule instance d'entité pour l'ensemble de l'application. Toutes les modifications apportées à l'entité affectent l'ensemble de l'application même si les modifications ne sont pas encore persistantes (validées). Dans la plupart des cas, ce n'est pas ce que vous voulez. Supposons que vous ayez un formulaire d'édition dans l'application WPF. Vous travaillez avec l'entité et vous décidez d'annuler une édition complexe (modification de valeurs, ajout d'entités liées, suppression d'autres entités liées, etc.). Mais l'entité est déjà modifiée dans un contexte partagé. Que vas-tu faire? Astuce: je ne connais aucun CancelChanges ou UndoChanges surObjectContext .

Je pense que nous n'avons pas à discuter du scénario du serveur. Le simple partage d'une seule entité entre plusieurs requêtes HTTP ou appels de service Web rend votre application inutile. Toute demande peut simplement déclencherSaveChanges et enregistrer des données partielles d'une autre demande car vous partagez une seule unité de travail entre toutes. Cela aura également un autre problème - le contexte et toute manipulation avec des entités dans le contexte ou une connexion à une base de données utilisée par le contexte n'est pas thread-safe.

Même pour une application en lecture seule, un contexte global n'est pas un bon choix car vous voulez probablement de nouvelles données à chaque fois que vous interrogez l'application.

Selon Daniel Simmons:

Créez une nouvelle instance ObjectContext dans une instruction Using pour chaque méthode de service afin qu'elle soit supprimée avant le retour de la méthode. Cette étape est essentielle pour l'évolutivité de votre service. Il s'assure que les connexions à la base de données ne sont pas maintenues ouvertes entre les appels de service et que l'état temporaire utilisé par une opération particulière est récupéré lorsque cette opération est terminée. Entity Framework met automatiquement en cache les métadonnées et autres informations dont il a besoin dans le domaine d'application et les connexions de base de données des pools ADO.NET, donc la recréation du contexte à chaque fois est une opération rapide.

C'est de son article complet ici:

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

Je crois que ce conseil s'étend aux requêtes HTTP, donc serait valable pour ASP.NET. Une application cliente avec état, telle qu'une application WPF, pourrait être le seul cas pour un contexte "partagé".

Conformément à la documentation EF6 (4,5 également): https://msdn.microsoft.com/en-us/data/hh949853#9

9.3 Contexte par demande

Les contextes d'Entity Framework sont destinés à être utilisés comme des instances de courte durée afin de fournir l'expérience de performance la plus optimale . Les contextes devraient être de courte durée et rejetés, et en tant que tels ont été mis en œuvre pour être très légers et réutiliser les métadonnées chaque fois que possible. Dans les scénarios Web, il est important de garder cela à l'esprit et de ne pas avoir un contexte plus long que la durée d'une seule demande. De même, dans les scénarios non Web, le contexte doit être ignoré en fonction de votre compréhension des différents niveaux de mise en cache dans Entity Framework. D'une manière générale, il convient d'éviter d'avoir une instance de contexte tout au long de la vie de l'application, ainsi que des contextes par thread et des contextes statiques.

Le code ci-dessous a aidé mon objet à être actualisé avec de nouvelles valeurs de base de données. La commande Entry (object) .Reload () force l'objet à rappeler les valeurs de la base de données

GM_MEMBERS member = DatabaseObjectContext.GM_MEMBERS.FirstOrDefault(p => p.Username == username && p.ApplicationName == this.ApplicationName);
DatabaseObjectContext.Entry(member).Reload();