实体框架和ObjectContext参考

Question

我玩弄实体框架，看看它如何在我正在使用的新项目中使用。我把我的edmx文件放在一个类库中，这样实体（和数据库访问）可以在多个地方使用。目前我有一个Web项目和一个控制台项目，都引用了类库。

我的一个实体有一个用静态方法定义的部分类。该方法的目的是接受一些参数并创建特定类的一个或多个实例。我的第一个版本的方法创建了一个ObjectContext实例，创建了实体类（或类），并将实体返回给调用方法。调用方法然后更新了一些属性，并尝试使用新的ObjectContext实例保存实体。显然这不起作用，因为实体被绑定（正确的术语??）到静态方法中创建的上下文。

经过一番研究，我修改了静态方法以接受ObjectContext引用，以确保创建的所有实体，然后使用相同的上下文进行操作和保存。这工作正常，但设计只是感觉不对。假设我的一个静态方法可能增长得更多，或者我的应用程序（特别是Web应用程序）可能会从附加层（DAL甚至服务层）中受益，那么这对所有这些类都有意义吗？需要一个ObjectContext参数？

我读过很多贴子，认为通过Singleton模式创建ObjectContext是一个坏主意，因为“许多客户端会使用同一个对象”。我的问题是我不明白这是怎么可能的。在本地控制台应用程序中，只有一个用户在运行该应用程序。在一个网络应用程序中，每个请求只有一个用户。用户共享问题在哪里？没有一篇文章/文章提到它......但是它们指向在Application上下文中存储对象实例的单例模式？

我也看到过关注web使用情况，并通过HttpContext对象将对象实例存储在用户Session对象中。这是有道理的，但似乎并未解决非Web使用问题。

我认为无论什么解决方案都适合（静态方法，工厂对象等）很可能会在我的类库中实现，所以显然它需要同时支持Web和非Web解决方案。也许检查HttpContext，以确定它运行在什么样的环境。

我希望http://www.west-wind.com/weblog/posts/2008/Feb/05/Linq-to-SQL-DataContext-Lifetime-Management会提供信息，但我很难包围我的头和示例代码似乎是矫枉过正的实例化和共享一个简单目的。 （虽然我相信我只是没有得到它...）

任何想法都赞赏。

谢谢。

Answer 1

问题不在于“许多客户端会使用同一个对象”。问题是ObjectContext旨在成为一个单一的工作单元。如果您将它用于许多不同的工作单元，您会发现存在一些问题。

• 内存使用量将会增长和增长。
• 由于对象修补必须增加工作量，因此您的应用程序将变得更慢。
• 多线程将不起作用

的解决方案是使用在ObjectContext的意图，即，方式，随着工作的单个单元。