0

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

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

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

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

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

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

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

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

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

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

4

1 回答 1

6

那么，在桌面应用程序和 WCF 应用程序中，哪个是处理数据上下文的最佳选择？

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

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

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

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

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

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

于 2012-04-15T09:09:17.650 回答