具有实体框架3.5和MVVM的存储库模式 - 我应该在任何地方共享相同的上下文吗?

c# entity-framework mvvm repository-pattern wpf

我正在开发一个数据库文件系统 。我在用 -

  1. .Net框架3.5
  2. 实体框架3.5
  3. WPF与MVVM模式

该项目跨越多个使用相同模型的程序集。

一个程序集,我们称之为“服务器”,只使用EF(即相同的模型)将数据添加到数据库。其他程序集(包括UI)都读取和写入数据。服务器所做的更改应立即反映在其他程序集中。

数据库包含自引用表,其中每个实体可以具有单个OR或不具有父级和(可能是)某些子级。我想使用存储库模式,它也可以提供一些机制来处理这种分层性质。

我已经在Code Project上阅读了这篇文章。它在任何地方共享相同的上下文(实体)。

我的问题是 - 我应该在各地分享相同的背景吗?这样做的优点和缺点是什么?

一般承认的答案

WPF应用程序框架(WAF)的BookLibrary示例显示了如何一起使用WPF MVVM和实体框架。它将层分成单独的组件。

也许这就是你要找的东西。


热门答案

根据我的理解,应该在需要时使用objectcontext然后扔掉。因此,您可能希望将其包含在一个工作界面单元中,以及一个工作单元工作区,以便在需要时创建工作单元。

至于你关于反映“集会”变化的实体的问题。事情是你的对象不存在于程序集中。它们存在于记忆中。

因此,为了在应用程序中反映更改,您必须在整个应用程序中维护对同一对象的引用。或者您可以实现通知系统,以便在更改实体或实体集合时,应用程序的另一端会注意并刷新数据。

保持单个上下文存活的缺点是,每次对对象上下文进行查询时,它都会随着从db加载的实体而增长。在长时间运行的应用程序中,这会转化为大量内存消耗。

每次使用全新上下文的缺点是对repo的任何调用都会为您提供新的数据副本。现在这应该不是问题,因为回购的唯一关注应该是保存/加载数据;不处理跨层的并发或数据重复



许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因
许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因