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

Question

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

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

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

谢谢

Answer 1

这只是一个选择问题。

EFv4 与设计师

优点:

您拥有设计器支持和 T4 模板，它将为您生成实体 = RAD。

您拥有非常大的功能集，包括对 View 、存储过程映射和一些自定义模型定义对象(如 QueryView 或模型定义函数)的支持。

需要时支持其他 EF 类型(自我跟踪实体、实体对象)。

缺点:

Designer 对于大模型(50+ 表)不是很好的工具

并非设计器支持所有功能 - 您必须以 XML 格式访问 EDMX

EDMX XML 结构可能是所有可用 .NET ORM 工具中最复杂和最难理解的描述

与设计师在共享环境中工作只是一种痛苦——最好在 EDMX 上使用独占锁

编辑:我忘记了我很受欢迎的缺点。 Designer 在 EDMX 中存储所有映射数据以及它自己的关于在图表中定位实体的数据。即使像缩放图表这样愚蠢的操作也会从源代码管理中检查 EDMX 文件。

EF代码优先

优点:

能够在代码中定义所有内容

基于属性的映射和 Fluent API

一些非常好的 API 特性——约定、本地等。

我认为这个 API 不那么复杂，更容易使用

缺点:

它还不是最终版本。当前版本仅为社区技术预览版 5。

因为那个 API 可以在最终版本中改变。

您必须自己编写所有代码。

与“大”EF 相比，功能集是有限的。

没有文档，目前您必须在博客中查找信息。

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