EntityFramework Core 9.0 中值类型转换器的兼容性问题解析

在从 EntityFramework Core 8 升级到 9.0 版本后，许多开发者遇到了一个关于值类型转换器的兼容性问题。这个问题主要出现在使用自定义值类型（如记录结构体）作为实体属性时，特别是在处理可为空值类型与不可为空值类型之间的转换场景中。

问题现象

当开发者使用类似如下的自定义值类型定义时：

public readonly record struct AreaLocationId(int Value);

并在实体配置中使用可为空的转换器：

builder.Property(e => e.LocationId)
    .HasConversion(
        id => id == null ? (int?)null : id.Value.Value,
        value => value == null ? null : new AreaLocationId(value.Value));

在 EF Core 8 中可以正常工作的查询，在 EF Core 9.0 中会抛出异常：

No coercion operator is defined between types 'ValueComparer`1[Nullable`1[AreaLocationId]]' and 'ValueComparer`1[AreaLocationId]'

问题根源

这个问题的本质在于 EF Core 9.0 对值类型转换器的处理更加严格。在 EF Core 8 中，系统能够隐式处理可为空与不可为空值类型之间的转换，但在 9.0 版本中，这种隐式转换不再被允许。

具体来说，当开发者尝试将一个非空值类型集合（如 List<AreaLocationId>）与一个可为空属性（如 AreaLocationId?）进行比较时，EF Core 9.0 会严格检查类型兼容性，导致操作失败。

解决方案

推荐解决方案

EF Core 团队推荐的最佳实践是为非空值类型定义转换器，而不是直接处理可为空的情况。正确的做法应该是：

protected class AreaLocationIdConverter() : ValueConverter<AreaLocationId, int>(
    v => v.Value, 
    v => new(v));

// 在模型配置中使用
b.Property(e => e.LocationId).HasConversion<AreaLocationIdConverter>();

这种方式让 EF Core 自动处理可为空的情况，而不是在转换器中显式处理 null 值。

临时解决方案

如果暂时无法修改转换器定义，可以使用以下临时解决方案：

// 使用可为空的集合类型匹配属性类型
var availableLocations = new List<AreaLocationId?> { new(1), new(2) };

技术背景

这个问题反映了 EF Core 9.0 在类型系统处理上的一个重要变化。在底层，EF Core 现在更严格地区分：

1. 值类型本身（如 AreaLocationId）
2. 值类型的可为空版本（如 AreaLocationId?）
3. 它们的比较器（ValueComparer）

这种严格性有助于避免潜在的运行时错误，但也带来了升级时的兼容性问题。开发者需要确保在查询中使用的类型与实体属性定义的类型完全匹配。

升级建议

对于计划从 EF Core 8 升级到 9.0 的开发者，建议：

1. 审查所有自定义值类型转换器，确保它们遵循非空值类型转换的最佳实践
2. 检查所有涉及值类型比较的查询，确保比较双方的类型完全一致
3. 考虑在测试环境中先行验证，特别是那些涉及复杂类型转换的场景

通过遵循这些指导原则，开发者可以顺利过渡到 EF Core 9.0，同时利用其更严格的类型系统带来的好处。