仅 EF POCO 代码 VS 带有实体数据模型的 EF POCO

Question

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

在 EF 中使用 poco 有 2 种类型 1.使用实体设计器 2.仅使用代码

EF poco code first 或 EF Poco 使用实体数据模型设计器的最佳方法是哪一个？

谢谢

Answer 1

这只是一个选择问题。

EFv4 与设计师

优点：

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

缺点：

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

EF 代码优先

优点：

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

缺点：

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

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