我们正在启动一个新的大型企业项目。该数据库将是100多个表，我们将使用实体框架，Web API和MVC。
我的问题与解决方案的实体框架方面有关。 我想在以下几点之间做出选择：
我知道我们可以使用EF首先从代码生成数据库或从EF设计器生成数据库，但我们更喜欢完全控制数据库并以传统方式开发，因此我们排除了允许我们使用的EF选项自动生成数据库。
我在互联网上找到的与Code First相关的大部分内容都涉及创建新数据库，然后使用代码迁移。当讨论首先讨论数据库时，讨论会支持EF Designer。示例：Code-first vs Model/Database-first
我的首选是将Code First与现有数据库结合使用。
以下是我支持此选项的考虑因素，我想知道是否还需要考虑其他事项，以及我的假设/想法是否正确。
首先编码现有数据库
编辑： 我想我在这方面很困惑。从阅读开始，看来Data First的正确方法是为所有自动生成的类创建部分类，然后作为“业务”层的一部分对部分类进行任何修改。 因此，我的想法已经从支持Code First从数据库转变为使用EF Designer到现有数据库，然后创建了部分类。
答案 0 :(得分：22)
在任何情况下，您都必须同步EDM（实体数据模型）和数据库。您必须确保EDM与您的数据库完全兼容。如果没有，它将失败，无论它是Code First还是你使用模型。
唯一的区别是：
使用Code First，唯一的优势是，一旦您同步了Code First模型（请参阅＆＃34; Code First也是EDM，但有些限制＆＃34;）和数据库，您可以开始使用迁移，并使用它们演化您的模型，以后可以更轻松地将更改应用于生产数据库（无论何时发布新版本）。使用图形模型，您无法使用迁移，必须直接从Visual Studio升级Db，或手动创建SQL DDL脚本。
如果您使用Code First或绘制模型，则无关紧要，将生成EDM（实体数据模型）。如果您习惯于设计数据库，那么使用设计师可能会更舒服。 请注意以下EF Core（前EF7）的注意事项！。
然而，Code First生成的EDM有一些设计师没有的限制。
Code First最突出的限制是，在设计器中，您可以轻松地从BD映射用户定义的函数，例如标量和表值函数以及存储过程。使用Code First还有更多限制。
在EF 6.1中，大部分限制都消失了，但制作映射仍然有点困难。（事实上，截至2014年，there's only a sample和a simple Nuget package怎么做。）。截至2017年3月，非核心EF，即EF 6.1，不再更新。如果出现错误，MS可能会解决错误（这是错误的：但不要期待进一步的改变）
新功能出现在6.2：What's new in EF 6.2中，其中包括使用Fluent API定义索引，支持Like，支持非身份数据库生成的密钥，例如SEQUENCE和其他一些变化
此时微软正在开发EF 7，但它也在维护EF 6.x.目前的建议是继续使用EF 6一段时间，因为EF 7还不够成熟。
EF 7正在从头开发，以克服继承的ObjectContext，这对实现新功能构成了可怕的限制。但它实现了最广泛使用的DbContext，几乎没有变化。因此，如果你使用DbContext，你将有一个简单的migraiton路径来传入新版本的EF。
然而，有一个非常重要的变化：EF Core（前EF7）中的 EDM模型有利于Code First模型。因此，如果您想使用当今的技术并确保轻松升级到新版本，请不要使用Model First或Database First：使用Code First。微软做出这一决定有很重要的原因：Code First在具有版本控制的团队环境中工作得更好，并允许使用迁移。无论如何，tou仍然可以以图形方式看到模型（使用Power Toools）或使用第三方工具使用设计器创建模型（当前的几种商业解决方案将支持EF7）。
注意：为什么在团队环境中Code First会更好？如果多个团队成员修改模型，那么合并多个代码文件中的更改要比在大型XML文件中更容易，其中包含许多定义模型的行。理解这个休闲XML文件中版本之间的变化也更加困难。对于中型或大型项目，我建议您尽快转到Code First