我已经在实体框架中阅读了一些关于POCO的文章，但仍然不明白我能用它做什么。 POCO如何使我的项目受益？
答案 0 :(得分：21)
“普通旧Clr对象”的POCO标准。它指的是一种ORM体系结构，其中所有用于从数据存储中持久化和加载数据的工作都是由系统完成的，而对象本身知道发生了什么。这意味着ORM可以完全支持普通对象，这些对象在使用ORM时未以任何方式进行修改。支持POCO持久性的ORM不要求您让您的类继承任何特定的基础，实现任何接口，甚至标记具有任何属性的方法。
与此完全相反（有时称为数据访问对象 - 或DAO）是指对象本身处理所有存储时，它确切地知道如何序列化和存储自身以及如何在需要时加载自身。在这种情况下，对象应该纯粹用于传输数据，不应该代表系统的任何业务逻辑。
实际上，这更像是两种情况的两种情况。许多ORM位于中间的某个位置，需要在类外部处理持久性，但通常还需要在持久化的类上实现一些元数据或接口以帮助解决问题。
EF（v1）不支持POCO。对象必须实现各种接口（以提供属性值更改的通知等），以便框架可以持久化。我相信有addon frameworks试图为EF添加POCO支持，但我不知道它们有多成功。 EF in .net 4.0将获得POCO支持。
POCO通常被认为是好的，因为它可以强烈分离关注点。您可以定义数据对象，使其完全不了解将用于存储它们的机制。 （因此，它可以很容易地为将来不同的东西切换存储机制）。这也意味着您不必考虑用于存储数据对象的数据库/框架来设计数据对象。
答案 1 :(得分：5)
POCO只是“普通的旧CLR对象”。它只是一个标准类，任何标准类。
就EF而言，人们指的是能够配置EF以将您自己的类（不是由EF直接生成）存储到数据库中。
答案 2 :(得分：1)
POCO只是一个普通的类，没有添加接口或基类来使它适用于您的数据库层（在此上下文中）。
优点是： 1）没有依赖于特定的数据库层，因此您可以将其换成更好的数据库（即NHibernate），而无需修改除数据库层之外的任何内容。
2）它可以更容易地对你的班级进行单元测试。
3）没有锅炉板代码在房产变更时通知等，只是普通的吸气剂和设定者。
理想情况下，您的域对象是从ORM加载的，没有该对象必须对其加载方式，跟踪更改方式或保存方式等有任何说法。
NHibernate在这方面表现非常出色，唯一的要求是你必须使所有的属性/方法都是虚拟的，这比任何硬依赖都要好得多。
答案 3 :(得分：-5)
POCO是用于在应用程序内传输数据的类（即将数据从数据层移动到ui层）。它们还将应用程序的结构与数据库的模式分离。
在小项目上这不是什么大问题，但随着项目的发展，对象模型（如何设计POCO）往往会偏离数据库模式。
.Net中通常使用的其他方法是DataTables和DataSet。通常，使用列名称检索数据。这会使您在数据库中执行列名称。如果列名在数据库中发生更改，则代码会中断。