entity-framework - 当所有代码更改都由 DBA 完成时，是否有替代使用 EF 进行代码优先迁移的方法？

Question

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

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

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

score 6 · Accepted Answer

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

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

万一该 URL 将来不起作用 - 这就是我的意思：

在上面设置了 Initializer 之后，配置与表对应的 POCO：

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

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

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

score 5 · Accepted Answer

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

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

score 2 · Accepted Answer

回复有点晚，但这里有：

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

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

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

score 1 · Accepted Answer

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

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

score 0 · Accepted Answer

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

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

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

希望这个对你有帮助。