EF POCO代码与仅使用实体数据模型的EF POCO代码的区别

Question

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

有两种使用基于POCO的EF方法： 1.使用实体设计器 2.仅使用代码

使用哪种方法最好，EF Poco Code First还是使用实体数据模型设计器的EF Poco？

谢谢

- oliver.sakkam

---

[OT] 你也可以使用NHibernate，这样就不用做出折衷了 :-) - Diego Mijelshon

@Diego：只是好奇——你到底意味着什么？就我所记得的，nHibernate允许在xml中定义映射，也可以在代码中（fluent nHibernate）中进行定义——基本上和EF中的选项一样。那么你提到要避免什么取舍？ - Yakimych

@Yakimych：使用NHibernate，您选择的映射方法和工具不会限制可用功能。 - Diego Mijelshon

@Diego：不幸的是，有时你必须应对愚蠢的公司政策，比如说：不能使用NHibernate，不能使用开源等等。 - Ladislav Mrnka

@LadislavMrnka：总是有 http://careers.stackoverflow.com :-) - Diego Mijelshon

Answer 1

这只是一个选择问题。

使用带设计器的EFv4

优点:

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

缺点:

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

使用EF Code First

优点:

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

缺点:

• 它还没有最终发布。目前发布的只是社区技术预览版5。
• 因此，API可能会在最终发布时更改。
• 您必须自己编写所有代码。
• 与“大”EF相比，功能集有限。
• 当前没有文档，您将不得不在博客中寻找信息。

目前我正在使用第一种方法。最终发布后，我可能会更喜欢Code First。

- Ladislav Mrnka

---

你提到的所有要点都很全面。我只想在“不太适合大型模型”这个评论中再加一些分量。50张表并不算是一个庞大的模型，但绝对正确的是当表数量增长到50以上时会引发严重问题。尤其在多人开发环境中更是一场噩梦。虽然ctp5存在一些缺点，但我已经开始使用它了，因为我猜想开发团队会在我之前完成ctp5开发，并且目前的共识是ctp5将是最终版本。 - Ralph Shillington