实体应该持续无知吗？（这是一个关于IT技术的问题标题）

Question

一个实体是否应该是持久性无知的？微软的ADO.NET Entity Framework呢？它是否是持久性无知的？

- Bastien Vandamme

---

“应该”？这要看你使用的框架是什么。EF使用POCO，这意味着它们是持久性无知的。 - Brad Christie

你有没有在发布之前至少试着阅读一遍文档？Entity Framework文档中已经非常清楚地说明了这一点。 - TomTom

是的，这就是我提出问题的原因。我对这里的答案更感兴趣，而不是文档：人们所说的“持久无知”到底是什么意思。他们不知道自己是如何被存储的，但他们是否不知道自己可以被存储？ - Bastien Vandamme

Answer 1

Entity Framework支持持久性无知和持久性感知实体。

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

在EF中，对于持久性无知还是持久性感知的决定是关于更改跟踪的问题，即如何检测正在发生的实体更改并决定需要采取哪些操作将其持久化到数据库。 EF有三种主要的更改跟踪方法

• 快照跟踪（实体完全持久性无知）
• POCO代理更改跟踪（实体表面上看起来是持久性无知，但在幕后是持久性感知的）
• 自跟踪实体（STE）现已弃用（实体持久性感知）

持久性无知是关于允许我们描述实体外观而不显式推断它们映射到数据库表的方式。这意味着我们与特定的数据库实现联系不那么紧密。但是，持久性无知具有一些关于如何有效地与数据库通信的权衡。

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

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

EF团队在快照更改跟踪器方面做得非常出色，使我们能够拥有完全的持久性无知实体。这在小上下文中表现非常好（我们每次跟踪少于1k个对象），但在这种情况下可能不适合我们的用法，他们提供了备选的跟踪方法。

即使使用纯POCO实体和快照跟踪，根据我们是否决定使用属性装饰或模型构建器来配置映射到SQL表的确切细节，我们也具有不同级别的持久性无知。这是我支持使用模型构建器而不是属性装饰的主要原因之一。

回答您的标题问题“实体应该是持久性无知的吗？”我的意见是理想情况下是，但只有在实际上有意义的情况下才是。

- undefined

Answer 2

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

- phil soady

Answer 3

一般来说，实体对象应该是简单的数据容器。它们不应关心数据来自哪里、如何获取或去向何方，它们的工作就是作为相关数据点的容器（如果您愿意，可以称之为记录）。通常有其他对象（数据访问对象）负责获取数据并用它填充实体对象，或者将实体对象保存到数据存储中。

- Kevin