实体框架：数据上下文的生命？

Question

我正在阅读数据上下文的推荐寿命，但我仍然对最佳选择存有疑问。

总的来说，我看到的结论是，在桌面应用程序中，数据上下文的生命周期应该是表单的生命周期，而在 WCF 应用程序中，生命周期应该是会话的生命周期。

原因，如果我理解的话，这是因为数据上下文的生命周期应该足够大以具有上下文工作单元的优点，但又不能太大而失去它的好处。

但是，例如，如果我从数据库中读取一些数据并且数据上下文被创建为桌面应用程序中表单的属性，如果我进行更改，我只需要更改实体中的值数据上下文并调用 savechanges() 方法，EF 将更改保存在数据上下文中。所以我与数据库有两种交互，一种是获取数据，另一种是保存更改。

但是，这样，数据上下文会变得非常大，而且出现并发问题的可能性也更大，我的意思是，由于我加载数据，进行更改并保存数据，其他用户有时间修改信息。

如果我为每个操作使用数据上下文，我会使用 dispose 的数据上下文读取数据，对局部变量中的信息进行更改，然后，当我保存更改时，我必须使用其他数据上下文，这再次接收实体，我必须搜索实体以将信息从我的局部变量传递给实体，然后保存更改。

在这种情况下，我与数据库进行了三个交互，因此效率较低，数据库必须做更多的工作。一个是获取结果并将信息传递给局部变量，另一个是再次获取结果并将信息从局部变量传递到上下文，最后保存更改。此外，我必须做额外的工作来搜索第二个数据上下文中的实体，以将局部变量的更改传递到新的上下文。

但是，并发问题发生的可能性较小，因为只是在第二个数据上下文中加载数据和将更改从局部变量传递到上下文之间经过的时间。

那么，在桌面应用程序和 WCF 应用程序中，哪个是处理数据上下文的最佳选择？也许我在使用数据上下文时做错了？

也许如果我使用第二种方法，并且我的本地变量也是实体，我可以创建第二个数据上下文，而不是从数据库加载实体，我可以直接添加本地实体，将其状态更改为添加，更改或删除，然后数据上下文可以保存更改？

Answer 1

所以，这是在桌面中使用数据上下文的最佳选择 应用程序和 WCF 应用程序？

这取决于具体情况，但在大多数情况下，这正是您所需要的：

• WinForm / WPF - 每个表单/每个演示者等
• WCF - 每个服务调用； 从不每个会话或每个应用程序
• ASP.NET - 每个请求； 从不每个会话或每个应用程序

在这些情况下，每个提到的范围通常是一个工作单元。如果范围内有多个工作单元，则可能需要不同的上下文实例化。

最困难的情况是多线程 Windows 服务，您必须手动识别工作单元并使用适当的上下文生命周期。 从不在线程之间共享上下文。 避免使用用于服务多个作品单元的全局长寿命上下文。 Here 是相关描述为什么共享上下文是一个错误的想法。

但是，并发问题发生的可能性较小，因为 只是第二次加载数据之间经过的时间 数据上下文并将本地变量的更改传递给 上下文。

那是对并发问题的误解。乐观并发应该检查您没有覆盖另一个线程/用户所做的更改。因此，您必须使用在修改之前加载的原始数据，因为这是您在修改之前知道的最后一个状态。如果最后一个状态与数据库中的当前状态不匹配，则必须解决并发问题。必须修改您提出的解决方案以支持这一点 - 例如，当您从数据库加载数据以进行更新时，您必须遍历所有实体并检查当前时间戳是否等于在第一次数据检索时从数据库加载的时间戳。