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

因为BasketItems不需要作为列表。请注意，setter是公共的。正如你所指出的，它也可以被覆盖。

基本上说，只要BasketItems是BasketItem的集合，这就是我们需要知道的全部内容。我们不关心如何实现集合。

Answer 2

尽可能避免使用混凝土类型通常是一种很好的设计实践。它实际上为您带来了许多强大的优势，这些优势在SOLID的依赖性倒置原则中得到了很好的记录 - SOLID Wikipedia。简而言之，不要把自己放在一个角落是好的设计，因为它允许用户按照他们认为合适的方式扩展属性并降低维护，因为作为作者，您不必为每个实现创建新的类类型ICollection。

这里的另一大好处是单元测试。避免使用具体类型可以更轻松地在单元测试中模拟依赖项。这导致测试更小且更精确。这里有一个很好的解释，有关更多信息的好处 - How do interfaces making unit testing and mocking easier?

Answer 3

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

ICollection在课堂上

3 个答案: