C# 探索为每个使用DbContext的ViewModel/类使用DbContext的陷阱（如果有）

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

考虑到每个ViewModel都是通过维护与模型本身的关系来监视和操纵视图状态的，我开始怀疑旋转多个DbContext对象的含义，以及DbContext之类的对象是否最好作为一个单独的对象保留—我很快发现答案是“”。因此，如果共识是每次使用都有一个实例（如多视图模型的情况，或者你有什么），我仍然没有看到有人提到使用该模型的潜在问题

为了详细说明，假设我有两个ViewModel，并且在每个ViewModel中创建一个上下文（

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拥有更多的最新数据，因为它的上下文更“最新”。像这样的事情我很想知道

谢谢

编辑

---

我不希望发现/涵盖每一种情况，因为这是编码所针对的情况所特有的。我只是想知道是否有任何“预先”或明显的危险，我不知道这是一个新手。

实体框架和扩展

DbContext

支持

UnitOfWork

设计模式。这样做的目的是将逻辑“事务”分开。因此，您通常希望应用程序的每个部分或功能都处理自己的

DbContext

实例

您可以这样想：

DbContext

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

谢谢你关于陷坑和危险的问题；实体框架默认使用所谓的乐观并发。这意味着在将本地更改保存回数据库时，根本不检查并发性。无论应用程序中的另一个用户或另一个上下文是否更改了数据库，本地DbContext中的所有内容都会发送回数据库。下面是一篇优秀的文章，解释了这一点以及如何改变行为：

---

您有什么理由不想用using语句将其包装起来，并在处理之前调用save changes以保持其最新状态吗？@Justin出于我管理导航属性的目的，我依赖于通过外键显示数据，这些外键是用来“遍历”的，如果我没有枚举作为导航属性的集合，那么using语句将处理我的上下文——或者说它看起来就是这样。所以我肯定需要在ViewModel的整个生命周期中保持该上下文的活跃性。Chris，谢谢你的回复。我觉得我很难找到大量的答案。如果我找不到广泛的“陷阱”，那么我认为至少有一个迹象表明DbContext至少打算处理并发性（如果不是作为单例使用的话），对于99%的情况来说，这足以处理任何事情。我见过朱莉·勒曼写过一本关于DbContext的书。我得去接一下以供参考。不客气。朱莉在Pluralsight.com上有一些很棒的视频，我强烈推荐。这是一项订阅服务，但他们有试用期。祝你好运