Code First Existing Database与EF Designer to Existing Database的对比

Question

我们正在启动一个新的大型企业项目。数据库将包含100多个表格，并且我们将使用Entity Framework、Web API和MVC。

我的问题与解决方案的Entity Framework方面有关。我正在尝试在以下两者之间做出选择：

1.使用现有数据库的代码优先

2.使用现有数据库的EF设计器（数据库优先）

我知道我们可以使用EF从代码优先或EF设计器生成数据库，但我们更喜欢对数据库拥有完全控制，并以传统方式开发，因此我们排除了允许我们自动生成数据库的EF选项。

我在互联网上找到的大部分与代码优先相关的内容都是关于创建新数据库，然后使用代码迁移。当讨论数据库优先时，讨论更倾向于EF设计器。例如：代码优先 vs 模型/数据库优先 我更喜欢选择将代码优先到现有数据库的组合。

以下是我偏爱此选项的考虑因素，我想知道是否还有其他需要考虑的因素，以及我的假设/想法是否正确。

代码优先到现有数据库

• 一开始需要构造大量的类，但我们可以通过EF Model Wizard进行初始生成。
• 然后可以修改这些类的任何自定义属性或删除不需要的内容，而不需要使用EF Designer扩展任何类。
• 缺点是对数据库的任何更改都必须手动添加到我们的类中，而不像使用设计器那样可以轻松更新。

编辑： 我想在这个领域我有些困惑。从阅读中得知，正确的Data First方法是为所有自动生成的类创建partial classes，然后将任何修改作为“业务”层的一部分进行。 因此，我的想法已经从支持Code First from Database转变为使用EF Designer到现有数据库，然后创建partial classes。

- Chris H

Answer 1

无论如何，您都需要同步实体数据模型（EDM）和数据库。您必须确保EDM与您的数据库完全兼容。如果不兼容，无论是Code First还是使用模型，它都将失败。

唯一的区别在于：

- 使用设计器，您可以以图形方式轻松设置属性、列名等。 - 使用Code First，您必须使用约定、Fluent API或属性设置这些属性、列名、数据类型等。

使用Code First的唯一优点是，一旦您已经同步了Code First模型（参见“Code First也是EDM，但功能有限”）和数据库，您就可以开始使用迁移，并使用它们来演化您的模型，这使得在发布新版本时更容易应用更改到生产数据库中。使用图形模型，您不能使用迁移，并且必须直接从Visual Studio升级Db，或手动创建SQL DDL脚本。

Code First也是EDM，但缺少一些功能。

无论您使用Code First还是绘制模型，都将生成一个EDM（实体数据模型）。如果您习惯设计数据库，可能会更喜欢使用设计器。请注意下面关于EF Core（前身为EF7）的注释！

然而，Code First生成的EDM有一些设计器没有的限制。

Code First最显著的限制是，在设计器中，您可以轻松地从BD映射用户定义的函数，例如标量和表值函数以及存储过程。但是在Code First中，有更多的限制。

在EF 6.1中，大部分这些限制都消失了，但是进行映射仍然有点困难。（事实上，截至今天，2014年，只有一个示例和一个简单的Nuget包来说明如何做到这一点。）

截至2017年3月，非Core EF，即EF 6.1，不再更新。如果出现错误，MS可能会解决它们，（这是错误的：但不要期望进一步的更改）

新功能在6.2中出现: EF 6.2有什么新功能, 包括使用Fluent API定义索引、支持Like, 支持非标识DB生成的键，如SEQUENCE和一些其他更改。

EF Core的变化，前身为EF7（截至2015年5月）

目前微软正在开发EF 7，但同时也在维护EF 6.x。当前建议是继续使用EF 6一段时间，因为EF 7还不够成熟。

EF 7从头开始开发，以克服继承的ObjectContext，后者对于实现新功能存在极大限制。但它实现了最广泛使用的DbContext，并进行了少量更改。因此，如果您使用DbContext，则可以轻松迁移到即将推出的新版本EF。

然而，有一个非常重要的变化：在EF Core（前身为EF7）中，EDM模型消失了，取而代之的是Code First模型。因此，如果您想使用今天的技术并确保轻松升级到新版本，请不要使用Model First或Database First：请使用Code First。微软有重要的理由做出这个决定：Code First在团队环境中的工作效果更好，并允许使用迁移。无论如何，您仍然可以以图形方式查看模型（使用Power Toools），或使用第三方工具使用设计师创建模型（当前商业解决方案中的几个将支持EF7）。

注意：为什么Code First在团队环境中更好？如果几个团队成员修改模型，则在几个代码文件中合并更改比在大型XML文件中进行更容易，该文件具有定义模型的许多行。在这个庞大的XML文件中理解版本之间的更改也更加困难。对于中大型项目，我建议您尽快转向Code First。

- JotaBe

---

谢谢，这提供了一些细节，让我进一步调查。我对迁移的理解是，它们用于从代码优先模型更新数据库，这正确吗？我的偏好是始终从 SQL Server 中编写与数据库相关的任何内容，并为此创建更新脚本等。目的是 C# 代码将始终在以后进行修改以反映数据库更改。我知道这似乎与 Code First 的观点相反，但我希望避免自动生成的类。 - Chris H