课堂ICollection

Question

我看到了下面的代码：

public class Basket
{
    public Guid BasketId { get; set; }
    public DateTime Date { get; set; }

    public virtual ICollection<BasketItem> BasketItems { get; set; }

    public Basket()
    {
        BasketItems = new List<BasketItem>();
    }
}

我不太明白的是，为什么我们要

public virtual ICollection<BasketItem> BasketItems { get; set; }

而不是

public virtual List<BasketItem> BasketItems { get; set; }

我能想到的一个原因是，当这个类被继承时，我们可以用不同的类型覆盖BasketItems？

这样做的其他原因是什么？

Answer 1

在可能的情况下避免混凝土类型通常是一个好的设计实践。它实际上给您带来了许多强大的优势，这些优势在SOLID - 坚实维基百科的依赖反转原则中得到了充分的证明。长话短说，不让自己陷入困境是很好的设计，因为它允许用户按他们认为合适的方式扩展属性，这降低了维护，因为作为作者，您不必为ICollection的每个实现创建一个新的类类型。

这里的另一个好处是单元测试。避免具体类型使模拟单元测试中的依赖关系变得更加容易。这导致测试变得更小和更精确。这里有一个很好的解释，可以获得更多的信息- 接口如何使单元测试和模拟变得更容易？

Answer 2

因为BasketItems不需要成为一个列表。注意，设置者是公共的。正如您所指出的，它也可以被重写。

本质上说，只要BasketItems是BasketItem的集合，我们就只需要知道这些。我们不在乎集合是如何实现的。

Answer 3

还有一件事：ICollection通常也用于DataEntity中的许多/多个关系。您可以引用(MSDN：http://msdn.microsoft.com/en-us/library/92t2ye13.aspx)是一个需要迭代和修改的对象列表。