为何在C#泛型属性中使用ICollection<T>而非Collection<T>？

开发者阿泽

2026-5-15

为啥MVC里用ICollection<T>作为属性类型？

哈哈，这个疑问太有代表性了——我刚接触.NET的时候也纠结过：放着现成的Collection<T>具体类不用，为啥非要用接口当属性类型？其实这背后是面向接口编程的核心思想，结合ORM框架的特性来看就完全通了：

依赖抽象，而非具体实现：用ICollection<T>作为属性类型，意味着这个属性可以接受任何实现了该接口的集合类——比如List<T>、HashSet<T>，甚至你自己写的自定义集合。如果写成Collection<Enrollment>，那这个属性就只能接收Collection<T>类型的实例，后续想换成更合适的集合（比如需要快速查找就换HashSet<T>），就得修改属性的类型定义，灵活性大打折扣。
适配ORM框架的需求：在MVC搭配Entity Framework这类ORM框架时，框架需要动态生成集合的代理类来支持懒加载、变更追踪等特性。这些代理类都是实现了ICollection<T>接口的，但并不是Collection<T>的子类。如果属性定义成Collection<Enrollment>，EF就没法替换成它的代理实现，会直接影响框架的核心功能。
初始化的小细节：虽然属性是接口类型，但我们通常会在类的构造函数里给它赋一个具体的实现，比如：
```
public class Student
{
    public Student()
    {
        Enrollments = new List<Enrollment>();
    }
    public virtual ICollection<Enrollment> Enrollments { get; set; }
}
```
这样既保持了抽象性，又避免了属性为null的问题。