【翻译】提示18——如何决定ObjectContext的生命周期

原文地址：http://blogs.msdn.com/b/alexj/archive/2009/05/07/tip-18-how-to-decide-on-a-lifetime-for-your-objectcontext.aspx

作者：Alex D James

我们经常碰到一个问题是ObjectContext应对存活多久。经常被引用的选项包括：

• 函数（Function）
• 窗体（Form）
• 线程（Thread）
• 应用程序（Application）

很多人都在问这类型的问题，典型的例子是在Stackflow上的问题。我相信有更多的类似问题被埋没在我们的论坛上。

这是一个经典的取决于类型的问题。

做出决定有许多权衡因素，主要包括：

• 处置（Disposal）：

干净处置ObjectContext和它的资源是很重要的。如果为每一个函数创建一个新的ObjectContext，这会容易很多，因为可以简单的使用using块来确保适当的释放资源。

using (MyContext ctx = new MyContext())
{
…
}

• 构建的花费（Cost Of Construction）：

许多人比较关注重一次又一次的重新创建ObjectContext的花费，这完全可以理解。现实情况是这种成本其实很低，因为大部分时候，它只涉及到通过引用将元数据从全局缓存中复制到新的ObjectContext。基本上，我不认为这种成本是值得担心的，但一如既往，这规则存在例外情况。

• 内存使用（Memory Usage）：

越多的使用一个ObjectContext，基本上它就会越占内存。这是因为，基本上无论是查询、添加或附加，它都要保存对所有实体的引用。因此，必须考虑无限期地共享相同的ObjectContext所存在的问题。尽管对于这种情况有一些例外和解决办法，但大部分时候，不建议这样做。

○ 如果ObjectContext只是执行NoTracking查询，那么它不会变大，因为它会立即忘记这些实体。

○可以实现一些非常明确的善后逻辑，即实现某种形式的循环接口，遍历ObjectStateManager中分离的实体和AcceptingChanges(..) 来放弃删除对象。注意：我不建议这样，我只是说，它应用有可能，因为我不知道相对于重新创建，它是否会导致保存。这也许是未来博客文章的一个好题材。

• 线程安全（Thread Safety）：

如果尝试去重用一个ObjectContext，你应该知道，它不是线程安全的，这类似于标准的.NET集合类。如果你从许多线程（如web请求）中访问它，你就要确保手动进行同步访问。

• 无状态（Stateless）：

如果你的服务被设计为无状态的，其实大多数Web服务应该是这样，在请求之间重用ObjectContext可能不是最好的，因为最后一次通话的ObjectContext的残余（leftovers）可能会产生微秒的影响，而这并不是应用程序所预期的。

• 自然有限的生命周期（Natural finite lifetimes）：

如果你使用一个自然有限的生命周期的方式来管理ObjectContext，如一个短周期的窗体，一个UnitOfWork，或一个存储库，那么有作用范围的ObjectContext可能是最好的实现。

正如你所看到的，有许多因素在起作用。

他们中的大多数倾向于短生命周期的上下文，而不是共享的。

因此，这就是我推荐的法则。

然后，只有了解了这背后的“推理法则”，才有助于在适当的时候采用适合自己的方式。