我想到的一个优点是，如果你使用Poco类进行Orm映射，如果两者都支持Poco，你可以轻松地从一个ORM切换到另一个ORM。
拥有没有Poco支持的ORM，例如使用像DataObjects.Net Orm这样的属性进行映射，对我来说不是问题，对于Poco支持的Orms及其生成的代理实体，你必须要知道实体实际上是绑定到某些上下文/会话的DAO对象，例如序列化是一个问题，等等。
答案 0 :(得分：19)
POCO是松散耦合和可测试性的全部。
因此，当您进行POCO时，您可以单独测试您的域模型（例如，如果您正在进行DDD）。您不必担心它是如何持久存在的。您不需要存储上下文/会话来测试您的域。
另一个优点是泄漏抽象较少。因为持久性问题不会被推送到域层。所以你正在执行SRP原则。
我可以看到的第三个优势是，对您的域模型进行POCO更具有进化性和灵活性。与连接到持久性的功能相比，您可以更轻松地添加新功能。
我在使用DDD时使用POCO，但是对于某种应用程序，您不需要执行DDD（如果您正在执行基于小数据的应用程序），那么问题就不一样了。
希望这有帮助
答案 1 :(得分：13)
答案 2 :(得分：8)
在Single Responsibility Principle之后，ORM中的POCO支持就是关注点的分离。通过POCO支持，ORM可以直接与域模型通信，而无需使用特定于数据访问的代码“混淆”域。这可确保域模型仅用于解决与域相关的问题，而不是数据访问问题。
除此之外，POCO支持可以更容易地单独测试对象的行为，而无需数据库，映射信息甚至是对ORM程序集的引用。拥有“独立”对象的能力可以使开发变得更加容易，因为对象很容易实例化并且易于预测。
此外，由于POCO对象未绑定到数据源，因此无论是从主数据库，备用数据库，平面文件还是任何其他进程加载，都可以将它们视为相同。虽然这似乎不会立即有益，但无论来源如何对待对象都可以使行为易于预测和使用。
我为最近的ORM选择了NHibernate，因为它支持POCO对象，它处理得非常好。它适合项目遵循的领域驱动设计方法，并使数据库和域之间实现了很好的分离。
能够切换ORM工具并不是POCO支持的真正理由。尽管您的类可能与ORM没有任何直接依赖关系，但它们的行为和形状将受到ORM工具及其映射到的数据库的限制。更改ORM与更改数据库提供程序一样重要。一个ORM中总会有一些功能在另一个ORM中不可用，您的域类将反映功能的可用性或缺失。
在NHibernate中，您需要将所有public或protected类成员标记为virtual以启用对延迟加载的支持。这种限制虽然没有显着改变我的域层，但 对其设计产生了影响。