Cadre d'entité et pool de connexion

Question

J'ai récemment commencé à utiliser l'Entity Framework 4.0 dans mon .NET 4.0 application et je suis curieux de savoir quelques choses relatives à la mise en commun.

1. Le regroupement de connexion que je sais, c'est géré par le ADO.NET fournisseur de données, dans mon cas, celui de MS SQL server. Cela s'applique lorsque vous instanciez un nouveau entités contexte (ObjectContext), c'est à dire la sans paramètre new MyDatabaseModelEntities()?

2. Quels sont les avantages et les inconvénients de a) la création d'une des entités mondiales contexte de l'application (c'est à dire une instance statique) ou b) de créer et d'exposer des entités contexte pour chaque opération, de méthode, avec un using bloc.

3. Toutes les autres recommandations, bonnes pratiques, ou des approches communes pour certains scénarios que je devrais connaître?

Answer 1

1. Le regroupement de connexion est gérée comme dans tous les autres ADO.NET application. Entité de connexion utilise encore des bases de données traditionnelles de la connexion avec la traditionnelle chaîne de connexion. Je crois que vous pouvez désactiver la connexion de mise en commun dans la chaîne de connexion si vous ne voulez pas l'utiliser. (pour en savoir plus à propos de SQL Server pool de Connexion (ADO.NET))
2. Ne jamais utiliser dans un contexte global. ObjectContext en interne met en œuvre plusieurs modèles, y compris Carte d'Identité et de l'Unité de Travail. Incidence de l'utilisation du contexte mondial est différent par type d'application.
3. Pour les applications web utilisent même contexte par demande. Pour les services web utilisent même contexte par appel. En WinForms ou WPF utilisation de l'application seule de contexte par formulaire ou par le présentateur. Il peut y avoir des exigences particulières qui ne permettra pas l'utilisation de cette approche, mais dans la plupart des situation, c'est assez.

Si vous voulez savoir quel est l'impact du seul contexte de l'objet pour WPF / WinForm demande de vérifier cet article. C'est à propos de NHibernate Session, mais l'idée est la même.

Edit:

Lorsque vous utilisez EF par défaut des charges de chaque entité, une seule fois par le contexte. La première requête crée une entité instace et les stocke en interne. Toute requête qui exige de l'entité avec la même clé est de retour cette stockées instance. Si les valeurs dans la banque de données modifié, vous continuez à recevoir l'entité avec les valeurs de la requête initiale. Ceci est appelé modèle carte d'Identité. Vous pouvez forcer le contexte de l'objet de recharger l'entité, mais il permettra de recharger une seule et même instance.

Toutes les modifications apportées à l'entité ne sont pas persisté jusqu'à ce que vous appelez SaveChanges sur le contexte. Vous pouvez faire des changements dans de multiples entités et de les stocker à la fois. Ceci est appelé motif d'Unité de Travail. Vous ne pouvez pas sélectivement dire, qui a modifié attaché entité que vous souhaitez enregistrer.

Combiner ces deux modèles et vous allez voir quelques effets intéressants. Vous n'avez qu'une seule instance de l'entité pour l'ensemble de l'application. Toute modification de l'entité affecte l'ensemble de l'application, même si les changements ne sont pas encore persisté (commis). Dans la plupart du temps, ce n'est pas ce que vous voulez. Supposons que vous disposez d'un formulaire de modification en application WPF. Vous travaillez avec l'entité et que vous décider de quelle annuler complexe editation (évolution des valeurs, l'ajout d'entités liées, la suppression d'autres entités liées, etc.). Mais l'entité est d'ores et déjà modifié dans le contexte partagé. Qu'allez-vous faire? Indice: je ne sais pas, CancelChanges ou UndoChanges sur ObjectContext.

Je pense que nous n'avons pas à discuter scénario de serveur. Tout simplement le partage entité unique entre plusieurs requêtes HTTP ou les appels de service Web permet à votre application inutile. Toute demande peut simplement déclencher SaveChanges et enregistrer des données partielles à partir d'une autre requête parce que vous partagez la même unité de travail de leur part à tous. Ce qui aura aussi un autre problème - contexte et toute manipulation avec des entités dans le contexte ou une connexion de base de données utilisé par le contexte n'est pas thread-safe.

Même pour un readonly application un contexte mondial n'est pas un bon choix parce que vous voulez probablement de nouvelles données à chaque requête de l'application.

Answer 2

Selon Daniel Simmons:

Créer une nouvelle instance de ObjectContext dans à l'Aide d'instruction pour chaque service méthode de sorte qu'il est disposé de avant le retour de la méthode. Cette étape est essentielle pour l'évolutivité de votre service. Il permet de s'assurer que les connexions de base de données ne sont pas gardés ouverte à travers les appels de service et état temporaire utilisée par une opération garbage collecté lors que l'opération est terminée. Entity Framework met automatiquement en cache de métadonnées et d'autres informations dont il a besoin dans le domaine de l'application, et ADO.NET les pools de connexions de base de données, afin de re-créer le contexte à chaque fois est une opération rapide.

C'est à partir de son article complet ici:

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

Je crois que ce conseil s'étend à des requêtes HTTP, ce serait valable pour ASP.NET. Avec un état, de la graisse de la demande du client comme une application WPF peut être le cas que pour un "partage" du contexte.

Answer 3

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();