探索为每个ViewModel / Class使用DbContext的陷阱（如果有） [英] Exploring the pitfalls(if any) of having a DbContext for each ViewModel/Class that uses it

问题描述

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

由于每个ViewModel都在监视和操作通过保持与模型本身的关系，我开始怀疑旋转多个DbContext对象的影响，如果像DBContext这样的东西最好留作单身，我很快就发现答案是NO 。所以如果共识是为每个使用的一个实例（如在多个ViewModels的情况下，或者什么有用的），我仍然没有看到任何人提到这样做的潜在问题。

要详细说明，让我说我有两个ViewModels，每个我创建一个Context（ TestContext 继承自 DbContext ）在每个ViewModel的生命周期内维护数据访问活动：

  public class MainWindowViewModel：ViewModelBase 
 {
 private TestContext db = new TestContext（）; 
 ...其他代码如下（属性方法等）... 
} 
 
 public class TestViewModel：ViewModelBase 
 {
 private TestContext db = new TestContext（）; 
 ...其他代码如下（属性方法等）... 
} 
  

每个类中有上下文可以消耗什么陷阱？

一个这样的想法，嘲笑我是如果有可能有上下文与另一个不同步，使得一个ViewModel具有比另一个更新的数据，通过其上下文更更新。

谢谢。

编辑

我不希望发现/覆盖每一种情况，因为这对于编码的情况是独一无二的。我只是想知道是否有任何前期或明显的危险，我不知道是新的主题。

解决方案

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

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

有关陷阱和危险的问题;实体框架默认使用所谓的乐观并发。这意味着当将本地更改保存回数据库时，根本不会检查并发。无论您的本地DbContext中的任何内容是否被更改，您的本地DbContext中的任何内容将被发送回数据库。一个很好的文章解释和如何改变行为可以在这里找到：
http://msdn.microsoft.com/en-us/library/bb738618.aspx

I am learning the Entity Framework and using it in an MVVM app where each ViewModel works with the DbContext for Data Access. Disclaimer: In a real application I know the ViewModel shouldn't interact directly with the Data Access Layer.

Given that each ViewModel is there to monitor and manipulate the state of the View by maintaining relationships with the Models themselves, I began to wonder about the implications of spinning up multiple DbContext objects, and if something like a DBContext is best left as a singleton - to which I quickly found the answer was "NO". So if the consensus is to have an instance for each use (as in the case with multiple ViewModels, or what-have-you) I still havent seen where any one mentions the potential issues with having this.

To elaborate, lets say I have two ViewModels and in each I create a Context (TestContext inherits from DbContext) to maintain the Data Access activities during the lifetime of each 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...)...
}

Are there any pitfalls with having a context in each class that can consume it?

One such thought that taunts me is if it's possible to have either context be out of sync with the other, such that one ViewModel has more recent data than the other by way of its context being more "up-to-date". Things like this I am interested in knowing.

Thanks.

EDIT

I dont hope to discover / cover every situation as that would be unique TO the situation against which one is coding. I just want to know if there are any "up-front" or obvious perils that I am unaware of being new to the subject.

解决方案

Entity Framework and by extension DbContext supports the UnitOfWork design pattern. The idea being that you keep your logical "transactions" separated. Because of this, you will usually want to have each portion or feature of your application deal with its own DbContext instance.

The way you can think about it is that the DbContext holds a local copy of whatever it pulled from the database and tracks all changes made to the local data by the user. When you're ready, you tell it to push the required changes back to the database in one go.

For your question about pit-falls and perils; The Entity Framework uses what's called optimistic concurrency by default. This means that when saving the local changes back to the database, concurrency isn't checked at all. Whatever you had in your local DbContext is sent back to the database regardless of whether another user or another context in your application changed it. An excellent article explaining that and how to change the behaviour can be found here: http://msdn.microsoft.com/en-us/library/bb738618.aspx

这篇关于探索为每个ViewModel / Class使用DbContext的陷阱（如果有）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！