探索为每个使用它的ViewModel/Class提供DbContext的陷阱(如果有的话)

Question

我正在学习实体框架并在MVVM应用程序中使用它,其中每个ViewModel都使用DbContext进行数据访问.免责声明:在实际应用程序中,我知道ViewModel不应直接与数据访问层交互.

鉴于每个ViewModel都是通过维护与模型本身的关系来监视和操纵View的状态,我开始怀疑旋转多个DbContext对象的含义,并且如果像DBContext这样的东西最好留作单例 - 我很快找到了答案是" 不 ".因此,如果共识是每个用户都有一个实例(如多个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通过其上下文更加"最新"而具有比另一个更新的数据.我有兴趣知道这样的事情.

谢谢.

编辑

我不希望发现/涵盖所有情况,因为这对于编码的情况是独特的.我只是想知道是否有任何"前期"或明显的危险,我不知道自己是这个主题的新手.

Answer 1

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

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

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