wpf - WPF应用程序中短暂的DbContext合理吗？

Question

在他关于 DbContext 的书中，@RowanMiller 展示了如何使用 DbSet.Local 属性来避免 1.) 不必要的数据库往返和 2.) 在应用程序中传递集合(例如使用 ToList() 创建)(第 24 页)。然后我尝试遵循这种方法。但是，我注意到从一个使用 [} – 块到另一个， DbSet.Local 属性变为空:

ObservableCollection<Destination> destinationsList;

using (var context = new BAContext())
{ 
   var query = from d in context.Destinations …;
   query.Load();
   destinationsList = context.Destinations.Local; //Nonzero here.
}
//Do stuff with destinationsList

using (var context = new BAContext())
{ 
   //context.Destinations.Local zero here again;
   //So no way of getting the in-memory data from the previous using- block here?
   //Do I have to do another roundtrip to the database here to get the same data I wanted
   //to cache locally???
}

那么，第 24 页的重点是什么？如果 DbSet.Local 仅在 using 块内可用，如何避免传递我的集合？此外，如果我使用这些短期上下文实例而不在幕后将任何缓存数据移交给彼此，我如何从更改跟踪中受益？那么，如果上下文应该是短暂的以释放连接等资源，我是否应该为此放弃缓存？ IE。我不能同时使用两者(短连接但长缓存)？所以我唯一的选择是将查询返回的结果存储在我自己的变量中，究竟是什么在第 24 页的动机中不鼓励？

我正在开发一个 WPF 应用程序，它可能在 future 也会变得多层，涉及 WCF。我知道 Julia 在她的书中有一个这样的例子，但我目前无法访问它。我在网上找到了其他几个，例如 http://msdn.microsoft.com/en-us/magazine/cc700340.aspx (旧的 ObjectContext，但很好地解释了层间协作)。在那里，使用了长期上下文(虽然提到了缺点，但没有提供解决方案)。
不仅仅是单个 Destinations.Local 丢失了，因为您肯定知道查询获取的所有其他实体也是如此。

[编辑]:
在阅读更多 Julia Lerman 的书后，似乎可以归结为 EF 默认没有二级缓存；然而，通过一些(我认为相当大的)努力，可以添加 3rd 方缓存解决方案，这在本书和 MSDN、codeproject 等的各种文章中也有描述。

如果在 DbContext 书中关于 DbSet.Local 的部分中提到了这个问题，我将不胜感激，它实际上是一个一级缓存，当 using {} 块结束时被破坏(只是我的建议，使其对读者)。第一次阅读后，我的印象是 DbSet.Local 总是会在第二个使用 {} 块中返回相同的引用(单例样式)，尽管有新的 DbContext 实例。

但是我仍然不确定二级缓存是否适合我的 WPF 应用程序(正如 Julia 在她的分布式应用程序文章中提到的二级缓存)？或者是通过 using {} 块中的一个或一些查询将我的域模型的聚合根实例(DDD，Eric Evans)放入内存的方法，处理 DbContext 并仅保存对聚合实例的引用，这避免长期上下文的方法？如果你能帮助我做出这个决定，那就太好了。

http://msdn.microsoft.com/en-us/magazine/hh394143.aspx
http://www.codeproject.com/Articles/435142/Entity-Framework-Second-Level-Caching-with-DbConte
http://blog.3d-logic.com/2012/03/31/using-tracing-and-caching-provider-wrappers-with-codefirst/

Answer 1

Local property提供“此集中所有已添加、未更改和已修改实体的本地 View ”。与所有更改跟踪一样，它特定于您当前使用的上下文。

DB Context 是用于加载数据和准备更改的工作区。

如果两个用户要同时添加更改，则在保存其他更改之前，他们必须不知道其他更改。他们可能会丢弃他们准备好的更改，这也会突然给其他用户带来问题。

DB Context 确实应该是短暂的，但在必要时可能比超短的要长。还要考虑到，如果您不加载和丢弃数据而只添加将要保存的更改，那么您可能无法通过保持资源的短暂性来节省资源。但这不仅与资源有关，还与当 DB 上下文仍处于事件状态并加载数据时可能发生变化的 DB 状态有关；对于更长寿的环境，记住这一点可能很重要。

如果您还不知道要立即保存到数据库中的所有相关更改，那么我建议您不要使用 DB Context 将更改存储在内存中，而是存储在代码中的数据结构中。

您当然可以在没有事件 DB 上下文的情况下使用实体对象来执行此操作。如果您没有其他合适的数据类并且不想创建一个，或者决定准备其中的更改更有意义，那么这很有意义。然后您可以使用 DbSet.Attach 将实体附加到数据库上下文以在您准备好时保存更改。