3

一个实体应该是 Persitent 无知的吗？microsoft ADO.NET Entity Framorwok 呢？是执着无知吗？

4

3 回答 3

3

实体框架支持持久性无知和持久性感知实体。

以前的答案表明这是与您使用的生成模式有关，这在历史上是正确的（巧合），但现在不再如此，代码优先和数据库第一代模式都可以选择持久性感知（ish）或持久性无知。

在 EF 中支持或反对持久性无知的决定是更改跟踪的问题，即我们如何检测实体发生的更改并决定需要哪些操作才能将这些更改持久化到数据库中。EF 具有三种主要的变更跟踪方法

  • 快照跟踪（实体完全不了解持久性）
  • POCO 代理更改跟踪（实体似乎对持久性无知，但在幕后是持久性感知的）
  • 现在已弃用的自我跟踪实体 (STE)（实体具有持久性意识）

持久性无知是关于允许我们描述实体的外观，而无需明确推断它们映射到数据库表。这意味着我们与特定的数据库实现没有那么严格的联系。然而，对持久性的无知会在我们如何有效地与数据库通信方面进行一些权衡。

如果我们的实体完全不了解持久性，我们需要让我们的框架做更多的工作来了解它们何时更改以及更改对我们的数据库意味着什么。使用实体框架，这是通过存储上下文跟踪（看到）的所有实体的并排副本并执行差异来检测更改来实现的。

使用 POCO 代理，我们创建了原始实体的模拟扩展并监听特定属性的操作，因此我们可以更有效地跟踪更改。

EF 团队在快照更改跟踪器上做了非常了不起的工作，使我们能够拥有完全不了解持久性的实体。这在小型环境中表现得非常好（我们一次跟踪少于 1k 个对象），但在可能不适合我们使用的情况下，他们提供了替代跟踪方法。

即使使用纯 POCO 实体和快照跟踪，我们也有不同程度的持久性无知，这取决于我们是否决定使用属性修饰或模型构建器来配置我们映射到 SQL 表的确切细节。这是我非常喜欢使用模型构建器而不是属性装饰的关键原因之一。

回答您的标题问题“实体应该是持久的无知吗？” 我的意见理想上是肯定的，但仅限于实际上有意义的地方。

于 2012-12-22T00:38:10.913 回答
0

EF 与存储系统无关，是的。如果需要，您可以编写自己的提供程序。例如基于内存的存储模型。有一个 EF 期望的提供者模型。
http://msdn.microsoft.com/en-us/library/ee789835.aspx

于 2012-12-21T14:21:42.390 回答
0

一般来说，您的实体对象应该是简单的数据持有者。他们不应该关心数据来自哪里，如何获得，或者去哪里，他们的工作是作为一组相关数据点的容器（如果你愿意的话，一个记录）。通常还有其他对象（数据访问对象），它们的工作是获取数据并用它填充实体对象，或者获取实体对象并将其数据保存到数据存储中。

于 2012-12-21T14:42:32.650 回答