Windows/WPF/Silverlight 应用程序中的实体框架 ObjectContext
我们正在使用实体框架（准确地说是带有 RIA 服务的 Silverlight）编写一个 WPF 应用程序。我们通过应用程序使用共享的 ObjectContext，以便我们可以从跨模块共享数据中受益。
问题是 - 如果用户在工作期间打开历史销售，它会加载到 ObjectContext 并保留在那里，直到应用程序结束。所以应该使用另一种模式。
我知道 ObjectContext 应该用作单个工作单元。但是，如何让应用程序的其他部分知道某些内容发生了变化并且他们应该重新加载数据呢？
编辑：好的，EventAggregator，但是，这会导致所有其他部分重新加载它们的（可能大部分是重复的）数据。所有类型的实体群体也可能需要许多事件。
你如何解决这些问题？我当前的解决方案是一种折衷方案 - 对整个应用程序使用的核心数据使用共享的 ObjectContext，以便它们可以自动共享和更新。对于大量数据，请使用新的单独的ObjectContext。还有更好的想法吗？
有没有办法从 DataContext 中“释放”实体，以便垃圾收集器可以完成其工作并释放内存？
We are writing a WPF application using Entity framework (Silverlight with RIA services to be precise). We're using a shared ObjectContext through the application so that we can benefit from sharing data across the modules.
The problem is - if user during his work opens let's say historical sales, it gets loaded to the ObjectContext and stays there until the end of the application. So another pattern should be used.
I know that ObjectContexts should be used as single Unit-of-Work. But then, how do you let other parts of the application know that something has changed and they should reload their data?
Edit: Ok, EventAggregator, but then, this would cause all other parts to reload their (probably much of it duplicate) data. Also probably many event would be needed for all the types of entites groups.
How do you solve these problems? My current solution is a kind of compromise - use a shared ObjectContext for the core data used by whole appliaction so that they can be shared and updated automatically. And for the large amount of data, use a new separate ObjectContext. Any better ideas?
Is there a way how to "release" entities from their DataContext so that Garbage collector can do its job and release the memory?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
等等，是 WPF 还是 Silverlight？在这种情况下，它们非常不同，我的答案也会不同。
WPF 解决方案
在 WPF 中，我将为每个表单创建一个 ObjectContext。这样，上下文的持续时间就与表单本身一样长。然后，您应该实现一个事件系统，以便当您保存对实体的更改时，您可以提醒其他表单它们可能需要刷新数据（INotifyPropertyChanged）。 Oren Eini 在 MSDN 杂志上使用 NHibernate 写了一篇关于此架构的非常好的文章。你应该能够从他的文章中获得架构概念。
Silverlight 解决方案
现在，Silverlight 不同了。 Silverlight 本质上只允许您的应用程序中有一种表单。是的，您可以使用一些技巧将表单的根视觉导航到不同的“页面”，但它仍然只是一种表单，并且用户无法在一个 Silverlight RIA 中打开多个窗口。因此，我将为每个 Silverlight RIA 实例创建一个 .Net RIA Services ObjectContext。请记住，RIA 服务并不是与数据库的实际连接，它只是链接到 Web 服务的缓存和更改跟踪对象。因此，让该对象存在较长时间是完全可以接受的，因为它不会占用任何服务器资源。如果您的 Silverlight RIA 打开多个浏览器窗口或具有多个 Silverlight 对象，则每个 Silverlight 实例都应该有一个 ObjectContext。
在服务器上，您在 Web 服务中使用实体框架 ObjectContext，它应该仅在一个请求的持续时间内有效。您的服务越无状态，它们的可扩展性和性能就越高。您希望尽快打开 EF ObjectContext、使用它并关闭它。
编辑：
如果您想要做的只是从对象上下文中分离对象，那么您只需使用
context.Detach(entity)方法。您可以找到如何执行此操作的示例在 MSDN 上。Wait, is it WPF or Silverlight? In this case, they are very different and my answer would be different.
WPF Solution
In WPF I would create a single ObjectContext per form. This way, the context will only last as long as the form itself. You should then implement an event system so that when you save changes to an entity you can alert the other forms that they may need to refresh their data (INotifyPropertyChanged, for example). Oren Eini wrote a pretty good article on this architecture using NHibernate in MSDN magazine. You should be able to get the architecture concept from his article.
Silverlight Solution
Now, Silverlight is different. Silverlight essentially only allows you to have one form in your application. Yes, there are some tricks you can do to navigate the root visual of the form to different "pages" but it is still only one form and the user can't open multiple windows in one Silverlight RIA. Because of this, I would make one .Net RIA Services ObjectContext per Silverlight RIA instance. Remember, RIA Services is not an actual connection to your database, it is just a caching and change tracking object linked to a web service. So, it is perfectly acceptable to leave this object in existance for longer periods of time because it is not tying up any server resources. If your Silverlight RIA opens multiple browser windows or has more than one Silverlight object, then you should have one ObjectContext per Silverlight instance.
On the server, you use an Entity Framework ObjectContext in the web service and it should only live for the duration of one request. The more stateless you can make your services, the more scalable and performant they will be. You want to open your EF ObjectContext, use it, and close it as soon as possible.
EDIT:
If all you are wanting to do is detach an object from the object context, then you can just use the
context.Detach(entity)method. You can find an example of how to do this on MSDN.您可以使用存储库模式。 UI 和 DAL 之间的附加抽象层。
使存储库中的数据集合静态且可观察。然后，每当存储库更新其中任何一个时，UI 层都应该跟上。只是一个想法。
You could use repository pattern. An additional layer of abstraction between UI and DAL.
Make Data collections in repository static and observable. Then whenever repository updates any of them, UI layer should catch up. JUst an idea.
在 ObjectContext 中使用 ObservableCollections。使用在 NotifyPropertyChange 上触发的事件。在视图模型之间使用发布/订阅模式来通知它们更改并使用它来更新其他视图。
Use ObservableCollections in the ObjectContext. Use an event that triggers on NotifyPropertyChange. Use a publish/subscribe pattern between the view models to inform them of the change and use this to update the other views.
在我们的例子中，我们决定实现一个工厂模式，并在需要时实例化一个新的对象上下文（有时它不会一对一地映射到虚拟机）。
关于对象上下文生命周期的一篇很棒的文章：
http ://www.silverlightshow.net/items/Silverlight-WCF-RIA-Services-strategies-for-handling-your-Domain-Context-part-one.aspx
In our case we have decide to implement a factory pattern and instantiate a new object context whenever we need it (sometimes it does not map one to one to a VM).
Agreat article about object context life time:
http://www.silverlightshow.net/items/Silverlight-WCF-RIA-Services-strategies-for-handling-your-Domain-Context-part-one.aspx