为什么 POCO 对 EF4、nHiberate 来说是件好事答案

【问题标题】：Why are POCO's a good thing in relation to EF4, nHiberate为什么 POCO 对 EF4、nHiberate 来说是件好事
【发布时间】：2011-12-13 08:56:20
【问题描述】：

为什么在 EF4、Linq2SQL 或任何其他数据映射技术中支持 POCO 如此重要？我理解 OO 意义上的 POCO 的概念，但是在 ORM 方面我还缺少什么吗？

编辑：我只是在 ORM 的上下文中添加我个人的POCO 定义：它是由开发人员手动编码的类，而不是由 ORM 映射工具（如 Visual Studio 的 EF4 设计器）生成、扩充或注释的类。

如果我错了，请纠正我。

【问题讨论】：

【解决方案1】：

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

将来自 NHibernate 或 EF Code First 的 POCO 定义与 Visual Studio 为没有 Code First 的 EF 生成的代码进行比较，然后问问自己你更喜欢阅读和维护哪一个。（例如，在探索新的代码库时。）

【讨论】：

好点。在解耦/可维护的方式和快速/代码生成的方式之间是否有权衡？
在 EF-CF 中，通常希望您遵守几个最合理的约定，以便它“自动”工作。如果您需要对事物进行更多控制，则必须研究正确的注释以覆盖这些约定。使用代码生成时，您正在与可视化设计师一起工作，“属性”面板将一目了然地向您展示您可以自定义的内容，而不必再翻阅文档并将混乱重新引入非非常简单的 COS 中.

【解决方案2】：

通常您不希望您的代码依赖于某种 ORM 技术。 POCO 最大限度地减少了这种依赖性。这只是解耦一般原则的一种体现。

【讨论】：

【解决方案3】：

实体框架使您能够一起使用自定义数据类使用您的数据模型而不对数据进行任何修改类本身。

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

【讨论】：

那么说 EF 支持 POCO 是真的吗？
是的，如果您使用实体框架的“代码优先”化身，实体框架支持 POCO。
@StriplingWarrior 实体框架在当前代码首次发布之前支持 POCO。我什至会说，就 POCO 而言，使用 EF 代码优先而不是 EF 模型优先不会带来很多好处。两者同样可行。但是，如果您喜欢 RAD，请完全忘记纯粹的 POCO……它们在 EF 中需要大量额外的工作和耐心。