实体框架 4.0：为什么要使用代码生成的实体对象而不是 POCO 对象？答案

【问题标题】：Entity Framework 4.0: Why Would One Use the Code Generated EntityObjects Over POCO Objects?实体框架 4.0：为什么要使用代码生成的实体对象而不是 POCO 对象？
【发布时间】：2010-01-13 12:11:19
【问题描述】：

除了更快的开发时间（据我所知，Visual Studio 2010 beta 2 没有用于构建 POCO 实体对象的 T4 模板），默认情况下使用 Entity Framework 创建的传统 EntityObject 实体有什么优势吗？如果 Microsoft 提供了用于构建 POCO 对象的 T4 模板，我正试图弄清楚为什么有人会想要使用传统方法。

【问题讨论】：

标签： entity-framework entity-framework-4

【解决方案1】：

你似乎同时问了两个问题。纯代码与模型优先和EntityObject 父类型与任意父类型。无论父类型如何，您都可以通过模型优先获得设计师支持。除了设计器支持之外，您还可以使用模型优先的预编译视图。这可以显着提高性能。

拥有EntityObject 作为父级可能比所谓的“POCO”（通常是代理库，而不是“普通”对象）更有优势，因为您的实体的运行时类型是您期望的确切类型，而不是而不是运行时生成的子类型。

此外，与其他对 LINQ 支持极少甚至没有的 ORM 不同，Entity Framework 具有丰富的 LINQ 支持，允许您将project 应用于 real POCO 类型。因此，无需关心实体的基本类型是什么，就可以构建真正的持久性无知的演示文稿。您不会被 ORM 黑盒中的任何类型所困扰。

EntityObject 允许将私有属性持久化到数据库中。使用代理类型要求这些属性至少受到保护并且必须是虚拟的。因此，EntityObject 可能允许更好的封装。

顺便说一句，我并不是要暗示使用代理没有任何好处。我只是想回答你关于EntityObject 的优势是什么的问题。

【讨论】：

【解决方案2】：

我认为唯一的好处是设计师的支持。找不到使用非 poco 实体的任何其他好处。

【讨论】：

好点。我想，如果创建了模板，微软就能够添加从设计器修改 POCO 实体的能力。