通过

基于代码的配置

  • 项目

注意

仅限 EF6 及更高版本 - 此页面中讨论的功能、API 等已引入实体框架 6。 如果使用的是早期版本，则部分或全部信息不适用。

可以在配置文件 (app.config/web.config) 中指定实体框架应用程序的配置，也可以通过代码进行指定。 后者称为基于代码的配置。

我们在单独的文章中介绍了配置文件中的配置。 配置文件优先于基于代码的配置。 换而言之，如果在代码和配置文件中都设置了配置选项，则使用配置文件中的设置。

使用 DbConfiguration

EF6 和更高版本中基于代码的配置是通过创建 System.Data.Entity.Config.DbConfiguration 的子类实现的。 设置 DbConfiguration 的子类时，应遵循以下指南：

  • 仅为应用程序创建一个 DbConfiguration 类。 此类指定应用域范围内的设置。
  • 将 DbConfiguration 类放在与 DbContext 类相同的程序集中。 （如果要更改这一点，请参阅移动 DbConfiguration 部分。）
  • 为 DbConfiguration 类提供一个公共无参数构造函数。
  • 通过从此构造函数内调用受保护的 DbConfiguration 方法来设置配置选项。

遵循这些指导原则后，EF 可以通过需要访问模型的工具和运行应用程序时自动发现和使用配置。

示例

派生自 DbConfiguration 的类可能如下所示：

using System.Data.Entity;
using System.Data.Entity.Infrastructure;
using System.Data.Entity.SqlServer;

namespace MyNamespace
{
    public class MyConfiguration : DbConfiguration
    {
        public MyConfiguration()
        {
            SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy());
            SetDefaultConnectionFactory(new LocalDbConnectionFactory("mssqllocaldb"));
        }
    }
}

此类设置 EF 以使用 SQL Azure 执行策略 - 自动重试失败的数据库操作，并对由 Code First 中的约定创建的数据库使用本地 DB。

移动 DbConfiguration

在某些情况下，不能将 DbConfiguration 类放在与 DbContext 类相同的程序集中。 例如，你可能在不同的程序集中有两个 DbContext 类。 有两个选项可用于处理这种情况。

第一个选项是使用配置文件指定要使用的 DbConfiguration 实例。 为此，请设置 entityFramework 部分的 codeConfigurationType 属性。 例如：

<entityFramework codeConfigurationType="MyNamespace.MyDbConfiguration, MyAssembly">
    ...Your EF config...
</entityFramework>

codeConfigurationType 的值必须是 DbConfiguration 类的程序集和命名空间限定名称。

第二个选项是将 DbConfigurationTypeAttribute 放置在上下文类中。 例如：

[DbConfigurationType(typeof(MyDbConfiguration))]
public class MyContextContext : DbContext
{
}

传递给特性的值可以为 DbConfiguration 类型（如上所示），也可以是程序集和命名空间限定的类型名称字符串。 例如：

[DbConfigurationType("MyNamespace.MyDbConfiguration, MyAssembly")]
public class MyContextContext : DbContext
{
}

显式设置 DbConfiguration

某些情况下，在使用任何 DbContext 类型之前可能需要先进行配置。 这种情况的示例包括：

  • 使用 DbModelBuilder 生成没有上下文的模型
  • 使用应用程序上下文之前，使用其他一些框架/实用程序代码，这些代码在使用该上下文的情况中利用 DbContext

在这种情况下，EF 无法自动发现配置，必须执行以下操作之一：

  • 在配置文件中设置 DbConfiguration，如上文中的移动 DbConfiguration 部分中所述
  • 在应用程序启动过程中调用静态 DbConfiguration.SetConfiguration 方法

重写 DbConfiguration

在某些情况下，需要重写 DbConfiguration 中设置的配置。 这通常不由应用程序开发人员完成，而是由不能使用派生的 DbConfiguration 类的第三方提供程序和插件来完成。

为此，EntityFramework 允许注册事件处理程序，该事件处理程序可以在锁定之前修改现有配置。 它还提供专门用于替换 EF 服务定位器返回的任何服务的 sugar 方法。 下面是它的预期使用方法：

  • 在应用启动（使用 EF 之前）时，插件或提供程序应为此事件注册事件处理程序方法。 （注意，此操作必须在应用程序使用 EF 之前进行。）
  • 事件处理程序为需要替换的每个服务调用 ReplaceService。

例如，要替换 IDbConnectionFactory 和 DbProviderService，需要注册类似于以下的处理程序：

DbConfiguration.Loaded += (_, a) =>
   {
       a.ReplaceService<DbProviderServices>((s, k) => new MyProviderServices(s));
       a.ReplaceService<IDbConnectionFactory>((s, k) => new MyConnectionFactory(s));
   };

在上面的代码中，MyProviderServices 和 MyConnectionFactory 表示服务的实现。

你还可以添加其他依赖关系处理程序来获得相同的效果。

请注意，你也可以通过这种方式包装 DbProviderFactory，但这样做只会影响 EF，而不会影响在 EF 之外使用 DbProviderFactory。 出于此原因，你可能会希望继续像以前一样包装 DbProviderFactory。

还应记住在应用程序外部运行的服务 - 例如，从程序包管理器控制台运行迁移时。 从控制台运行迁移时，它会尝试查找 DbConfiguration。 但是，它是否将获得包装好的服务取决于它注册的事件处理程序的位置。 如果已将其注册为 DbConfiguration 的构造的一部分，则应执行代码并包装服务。 通常不会出现这种情况，这意味着工具不会获得包装好的服务。