Entity Framework中Nullable适配模型构造器的无警告实现问题

问题背景 #

我正在编写适配Nullable引用类型（NRT）的模型构造器，目标是实现无编译警告且不使用default!的规范写法。目前大部分问题已解决，但集合属性存在异常：明明在无参构造函数中初始化了集合，编译器却不识别，导致必须在对象初始化器中手动赋值。

Campaign类代码 #

public class Campaign
{
    private string _name;

    public int Id { get; private set; }

    public required string Name
    {
        get => _name;
        set => _name = value.Trim();
    }

    public required State State { get; set; }

    public required ICollection<Event> Events { get; set; }

    public required ICollection<User> Followers { get; set; }

    public bool Enabled { get; set; }

    public bool Closed { get; set; }

    public bool Deleted { get; set; }

    public DateTime Created { get; private set; }

    protected Campaign(int id, string name, DateTime created)
    {
        _name = name;
        Id = id;
        Created = created;
    }

    public Campaign()
    {
        _name = string.Empty;
        Events = new List<Event>();
        Followers = new List<User>();
        Enabled = true;
        Created = DateTime.UtcNow;
    }
}

测试代码的编译问题 #

在xUnit测试中，必须手动设置Events和Followers，否则会出现编译错误：

var campaign = new Campaign
{
    Name = "Test Campaign",
    State = state,
    // 缺少以下两行会编译错误
    Followers = new List<User>(),
    Events = new List<Event>()
};

疑问与方案咨询 #

1. 为什么编译器会有这样的要求？
2. 移除这两个属性的required关键字是否可行？有什么弊端？
3. 我目前倾向于双构造器方案：一个供EF使用的受保护构造器，一个用于手动构建对象的无参公共构造器。在无参构造器中，将非空字符串设为Empty，集合设为空列表以保证NRT状态正确，然后移除这些属性的required关键字。这个方案是否有遗漏，或者有没有更优实现？

解答 #

1. 编译器要求手动赋值的原因 #

C#的required关键字设计逻辑是：强制属性在对象初始化器中被显式赋值，不管构造函数内部有没有做初始化。也就是说，required的校验只针对对象初始化阶段的显式设置，构造函数里的初始化不会被编译器视为满足required的要求。所以即使你在无参构造里给集合赋了值，只要加了required，就必须在new Campaign { ... }里再显式写一遍。

2. 移除required关键字的可行性与弊端 #

完全可行，弊端主要有两点：

• 失去编译期强制校验：如果其他开发者手动创建Campaign时，绕过无参构造直接用EF的受保护构造器（虽然是受保护的，但子类可以调用），或者未来修改无参构造时不小心删掉集合初始化，编译器不会报错，可能导致运行时空引用。不过你的无参构造已经稳定初始化了集合，这个风险极低。
• EF构造器需要处理空值：受保护的EF专用构造器里，集合属性无法直接初始化（EF会自己生成代理集合来跟踪变更），所以不得不写Events = default!或者Followers = default!——但你提到只在EF构造器里用这个语法是可接受的，这个代价很小。

3. 双构造器方案的评估与优化 #

你的方案是合理的，这也是.NET社区适配NRT和EF的常见实践，几乎没有遗漏。补充几个优化点：

• 限制集合属性的可变性：把集合属性的setter设为private，如果不需要外部代码替换集合引用的话。比如：

  public ICollection<Event> Events { get; private set; }
  

  这样外部只能修改集合内的元素，不能把整个集合设为null，进一步降低空引用风险。如果需要兼容EF的代理，可以保持set;但改成protected set;。
• 替换集合接口为具体类型（可选）：把ICollection<Event>改成List<Event>，这样构造器里的初始化更直接，EF也能正常处理代理。
• 避免default!的替代方案：如果不想用default!，可以在EF构造器里给集合赋一个临时空集合，比如Events = new List<Event>()——EF在加载实体时会自动替换成代理集合，不会影响功能，这样就能彻底告别default!。

内容的提问来源于stack exchange，提问作者David Thielen