EF POCO代码仅VS EF POCO与实体数据模型

Question

将域对象与任何类型的持久性代码完全分离的能力使系统更具可扩展性和可维护性。当业务逻辑可以与存储代码分开测试时，测试变得更加容易。将POCO与实体框架（EF）一起使用肯定是朝着正确方向迈出的一步：）

有两种类型的使用poco与EF 1.使用实体设计师 2.仅使用代码

哪一个是最好的方法EF poco代码首先或EF Poco使用实体数据模型设计师？

感谢

Answer 1

这只是一个选择问题。

EFv4与设计师

优点：

• 您有设计师支持和T4模板，它将为您生成实体= RAD。
• 您有很大的功能集，包括对视图，存储过程映射的支持以及一些自定义模型定义的对象，如QueryView或模型定义的函数。
• 在需要时支持其他EF类型（自我跟踪实体，实体对象）。

缺点：

• 设计师不是很好的大型模型工具（50多个表）
• 设计器不支持所有功能 - 您必须以XML格式访问EDMX
• EDMX XML结构可能是所有可用的.NET ORM工具中最复杂且难以理解的描述
• 在设计师的共享环境中工作只是一件痛苦的事 - 最好在EDMX上使用独占锁
• 编辑：我忘记了我非常普遍的缺点。 Designer将所有映射数据与其自身关于图中定位实体的数据一起存储在EDMX中。即使像缩放图这样的愚蠢行为也会从源代码管理中检出EDMX文件。

首先是EF代码

优点：

• 能够在代码中定义所有内容
• 基于属性的映射和Fluent API
• 一些非常好的API功能 - 约定，本地等
• 我认为此API不太复杂且易于使用

缺点：

• 尚未发布最终版本。当前版本仅是社区技术预览5。
• 因为API可能会在最终版本中发生变化。
• 你必须自己编写所有代码。
• 与“大”EF相比，功能集有限。
• 没有文档，目前您必须在博客中查找信息。

目前我正在使用第一种方法。在最终发布之后，我可能会对代码更加满意。