【问题标题】:Entity Framework Code First Auto-create Table实体框架代码优先自动创建表
【发布时间】:2014-09-06 04:24:05
【问题描述】:

我试图了解 Entity Framework 到底在做什么,导致我将要描述的观察到的行为。

这是一个 ASP.NET MVC 4 Internet 应用程序项目。

我在本地主机上有一个名为 wpdb 的现有 MSSQL 数据库。

Web.config:

<add name="DefaultConnection"
    connectionString="Data Source=localhost;Initial Catalog=wpdb;User=xxx;Password=xxx"
    providerName="System.Data.SqlClient" />

当我第一次运行网络应用程序时,它会自动创建dbo.UserProfiledbo.webpages_Membership 和其他一些表格。

我创建了一个新模型Comments.cs

public class Comment
{
    public int ID { get; set; }
    public string Text { get; set; }
}

public class CommentDBContext : DbContext
{
    public DbSet<Comment> Comments { get; set; }
}

我添加了一个新的控制器CommentsController 作为具有读/写操作和视图的MVC 控制器,使用实体框架(并选择我的“Comment”和“CommentDBContext”类)。

然后我添加了一个新的连接字符串(显然 Entity Framework 的默认连接字符串不是“DefaultConnection”,但最终是无效的,我不知道为什么)。

<add name="CommentDbContext"
    connectionString="Data Source=localhost;Initial Catalog=wpdb;User=xxx;Password=xxx"
    providerName="System.Data.SqlClient" />

现在,当我浏览到 localhost/Comments 时,Entity Framework 会自动在我的数据库中创建一个名为 dbo.Comments 的新表。

到目前为止我所描述的一切都完全符合预期,这就是它变得奇怪的地方

我不小心删除了dbo.Comments。但是,这一次当我浏览到localhost/Comments Entity Framework 时不会重新创建表。相反,它会向我抛出“无效对象 'dbo.Comments'”错误。

为什么要这样做?为什么不只是重新创建数据库?我什至尝试删除我所有的模型/控制器/视图代码,清理/重建解决方案,然后重新创建它,EF 仍然拒绝重新创建表!

更令人困惑的是,如果我在 Web.config 文件中注释掉 CommentDbContext 行(以便 EF 代码尝试连接到错误的数据库)然后运行应用程序并浏览到 /Comments,然后杀死应用程序,取消注释连接字符串,这次它会创建一个全新的dbo.Comments 表,没有任何问题!

为什么将连接字符串更改为无效然后将其更改回允许 EF 再次从我的模型生成表?似乎有一些状态被保存在不应该的地方..

【问题讨论】:

    标签: sql-server asp.net-mvc entity-framework


    【解决方案1】:

    我不小心删除了 dbo.Comments。它向我抛出“无效对象'dbo.Comments'”错误。为什么会这样?

    因为您不应该按照配置的方式编辑/删除表格。它不会自动地同步对模型的数据库更改和对数据库的模型。

    为什么不直接重新创建数据库?

    因为你没有自动告诉它,也没有要求它。

    为什么将连接字符串更改为无效然后将其更改回来允许 EF 再次从我的模型生成表?

    因为它创建了一个表(忘记了名称),该表知道它上次同步的时间以及它已经创建和尚未创建的表。当您将连接字符串更改为没有该表的其他数据库时,它会重新创建所有内容。

    您可能应该看看 MSDN 上的以下文章,然后选择您希望 Entity Framework 如何为您的场景工作:

    Code First Migrations

    【讨论】:

    • Because it creates a table (forgot the name) that knows 我想了解更多有关此的信息。你能把我链接到一些文档吗?
    • 我认为这个漏掉的一件事是:当他把它改回原来的连接字符串时,为什么它决定创建丢失的表?为什么在完全弄乱连接字符串之前没有检测到丢失的更改?我怀疑它只在应用程序启动时检查实体模型,并且由于它是一个 MVC 应用程序,它直到 webconfig 被更改才重新启动。我怀疑他可能只是循环了应用程序和/或 IIS,它会自动重新创建表,而不会弄乱连接字符串。
    • 无论如何,如果 DbContext 的每个实例都必须进行完整的模式比较以确定模型已更改,那么这将非常昂贵。不是对您出色答案的批评,只是对 OP 的一些见解,说明他们为什么在应用程序运行时不自动执行此操作。
    • @AaronLS 你可能是对的。 OP 没有提供有关当前如何配置 EF 的信息,而且我根本不知道默认值,因为我更喜欢在我的代码中明确表示,所以我确切地知道它应该做什么。在更新版本时,显式应该提供更少的中断代码。
    • 同意,默认行为通常只适用于早期开发,当转移到暂存/生产时非常迅速,那么迁移是必要的。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-12-05
    • 2017-07-05
    • 1970-01-01
    相关资源
    最近更新 更多