当所有代码更改都由 DBA 完成时，是否有替代使用 EF 的 Code First 迁移？答案

【问题标题】：Is there an alternative to Code First Migrations with EF when all code changes are done by a DBA?当所有代码更改都由 DBA 完成时，是否有替代使用 EF 的 Code First 迁移？
【发布时间】：2013-03-15 00:26:23
【问题描述】：

我已经阅读了有关 Code First Migrations 的信息，但它似乎并不真正适合企业。

我们有一个 DBA 来完成我们所有的数据库更改，我们不需要将这些更改放入类中并由应用程序执行数据库迁移。

如果我们更改我们的类和我们的 fluent API，然后让我们的 DBA 对数据库进行更改，那么我们如何同步到我们的 EF 模型？对于企业规模的应用程序，这通常是如何完成的？

【问题讨论】：

如果您更改类以反映数据库中的更改，则不需要迁移。
@NunoCarmo - 感谢您的反馈。那么您是说如果更改 100% 正确，那么它不会抱怨模型更改？如果有一些小的差异，有什么方法可以看到错误消息，或者 EF 会报告模型不再同步？

标签： entity-framework

【解决方案1】：

在我看来，这些其他答案似乎还不够。

您可以关闭 EF 初始化程序：

public ApplicationContext : DbContext
{
    public ApplicationContext()
        : base("ConnectionStringName")
    {
        Database.SetInitializer<ApplicationContext>(null);
    }

    // DbSets here
    public DbSet<Part> Parts {get; set;}

    // override OnModelCreating below ...
}

然后使用 Fluent API/数据注释，但是您通常会设置您的 POCO/模型以匹配现有数据库。

此博客的详细信息：http://cpratt.co/entity-framework-code-first-with-existing-database/

万一该网址将来无法使用 - 我的意思是：

在上面设置好初始化器后，配置你的 POCO 对应一个表：

public class Part
{
    public string PartID {get; set;}
    public string Description {get; set;}
    public decimal Weightlbs {get; set;}
    public decimal Price {get; set;}
}

然后通过在 Application Context 类中覆盖此方法将您的 POCO 映射到现有数据库表：

protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
    // Code First will assume a lot, but if you need to override things:

    modelBuilder.Entity<Part>().ToTable("db_PartTable");
    modelBuilder.Entity<Part>().Property(p => p.PartID) 
        .HasColumnName("Part_ID");
    modelBuilder.Entity<Part>().Property(p => p.Description)
        .HasMaxLength(100)
}

另一个很好的博客，由 Scott Guthrie 撰写：http://weblogs.asp.net/scottgu/using-ef-code-first-with-an-existing-database

【讨论】：

【解决方案2】：

即使我使用 EF 代码优先样式（与 EDMX 相对），我仍然在技术上使用数据库优先方法，因为我从不让 EF 为我生成数据库。相反，我创建类来为数据库建模。这听起来像你需要做的事情。

至于 DBA 改变的东西.. 你是否需要更新你的域实体类取决于 DBA 改变的是什么。例如，如果他将varchar(100) 的长度增加到varchar(200) 或类似的东西，那么该更改不应真正破坏您的代码（但仍然建议您更新代码以匹配此代码）。如果他正在删除或重命名某些列，那么您肯定需要更新您的域实体类，因为这显然会导致底层模型不同步的异常。

【讨论】：

您是否找到任何信息或知道 EF 如何检查数据库和类是否同步？例如，如果我向数据库中添加一个新表，但这与我的 DbContext 无关，该怎么办？会不会在建模型发现不同步的时候初始化就出问题了？
@Marilou，添加新表不会导致问题。问题在于更改现有映射。
@Marilou 为什么这不是公认的答案？您的问题看起来像是最接近的答案。如果您正在寻找能够自动不断地使用数据库监控您的手写 POCO 的东西......那么除了使用代码优先迁移或 edmx 之外，您将找不到它。确实 - 这些是你会使用的东西，但你似乎想要别的东西？

【解决方案3】：

回复有点晚了，但这里是：

如果您使用 Visual Studio 的 EF Power Tools 扩展，它使您能够执行 Rowan Miller 所说的“代码第二”。看看this article。

它可以让你指向一个现有的数据库，它会生成漂亮的 POCO 类并使用DbContext，就像你通过 Code First 完成的一样。不再有 ObjectContext 或 edmx 文件。流畅的配置也完全为你生成。

接下来，EF 团队将把这个功能加入到主要的 EF 工具中，这样您就不必下载 EF Power Tools 扩展。

【讨论】：

如果您指的是过时的 EF 电动工具（可能只是测试版），甚至可以添加到 VS 2015...不过，这只是一个工具，不会修复主要问题这个框架的问题，他们称之为 ORM ......使用同样的夸张我可以说“我的车库里有 2 辆法拉利”。顺便提一句。添加到EF和VS本身的功能远远超出了EF电动工具原本的威力……

【解决方案4】：

通常在这种情况下人们使用数据库优先方法。

当有人已经为您设计了数据库并且您可以通过几次点击生成或更新模型时，手动编写实体代码是没有意义的。当然，如果您的团队熟悉其他一些 ORM（其中它是主要方法）并且还不太熟悉 Entity Framework，或者如果您的团队非常小并且没有人可以编写 SQL 脚本，那么 Code First 可能会很方便，但是如果您有熟练的 DBA，为什么您需要 Code First？

【讨论】：

但是 Database First 方法不是创建 edmx 文件吗？是否有一种仅使用标准 POCO 的数据库优先方法以及我可以使用流式 API 的方法？
永远不会有 Fluent API for Database First。 Fluent API 和 edmx 文件都是为了描述代码和数据库之间的映射，但与 Fluent API 相反，这个 xml 文件可以通过 Visual Studio 中的向导生成，您不需要手动编写任何内容。至于 POCO，它们在 Database First 方法和 DbContext 中得到支持。
DbContext 方法是什么？那是“代码优先”的一部分吗？
一点也不。早期版本的 EF 只有 ObjectContext，但是当框架内部变得更加复杂时，EF 团队尝试在其周围添加简化的包装器并重新设计他们的代码，这个包装器就是 DbContext。该尝试失败了，现在他们尝试在 EF7 中从头开始重写所有内容，在稳定的 EF6 中，DbContext 是新项目的默认上下文类型，但如果您有从 EF4 迁移的旧项目，您仍然可以使用 ObjectContext。因为 DbContext 只是 ObjectContext 的包装，它们都支持 Code First、Model First 和 Database First。
这种方法没有受支持的未来。

【解决方案5】：

只是对此添加一些想法 - 看看这两个帖子（我不久前发布的）： https://stackoverflow.com/a/10164815/417747
https://stackoverflow.com/a/10255051/417747

简而言之，根据我的经验：

您无法在真正的企业规模数据库中轻松“维护”这样的解决方案。 “两个世界”迟早会发生碰撞，同步事情可能会很痛苦（尽管可行）
但是您不应该因此而放弃它。它非常适合快速启动并经过仔细规划，同步您可以使这项工作持续一段时间，
您可以转储脚本和/或调整迁移代码，调整“播种” - 取消一些更改（仍然有一些限制是痛苦的，我怀疑它会“模仿”DBA 可以做什么),
您可以跳过 CF 中的“生成”，一旦它走得太远（实际上很快，只要 DBA 接管）- 并且只需（使用脚本并在帖子中部分解释）确保您的 Db-s 匹配（真实和“代码”蓝图一）。这仍然意味着您已经设置了大部分表格等，并且您需要调整一些东西，
这是一个“经验法则”，在很多情况下 CF 是不合理的 - 所以只需将其用于原型设计，
对于您所描述的场景，一个好的“数据库生成器”可能是一个更好的解决方案（但它也有一些缺点），但我仍然没有看到两个世界的一个好的“组合”

希望这会有所帮助。

【讨论】：

【解决方案6】：

几天前我遇到了同样的问题，

旧数据库，__MigrationHistory 表是

在数据库中进行更改并在本地计算机上重新创建它

将当前创建数据库的 __MigrationHistory 表中的 ContextKey、Model 和 ProductVersion 添加到旧数据库的 __MigrationHistory 表中。

别忘了对旧数据库使用更改脚本。如需更多信息，请查看，

http://www.codeproject.com/Tips/800936/Entity-Framework-code-first-migrations-alternative

【讨论】：