Question

我已经阅读过Code First Migrations，但似乎这并不适合企业版。

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

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

Answer 1

即使我使用EF Code First风格（与EDMX相反），我仍然在技术上使用数据库第一种方法，因为我从不让EF为我生成数据库。相反，我创建了类来建模数据库。这听起来像你需要做的事情。

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

Answer 2

对我来说，似乎这些其他答案都不够。

您可以关闭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

Answer 3

通常在这种情况下，人们会使用Database First方法。

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

Answer 4

回复有点迟，但这里有：

如果您使用Visual Studio的EF Power Tools扩展程序，它可以让您执行Rowan Miller所说的“#Second Code＆＃34;”。看看this article。

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

展望未来，EF团队将此功能推广到主要EF工具中，因此您无需下载EF Power Tools扩展程序。

Answer 5

只是为此添加一些想法 - 看看这两篇文章（我前一段时间）： https://stackoverflow.com/a/10164815/417747
https://stackoverflow.com/a/10255051/417747

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

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

希望这有点帮助。

Answer 6

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

旧数据库，__ MobileHistory表是 enter image description here

在数据库中进行了更改，并在本地计算机上重新创建 enter image description here

将当前创建的数据库的__MigrationHistory表中的ContextKey，Model和ProductVersion添加到旧数据库的__MigrationHistory表中。 enter image description here

哦，别忘了将alter scripts用于旧数据库。如需更多检查，

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

当所有代码更改都由DBA完成时，是否可以使用EF替代Code First Migrations？

6 个答案: