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

Question

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

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

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

谢谢

Answer 1

这只是一个选择问题。

EFv4 与设计师

优点：

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

缺点：

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

EF代码优先

优点：

• 能够在代码中定义一切
• 基于属性的映射和 Fluent API
• 一些非常好的 API 特性——约定、本地等。
• 我认为这个 API 不那么复杂，更容易使用

缺点：

• 它还不是最终版本。当前版本仅为社区技术预览版 5。
• 因为那个 API 可以在最终版本中改变。
• 您必须自己编写所有代码。
• 与“大”EF 相比，功能集是有限的。
• 没有文档，目前您必须在博客中查找信息。

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