在我的BL(将是公共API)中，我使用ICollection作为find方法中的返回类型，例如：

注意使用ICollection而不是Collection<>。

现在在我的GUI中，我需要将结果强制转换回集合，比如：

这是因为我需要在返回的列表中使用一些collection<>特定的方法，而这是我不能用ICollection<>做的。

这是正确的用法吗？或者我应该简单地将返回类型从collection<>改为ICollection<>以避免这种转换吗？

其次，我没有使用IEnumerable，因为它比ICollection更通用，甚至没有像Count这样的简单属性。在这里，我真的不认为推广返回类型有什么意义。我错过重要的东西了吗？

您想要返回ICollection的唯一原因是为了实现松耦合和继承目的。如果您的方法只有一个版本(因为它是静态的)，那么您将始终知道返回类型(集合)，并且不需要使它成为ICollection。但是，如果在一系列类中使用，则可能会有一个返回和ICollection的虚拟或抽象方法，然后在子类实现中，可以返回集合或FunkyCollection或任何实现接口的对象，因此这会给您带来更多的灵活性，即说只能返回集合。但出于您的目的，您应该将返回类型集合改为ICollection，而不是ICollection，因为它是一个不会被重写的静态方法。此外，它还可以减少用户的困惑，因为他们不需要强制转换。

使用ICollection的关键是更通用，隐藏更多信息，这是一件好事。

但是，如果您需要将其转换回原处，它已经变得毫无意义了，您还可以返回更具功能性的集合<>

其他人已经给出了这么好的答案，但我只是想澄清，不，我不相信你所做的是理想的。这样做的原因是，如果稍后有人来修改/重构/重新实现您的BL以返回一些其他类型的ICollection(根据API)，而不是真正的Collection，您将在GUI中得到运行时错误。

但是，您仍然可以选择从BL返回一个ICollection：那么，如果您真的想要一个Collection(可能，对于一个或多个方便的扩展方法，我猜？)，然后您可以创建一个新集合，并将内容从一个集合复制到另一个集合。这样，就不会冒运行时错误的风险。虽然，最终取决于(别人已经问过)您在Collection中寻找的方法…也许有更好的方法来做你想做的事。

祝你好运！< BR>- F！

如果您打算要求用户使用collection<>方法，那么您可能应该返回collection<>而不是ICollection。

或者，可以使用程序集内部的单独函数返回GUI所需的类型：

这可能是因为集合实现了IList，而它有一些ICollection没有的额外方法，这对您来说已经足够了。你缺少什么方法？

返回ICollection的想法是这样您的方法耦合度就更少了。如果您以后想要构建一个列表，而不是一个集合，那么您就可以在不破坏客户机代码等的情况下完成它。

如果你只是用这个来获得一个集合(而不是一个ICollection)，那么你可以改为Collection，因为你知道你会有一个不那么灵活的方法。但无论如何，雅格尼。

此外，如果您担心设计问题，我建议不要将此设置为静态的，以提高代码的可测试性。