【Entity Framework】闲话EF中批量配置

一、概述

当需要在多个实体类型中以相同方式配置一个方面时，可以通过以下方式减少代码重复并合并逻辑。

二、OnModelCreating中的批量配置

从ModelBuilder返回的每个生成器对象都会公开一个Model或Metadata属性，该属性提供对构成模型的对象的低级别访问。具体而言，有些方法允许循环访问模型中的特定对象，并对其应用通用配置。

如下示例中，模型中包含一个自定义值类型Currency:

public readonly struct Current
{public Crrent(decimal amount)=>Amount = amount;public decimal Amount{get;}public override string ToString() => $"${Amount}";
}

默认情况下不会发现此类型的属性，因为当前EF提供程序不知道如何将其映射到数据库类型。此OnModelCreating代码片段添加类型Currency的所有属性。并将值类型器配置为受支持的类型-decimal：

foreach(var entityType in modelBuilder.Model.GetEntityTypes())
{foreach (var propertyInfo in entityType.ClrType.GetProperties()){if (propertyInfo.PropertyType == typeof(Currency)){entityType.AddProperty(propertyInfo).SetValueConverter(typeof(CurrencyConverter));}}
}

public class CurrencyConverter : ValueConverter<Currency, decimal>
{public CurrencyConverter(): base(v => v.Amount,v => new Currency(v)){}
}

元数据API的缺点

• 与Fluent API不同，对模型的每次修改都需要显示完成。
• 每次更改后都会运行约定。如果删除约定发现的导航，则约定将再次运行，并可以将导航添加回来。为了防止这种情况发生，需要延迟约定，直到通过调用DelayConventions() 添加属性之后再释放返回的对象，或者使用AddIgnored 将CLR属性标记为忽略。
• 发生此循环访问后，可能会添加实体类型，并且不会向其应用配置。通常可以通过将此代码放在OnModelCreating的末尾来防止这种情况，但如果有两组相互依赖的配置，则可能没有一个顺序可以一致地应用这些配置。

三、预先约定配置

EF Core允许为给定CLR类型指定一次映射配置；然后，此配置将应用于模型中发现的给定类型的所有属性。这称为"预先预定模型配置"，因为它配置模型的各个方面，直到允许运行模型生成约定。此类配置通过在DbContext派生的类型上替代ConfigureConventions来应用。

以下示例演示如何将类型Currency的所有属性配置为具有值转换器：

protected override void ConfigureConventions(ModelConfigurationBuilder configurationBuilder){configurationBuilder.Properties<Currency>().HaveConversion<CurrencyConverter>();
}

以下示例演示如何在类型 string 的所有属性上配置一些方面：

configurationBuilder.Properties<string>().AreUnicode(false).HaveMaxLength(1024);

备注

从ConfigureConventions调用中指定的类型可以是基类型，接口或泛型类型定义。所有匹配的配置将从最不具体的配置开始按顺序应用：

1. 接口
2. 基类型
3. 泛型类型定义
4. 不可以为null的值类型
5. 确切类型

预先约定配置相当于将匹配对象添加到模型后立即应用的显示配置。它将替代所有约定和数据注释。

忽略类型

预先预定配置还允许忽略某个类型，并防止约定将其作为实体类型或实体类型的属性发现：

configurationBuilder.IgnoreAny(typeof(IList<>));

默认类型映射

通常，只要为此类型的属性指定了值转换器，EF就可以使用提供程序不支持的类型常量转换查询。但是，在不涉及此类型的任何属性的查询中，EF无法找到正确的值转换器。在这种情况下。可以调用DefaultTypeMapping 添加或替代提供程序类型映射：

configurationBuilder.DefaultTypeMapping<Currency>().HasConversion<CurrencyConverter>();

预先约定配置的限制

• 许多方面无法使用此方法进行配置
• 目前，配置仅由CLR类型确定
• 在创建模型之前，将执行此配置。如果应用此配置时出现任何冲突，则异常堆栈跟踪将不包含ConfigureConventions方法，因此可能更难找到原因。

约定

EF Core模型生成约定是根据在生成模型时对模型的更改触发的包含逻辑的类。这使得模型在进行显示配置，应用映射属性以及运行其他约定时保持最新状态。为了参与此过程，每个约定实现一个或多个接口，用于确定何时触发相应的方法。

模型生成约定是控制模型配置的强大方法，但可能很复杂且难以处理得当。 在许多情况下，可以使用现有的预先约定模型配置来轻松指定属性和类型的常见配置。

添加新约定

每个层次结构一个表继承映射策略需要一个鉴别器列来指定任何定行中表示的类型。默认情况下，EF对鉴别器使用未绑定的字符串列，这可确保它使用于任何鉴别器长度。但是，限制鉴别器字符串的最大长度可能会提高存储和查询的效率。

EF Core模型生成约定是根据在生成模型时对模型的更改触发，这使得模型在进行显示配置，应用映射属性以及运行其他约定时保持最新状态，为了参与此过程，每个约定实现一个或多个接口，用于确定何时触发约定。如，每次向模型添加新实体类型时，都会触发实现IEntityTypeAddedConvention的约定。同样，每当将键或外键添加到模型时，都会触发实现IForeignKeyAddedConvention和IKeyAddedConvention的约定。

替换现有约定

有时，我们不想完全删除现有约定，而是想将其替换为一种操作基本相同但行为已更改的约定。这很有用，因为现有约定已经实现了需要适当触发的接口。

约定实现注意事项

EF Core会跟踪每个配置是如何进行的。这由ConfigurationSource枚举表示。不同类型的配置包含：

• Explicit：模型元素在OnModelCreating中显示配置
• DataAnnotation：模型元素是使用CLR类型的映射属性（既数据注释）配置的
• Convention：模型元素是由模型生成约定配置的

预定永远不会替代标记为DataAnnotation或Explicit的配置。这是通过使用"约定生成器"来实现的。例如,从Builder属性获取的IConventionPropertyBuilder。

property.Builder.HasMaxLength(512);

如果 HasMaxLength 尚未由映射属性配置或在 OnModelCreating 中配置，则在约定生成器上调用它只会设置最大长度。

此类生成器方法还有第二个参数：fromDataAnnotation。 如果约定代表映射属性进行配置，则将其设置为 true。

四、何时使用每种方法进行批量配置

在以下情况下使用元数据API：

• 配置需要在某个时间应用，而无需对模型中的后续更改做出反应。
• 模型生成速度非常重要。元数据API的安全检查较少，因此比其他方法稍快一些，但是使用编译模型会产生更好的启动时间。

在以下情况下使用预先预定模型配置：

• 适用条件很简单，因为它仅取决于类型。
• 需要在模型中添加给定类型的属性并替代数据注释和约定时，随时应用配置。

在以下情况下使用最终约定：

• 适用条件很复杂。
• 配置不应替代数据注释指定的内容。

在以下情况下使用交互式约定：

• 多个约定相互依赖。 最终约定按照添加顺序运行，因此无法对后面的最终约定所做的更改做出反应。
• 逻辑在多个上下文之间共享。 交互式约定比其他方法更安全。