【发布时间】:2010-12-11 10:52:25
【问题描述】:
我在实体框架中阅读了一些关于 POCO 的文章,但仍然不明白我可以用它做什么。 POCO 如何使我的项目受益?
【问题讨论】:
-
POCO 或多或少只是一个简单的类,用于反映数据库中的数据,换句话说,它是一个 DC(数据容器)
标签: c# entity-framework poco
我在实体框架中阅读了一些关于 POCO 的文章,但仍然不明白我可以用它做什么。 POCO 如何使我的项目受益?
【问题讨论】:
标签: c# entity-framework poco
POCO 只是一个普通类,没有添加接口或基类以使其与您的数据库层一起工作(在此上下文中)。
优点是: 1) 不依赖于特定的数据库层,因此您可以将其换成更好的(即 NHibernate),而无需修改数据库层以外的任何内容。
2) 它可以更轻松地对您的类进行单元测试。
3) 没有样板代码来通知属性何时发生更改等。只是普通的 getter 和 setter。
理想情况下,您的域对象是从 ORM 加载的,而该对象不必对如何加载、如何跟踪更改或如何保存等有任何发言权。
NHibernate 在这方面做得非常好,唯一的要求是您必须使所有属性/方法虚拟化,这比任何硬依赖都要好得多。
【讨论】:
“Plain Old Clr Object”的 POCO 标准。它指的是一种 ORM 架构风格,其中从数据存储中持久化和加载数据的所有工作都由系统完成,而对象本身并不知道发生了什么。这意味着 ORM 可以完全支持 plain 对象,这些对象没有在考虑 ORM 的情况下以任何方式进行修改。支持 POCO 持久性的 ORM 不需要您让您的类从任何特定的基类继承,实现任何接口,甚至使用任何属性标记方法。
与此完全相反(有时称为数据访问对象 - 或 DAO)是,当所有存储都由对象本身处理时,它确切地知道如何序列化和存储自己以及如何在需要时加载自己。在这种情况下,对象应纯粹用于传输数据,不应代表系统的任何业务逻辑。
实际上,这更像是这两种情况的频谱。许多 ORM 处于中间位置,需要在类外部处理持久性,但通常还需要在被持久化的类上实现一些元数据或接口以帮助解决问题。
EF (v1) 不支持 POCO。对象必须实现各种接口(以提供属性值更改等的通知)才能被框架持久化。我相信有addon frameworks 试图将 POCO 支持添加到 EF,但我不知道他们有多成功。 EF in .net 4.0 将支持 POCO。
POCO 通常被认为是好的,因为它允许高度分离关注点。您可以将数据对象定义为对将用于存储它们的机制的知识绝对为零。 (因此,将来可以很容易地为不同的东西切换存储机制)。这也意味着您不必在设计数据对象时考虑用于存储它们的数据库/框架。
【讨论】:
POCO 是设计用于在应用程序中传输数据的类(即将数据从数据层移动到 ui 层)。它们还将应用程序的结构与数据库的模式分离。
对于小型项目,这没什么大不了的,但随着项目的发展,对象模型(您如何设计 POCO)往往会偏离数据库模式。
.Net 中通常使用的其他方法是 DataTables 和 DataSets。通常使用列名检索数据。这使您在数据库中执行列名。如果数据库中的列名发生更改,您的代码就会中断。
【讨论】:
POCO 只是“普通的旧 CLR 对象”。它只是一个标准类,任何标准类。
在 EF 方面,人们指的是能够配置 EF 以将您自己的类(不是由 EF 直接生成)存储到数据库中。
【讨论】: