7

我正在学习实体框架并在 MVVM 应用程序中使用它，其中每个 ViewModel 与 DbContext 一起工作以进行数据访问。免责声明：在实际应用程序中，我知道 ViewModel 不应该直接与数据访问层交互。

鉴于每个 ViewModel 都是通过维护与模型本身的关系来监视和操纵 View 的状态，我开始想知道旋转多个 DbContext 对象的含义，以及最好将 DBContext 之类的东西保留为单例 -我很快发现答案是“不”。因此，如果共识是为每次使用都有一个实例（例如在多个 ViewModel 的情况下，或者你有什么），我仍然没有看到任何人提到使用这个的潜在问题。

详细地说，假设我有两个 ViewModel，并在每个 ViewModel 中创建一个 Context（TestContext继承自DbContext）以在每个 ViewModel 的生命周期内维护数据访问活动：

public class MainWindowViewModel : ViewModelBase
{
    private TestContext db = new TestContext();
    ... other code follows (properties methods etc...)...
}

public class TestViewModel: ViewModelBase
{
    private TestContext db = new TestContext();
    ... other code follows (properties methods etc...)...
}

在每个可以使用它的类中都有一个上下文有什么陷阱吗？

一种嘲弄我的想法是，是否有可能使任何一个上下文与另一个不同步，这样一个 ViewModel 的数据比另一个 ViewModel 的数据更新，因为它的上下文更“最新”。像这样的事情我有兴趣知道。

谢谢。

编辑

我不希望发现/涵盖所有情况，因为这对于编码的情况来说是独一无二的。我只是想知道是否有任何“预先”或明显的危险，我不知道是这个主题的新手。

4

1 回答 1

4

实体框架并通过扩展DbContext支持UnitOfWork设计模式。这个想法是你保持你的逻辑“交易”分开。因此，您通常希望应用程序的每个部分或功能都处理自己的DbContext实例。

您可以考虑的方式是，它DbContext保存从数据库中提取的任何内容的本地副本，并跟踪用户对本地数据所做的所有更改。准备好后，您告诉它一次性将所需的更改推送回数据库。

关于陷阱和危险的问题；Entity Framework 默认使用所谓的乐观并发。这意味着当将本地更改保存回数据库时，根本不会检查并发性。无论您的应用程序中的另一个用户或另一个上下文是否更改了它，本地 DbContext 中的任何内容都会被发送回数据库。可以在这里找到一篇很好的文章来解释这一点以及如何改变行为：http: //msdn.microsoft.com/en-us/library/bb738618.aspx

于 2013-03-01T01:34:16.883 回答