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