C# 如何首先在较新的数据库模型版本中使用实体框架代码

也许是一个奇怪的问题，但我们有一个场景，在这个场景中，我们希望首先在一个环境中使用实体框架代码，该环境可能有一个比代码本身更新/更高版本的数据库

让我详细说明一下。我们有两个解决方案，它们都使用一个核心组件，其中包含所有解决方案都使用的总体数据模型。解决方案主要是部署到多个不同Azure网站的站点和应用程序。因此，解决方案彼此相邻运行。他们唯一共享的是Azure数据库

现在，这一情景将起作用。当我们更新核心组件中的数据库模型并更新Azure中的一个解决方案时。在该解决方案中加载模型时，将更新基础数据库。没问题，很有魅力

当加载另一个解决方案时，问题开始出现。这些其他解决方案仍在使用以前的core assembly，与它们所连接的数据库模型相比，它现在有一个过时的EF CF模型。因此，将抛出一个很好的异常，如下所示

自创建数据库以来，支持“{NAME}”上下文的模型已更改。手动删除/更新数据库，或使用IDatabaseInitializer实例调用database.SetInitializer。例如，DropCreateDatabaseIfModelChanges策略将自动删除和重新创建数据库，并可以选择使用新数据为其种子

问题是我们是否可以强制模型只加载并忽略数据库中所做的更改。我们内部有一个策略，只在数据库中应用不破坏的更改，因此模型应该能够毫无问题地加载

提前感谢您提供的信息和提示

我可能是错的（不确定我是否记得正确），但如果它不干扰您的应用程序配置，您可以将DB initializer设置为null：

    public PortalDbContext()
        : base("name=PortalConnectionString")
    {
        Database.SetInitializer<PortalDbContext>(null);
    }

public PortalDbContext（）
：base（“名称=PortalConnectionString”）
{
Database.SetInitializer（null）；
}

也可以创建自定义初始值设定项：

public class BlogContextCustomInitializer : IDatabaseInitializer<BlogContext>
{
    public void InitializeDatabase(BlogContext context)
    {
        if (context.Database.Exists())
        {
            if (!context.Database.CompatibleWithModel(true))
            {
                // Do something...
            }
        }
    }
}

公共类BlogContextCustomInitializer:IDatabaseInitializer
{
public void InitializeDatabase（BlogContext上下文）
{
if（context.Database.Exists（））
{
如果（！context.Database.CompatibleWithModel（true））
{
//做点什么。。。
}
}
}
}

如果首先使用EF代码，则模型必须与数据库匹配

即使你找到了一种方法来规避这个限制，你也会做一些危险的事情

让我解释一下：如果您从“解决方案A”更新数据库，“A”中的模型将与数据库匹配，并且此解决方案中对模型的任何进一步更改都可以应用于数据库，而不会出现任何问题。这是正确的！。然而，如果你按照你在这个问题中提出的要求去做，也就是说，你做了一些事情，使“解决方案B”能够继续工作，即使模型与数据库不匹配，然后你在“解决方案B”中对模型进行了更改，你如何应用它？“解决方案B”如何知道要应用哪些更改？“B”如何确定“A”所做的哪些更改应保持原样，以及“B”所做的哪些必须应用于数据库的新更改

如果您可以继续这样做，那么您将使用两种不同的代码优先模型，它们都与数据库不匹配，此外，您如何保证这两种应用程序都能正常工作？如何确保“A”上的更改不会影响“B”上的代码，反之亦然

避免此问题的最安全解决方案是在两个解决方案之间共享包含代码优先模型的程序集。任何其他解决方案迟早都会带来麻烦。也许您必须重构您的解决方案，以便它们可以共享相同的DbContext。DbContext必须是项目中唯一的内容。我通常有一个Entities项目和一个DbContext项目，该项目引用实体。那么这两种解决方案都会引用这些项目。这些项目可以位于其中一个解决方案中，也可以位于完全不同的解决方案中。当然，在一个或两个解决方案中，您必须添加对DbContext程序集的引用，而不是项目，并保持它的更新，您可以为此使用生成后脚本。这样，当您重新编译您的解决方案时，您还将检测到对一个解决方案所做的不兼容更改，这些更改会对另一个解决方案产生不利影响

---

EF6在同一数据库中支持多个不同的

DbContext

，因此，如果每个应用程序都有不同的、不冲突的

DbContext

，就不会有问题。我无法正确地检查它，但我认为

DbContext

的名称在每个解决方案中都必须不同（我不记得是否考虑了名称空间）。“非冲突”指的是它们引用不同的数据库对象（表、视图或其他任何对象），其中两个上下文引用的对象不会更改（例如主表）。

如果您也使用EF进行迁移，我担心现在可能有一种方法可以在同一数据库上使用多个版本的对象模型图。EF migrations使用模型列创建uuu MigrationHistory表，该列是应用程序数据库模型的压缩形式。当应用程序首次初始化时，EF将使用_MigrationHistory表中提供的最新版本检查当前模型状态。由于您只能有一个uu MigrationHistory表，因此可能无法将两个具有不同数据库模型的不同应用程序连接到同一个数据库。我也有过类似的问题。我希望有一些解决办法。我希望我能找到一些东西。会让你知道结果的，不客气。我突然想起有几点需要解释。。。我脑子里有，但没有写。我希望现在更清楚了。我试图解释