正在返回 Listfrom 方法与返回 Collection的性能有何不同？
我们有一个 Web 项目，在名为“Bll.dll”的类库项目中包含其业务方法
Bll.dll 的某些方法返回 List<>； ...
从消息来源 - 我现在不记得了 - 告诉我们返回 Collection<>比返回 List<>
更好 有效吗？
请注意，我不对 BLL 方法返回的值进行任何处理..只需在网页中查看它
We have a web project that contain its business methods in a class library project called "Bll.dll"
some methods of Bll.dll return List<> ...
from a source - that i don't remember now - told that returning Collection<> is better than returning List<>
Is it a valid ?
Note that i don't make any process on values returned from BLL methods .. just view it in a web page
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
Collection被实现为 IIRC，作为IList的包装器，其默认实现是List。因此，Collection比List至少多了一个抽象，但一般来说这不会成为瓶颈。事实上，您可能会考虑返回IList。编辑：这是
Collection的构造函数，由反射器提供：所以实际上，这包装了一个抽象层。 优点的一面是，您可以通过子类化
Collection添加自己的验证等（这在使用List时是不可能的） code> 直接或通过子类化，因为没有有趣的虚拟方法）。另一件需要考虑的事情是，它们在“O”方面具有相同的总体性能（假设您使用默认的
List实现）。索引器查找将是O(1)等Collection<T>is implemented, IIRC, as a wrapper around anIList<T>, of which the default implementation isList<T>. Therefore aCollection<T>has at least one more abstraction than aList<T>, but in general this won't be a bottleneck. In fact, you might consider returningIList<T>.Edit: here is the constructor of
Collection<T>, courtesy of reflector:so indeed, this wraps a layer of abstraction. The plus side of this is that you can add your own validation etc by subclassing
Collection<T>(which is not possible when usingList<T>directly or via subclassing, since there are no interestingvirtualmethods).The other thing to consider is that they will have the same overall performance in terms of "O" (assuming you use the default
List<T>implementation). Indexer lookup will beO(1), etc您确实应该只返回满足您在设计 API 时设定的目标的接口。例如，如果您只希望客户端迭代集合，则返回 IEnumerable。至于您的具体问题，我觉得
ICollection有点无用，因为它缺少索引器。You really should only return the interface that meets the goals you set when designing your API. For example if you only expect your clients to iterate over a collection then return
IEnumerable<T>. As to your specific question I feelICollection<T>is kind of useless as it lacks an indexer.这个更好可能不适用于性能，而仅适用于返回类型的类型。
在这种情况下，很难说哪个更好，在我看来，依赖于方法“localy”的使用更好地返回我们操作的类型。
That better may not apply to the performace but only to type of the returning type.
In this case is not easy to say what is better, in my opinion that depend of the usage of method "localy" is beter to return type that we operate on.
最好的办法是公开一个强类型类，例如 CustomerCollection。这样您以后就有地方添加属性和方法。
正式来说，你不应该公开列表，但我个人认为这没有问题。
The best thing to do is expose a strongly typed class like CustomerCollection. That way you have a place to add properties and methods later.
Offically you shouldn't expose a List, but I personally see no problem with it.
返回 List 的问题是调用者可以修改它。如果您想连接一些通知机制（“每当调用者向其添加新对象时通知被调用者”），您不能，因为 List 是一个死胡同。
返回 Collection/ICollection 允许您创建自己的实现，其中包含您想要的任何内容。
基本上，列表意味着您被困在一个角落，如果不进行重大更改就无法逃脱。
所以 Collection/ICollection/IList 是更好的选择。
请参阅此问题和本文。
The problem with returning a List is that the caller can modify it. If you would ever like to wire up some notification mechanism ("Notify the callee whenever the caller adds a new object to it"), you can't as a List is a dead end.
Returning a Collection/ICollection allows you to create your own implementation that has whatever you want.
Basically, a List means that you're stuck in a corner that you can't escape without a breaking change.
So Collection/ICollection/IList is preferable.
Please see this question and this article.