实体框架和多线程 [英] Entity Framework and Multi threading

问题描述

我们是有一些麻烦，我们设计的多线程实体框架驱动的应用程序，并希望一些指导。我们正在创建在不同的线程的实体，该实体将被添加到收藏它们然后绑定到不同的WPF控件数据。该ObjectContext类不是线程安全的，所以管理此，我们基本上有2个解决方案：

We are having some trouble designing our multi-threaded Entity Framework driven application and would like some guidance. We are creating entities on different threads, the entities are added to collections which are then data bound to various wpf controls. The ObjectContext class is not thread safe, so managing this we have essentially have 2 solutions:

解决方案1是有一个单一的情况下，小心地使用锁定，以确保没有2个线程同时访问它。这将是相对简单的实现，但需要的上下文是活着的应用程序的持续时间。它是一个坏主意，有一个单独的上下文实例打开这个样子？

Solution 1 is have a single context and carefully use locking to ensure no 2 threads access it at the same time. This would be relatively simple to implement but would require the context to be alive for the duration of the application. Is it a bad idea to have a single context instance open like this?

解决方案2是按需创建上下文对象，然后立即分离的对象，然后按住他们在我们自己的收藏集，然后重新连接他们做任何更新。这有一些严重的问题，使用的虽然，因为当物体脱离他们失去引用的导航属性的对象。同样有问题的2个线程仍然可以尝试访问单个对象，并都试图连接（）到一个环境。此外，我们需要每一个我们想要的时间访问一个实体导航属性提供一个新的环境。

Solution 2 is to create context objects on demand and then detach the objects immediately, then hold them in our own collections, then re-attach them to do any updating. This has some serious problems for use though, as when the objects are detached they lose references to the navigation property objects. Also there is the problem that 2 threads could still try to access a single object, and both try to attach() it to a context. Also, we would need to supply a new context every time we wanted to access an entities navigation properties.

问：要么两个解决方案有效，如果不是你怎么推荐我们解决这个

Q: Are either of the two solutions valid, if not how do you recommend we tackle this?

推荐答案

首先，我假设你已经阅读<一个href="http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/e5cb847c-1d77-4cd0-abb7-b61890d99fae/">this文章在MSDN 。

First off, I'm assuming you have read this article on MSDN.

解决方案＃1几乎可以肯定是从线程的角度来看是最安全的，因为你是保证只有一个线程的情况下，在任何互动有时间。没有什么内在的错误保持上下文around-它不保持打开的数据库连接在幕后，所以它只是内存开销。这可能，当然，present如果你最终瓶颈上线，整个应用程序是用单-DB-线程假设一个性能问题。

Solution #1 is almost certainly the safest from a threading perspective, since you are guaranteeing that only one thread is interacting with the context at any give time. There is nothing inherently wrong with keeping the context around- it isn't keeping database connections open behind the scenes, so it's just memory overhead. This could, of course, present a performance problem if you end up bottlenecked on that thread and the whole application is written with single-db-thread assumptions.

解决方案＃2似乎行不通到我 - 你最终会与微妙的错误在整个应用程序里的人忘了重新连接（或分离）的实体。

Solution #2 seems unworkable to me- you'd end up with subtle bugs throughout the application where people forget to re-attach (or detach) entities.

的一个解决方案是不使用的实体对象中的应用程序的UI层。我建议这个anyway-机会，实体的结构/布局对象是不是最佳的，你想怎么显示的东西在你的用户界面（这是对的MVC 的模式）。你的DAL应该有哪些是业务逻辑的具体（ UpdateCustomer 为例）的方法，并应在内部决定是否要创建一个新的环境，或使用存储之一。你可以用单个存储环境的方式开始，然后如果你碰到的瓶颈问题你有一个有限的表面区域，您需要进行更改。

One solution is to not use your entity objects in the UI layer of the application. I'd recommend this anyway- chances are, the structure/layout of the entity objects is not optimal for how you want to display things on your user interface (this is the reason for the family of MVC patterns). Your DAL should have methods which are business logic specific (UpdateCustomer for instance), and it should decide internally whether to create a new Context or use a stored one. You can start with the single stored context approach, and then if you run into bottleneck issues you have a limited surface area where you need to make changes.

缺点是，你需要写多了很多code-你有你的EF的实体，但你也不得不有重复的特性，许多EF实体的潜在的不同基数的实体企业。为了缓解这种情况，可以使用如 AutoMapper 框架，以简化从EF实体复制性的商业实体，然后再返回。

The downside is that you need to write a lot more code- you'd have your EF entities, but you'd also have business entities that have duplicate properties and potentially differing cardinality of many of the EF entities. To mitigate this, you can use frameworks like AutoMapper to simplify copying properties from the EF entities to the business entities and back again.

这篇关于实体框架和多线程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！