views:

114

answers:

5

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

+4  A: 

Collection<T> is implemented, IIRC, as a wrapper around an IList<T>, of which the default implementation is List<T>. Therefore a Collection<T> has at least one more abstraction than a List<T>, but in general this won't be a bottleneck. In fact, you might consider returning IList<T>.

Edit: here is the constructor of Collection<T>, courtesy of reflector:

public Collection()
{
    this.items = new List<T>();
}

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 using List<T> directly or via subclassing, since there are no interesting virtual methods).

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 be O(1), etc

Marc Gravell
what you mean by IIRC ? and did you see IList<T> is the best in my case ?
Space Cracker
See http://en.wiktionary.org/wiki/IIRC; and yes, unless you have a specific need to use a concrete return type, `IList<T>` is a good choice - it gives you the flexibility to use any implementation without the client having to know about it. So you can **expose** it as `IList<T>`, but return `List<T>` for now, with the freedom to substitute anything else (`Collection<T>`, `MyCustomFooCollection`, etc) later.
Marc Gravell
+2  A: 

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 feel ICollection<T> is kind of useless as it lacks an indexer.

ChaosPandion
How do you know the client only wants to iterate over the collection? Maybe they want to use it as a collection. Or perhaps just get the count. What if you later want to expose additional properties? Microsoft's Framework Design Guidelines recommend the exact opposite for these and other reasons.
Jonathan Allen
@Jonathon - Part of the problem with bloated frameworks is that the designers try and cover all use cases poorly instead of focusing on one thing well. Feel free to follow along the Microsoft guidelines blindly if you wish.
ChaosPandion
If you have an Collection<T> anyways, you do nothing to reduce bloat by only offering you client an IEnumerable. In fact you increase blost because now they have to either create their own collection or detect that you gave them one and cast it.
Jonathan Allen
A: 

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.

Vash
A: 

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.

Michael Stum
You can return AsReadOnly of the List<T>, which is an IList<T>. Of course, this thin wrapper will probably have some trivial amount of overhead.
Steven Sudit
A: 

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.

Jonathan Allen
Why not use generics?
Steven Sudit
Well CustomerCollection would inherit from ObjectModel.Collection<T>. As for List, the only version I'm aware of is List<T>.
Jonathan Allen
Well, you'd have to explicitly declare a CustomerCollection, deriving it from Collection<T>, but I'm not sure what that buys you over returning IList<T>.
Steven Sudit
What if you later want to add a "TotalDollarsSpent" property to the collection itself? You can't do that to an IList<T>.
Jonathan Allen
That's true, but it's also true that I wouldn't want to. The total is a derived value.
Steven Sudit
If you use total a lot you can make it a read-only property that encapsulates the operation.
Jonathan Allen