EF Core 9.0 中InMemory提供程序与编译模型的使用注意事项

在升级到EF Core 9.0后，开发人员在使用InMemory提供程序测试时可能会遇到一个特定问题：当实体包含非可空枚举属性时，在调用DbSet.Add()方法时会抛出异常。这个问题的根源在于编译模型(compiled model)与InMemory提供程序之间的兼容性问题。

问题现象

当实体类中包含非可空枚举类型的属性时，EF Core 9.0的InMemory提供程序在尝试添加实体时会抛出NullReferenceException。异常发生在内部类型映射转换器(TypeMapping.Converter)为null的情况下，而代码中却使用了null forgiving操作符(!)，表明开发者预期此处不应该为null。

例如，对于以下实体定义：

public class BillingGroup {
    public int Id { get; set; }
    public required BillingPlan Plan { get; set; } // 非可空枚举
}

public enum BillingPlan : int {
    Personal = 1,
    Business = 2
}

调用context.BillingGroups.Add(new BillingGroup() { Plan = BillingPlan.Personal })时会抛出异常。

问题根源

这个问题主要出现在同时满足以下条件时：

1. 使用了EF Core的编译模型(compiled model)功能
2. 测试环境中使用了InMemory提供程序
3. 实体包含非可空枚举属性

在EF Core 9.0中，即使没有显式调用.UseModel()方法，运行时也会自动检测并使用编译模型。这与EF Core 8.0的行为不同，在8.0版本中可能需要显式指定才会使用编译模型。

解决方案

针对这个问题，有以下几种解决方案：

1. 删除编译模型：完全移除项目中的编译模型，让EF Core在运行时动态构建模型。EF Core 9.0在性能上已有显著提升，可能不再需要编译模型带来的优化。

2. 为InMemory提供程序创建专用模型：如果需要保留编译模型的优势，可以为InMemory提供程序单独创建一个编译模型，与主数据库的编译模型区分开。

3. 将枚举改为可空类型：作为临时解决方案，可以将枚举属性改为可空类型(如BillingPlan?)，但这会改变数据模型的设计。

最佳实践建议

1. 在测试环境中，特别是使用InMemory提供程序时，考虑不使用编译模型，以避免潜在的兼容性问题。

2. 如果项目同时使用多种数据库提供程序(如SQL Server和InMemory)，确保为每种提供程序单独配置模型。

3. 定期检查EF Core的更新日志，了解行为变更，特别是在升级主要版本时。

4. 在测试代码中显式指定是否使用编译模型，避免自动检测带来的不确定性。

EF Core 9.0的这一变更虽然提高了便利性，但也带来了新的注意事项。开发者在升级项目时需要特别注意编译模型与不同提供程序之间的交互方式，特别是在测试环境中使用InMemory提供程序时。