根据fxcop，列表不应该在API对象模型中公开。为什么这被认为是不好的做法？

我同意这里丛林中的驼鹿：List是一个不受约束的、膨胀的物体，里面有很多"行李"。

幸运的是，解决方案很简单：改为公开IList。

它公开了一个拥有大多数List方法的准系统接口(AddRange()除外)，并且它不限制您使用特定的List类型，这样您的API使用者就可以使用自己的IList自定义实现器。

为了获得更大的灵活性，请考虑在适当的时候将一些集合公开给IEnumerable。

主要有两个原因：

• list是一个相当膨胀的类型，许多成员在许多场景中都不相关(对于公共对象模型来说太"忙")。
• 类是未密封的，但不是专门设计为要扩展的(不能重写任何成员)

只有在编写一个将被成千上万的开发人员使用的API时，才认为这是一个糟糕的实践。

.NET框架设计指南适用于Microsoft的公共API。

如果有一个API没有被很多人使用，那么应该忽略这个警告。

我认为你不希望你的消费者在你的退货中加入新的元素。API应该是清晰和完整的，如果它返回一个数组，它应该返回准确的数据结构。我不认为它与t per say有关，而是直接返回一个列表<>而不是数组[]

其中一个原因是用户可以更改列表，并且列表的所有者不知道这一点，而在某些情况下，在列表中添加/删除项目后，它必须做一些事情。即使现在不需要，将来也会成为一种需求。因此，最好将addxxx/removexxx方法添加到类的所有者，并公开一个IEnumerable列表，或者(在我看来更好)将其公开为IList，并使用来自WindowsBase的ObservableCollection。

一个原因是因为列表不是你可以模拟的东西。即使在不太流行的库中，我也看到过由于这个建议而将列表对象作为IList公开的迭代，并且在以后的版本中，决定根本不将数据存储在列表中(可能存储在数据库中)。因为它是一个IList，所以更改客户机下的实现并保持每个人工作并不是一个破坏性的更改。