为什么POCO's相对于EF4、nhibernate是一件好事?

本文关键字：一件 nhibernate POCO EF4 相对于为什么 | 更新日期: 2023-09-27 18:11:59

为什么在EF4、Linq2SQL或任何其他数据映射技术中支持POCO如此重要?我理解面向对象意义上的POCO的概念，但是当涉及到ORM时，我还遗漏了什么吗?

编辑:我只是在ORM的上下文中添加我个人的对POCO的定义:它是一个由开发人员手工编码的类，而不是由ORM映射工具(如Visual Studio的EF4设计器)生成、增强或注释的类。
如果我错了，请纠正我。

"POCO"意味着框架没有对实体对象施加不必要的或违反直觉的约束——不需要使用代码生成器，不需要扩展框架提供的基类，不需要对属性进行广泛的注释，或者在大多数情况下，编写与始终存储在内存中的类不同的代码。这样可以将数据持久化到模型类之外，并减少认知开销。

比较NHibernate或EF Code First的POCO定义与Visual Studio为EF不使用Code First生成的代码，然后问自己你更喜欢阅读和维护哪一个。

通常您不希望您的代码依赖于某种ORM技术。poco将这种依赖最小化。这只是一般解耦原理的一个化身。

实体框架允许您一起使用自定义数据类使用您的数据模型，而无需对数据进行任何修改类本身。

这意味着您可以对数据模型使用"普通的"CLR对象(POCO)，例如现有的域对象。这些映射到数据模型中定义的实体的POCO数据类，支持大多数与实体数据模型工具生成的实体类型相同的查询、插入、更新和删除行为。