Question

I have a class Customer (with typical customer properties) and I need to pass around, and databind, a ‘chunk’ of Customer instances. Currently I’m using an array of Customer, but I’ve also used Collection of T (and List of T before I knew about Collection of T). I’d like the thinnest way to pass this chunk around using C# and .NET 3.5.

Currently, the array of Customer is working just fine for me. It data binds well and seems to be as lightweight as it gets. I don’t need the stuff List of T offers and Collection of T still seems like overkill. The array does require that I know ahead of time how many Customers I’m adding to the chunk, but I always know that in advance (given rows in a page, for example).

Am I missing something fundamental or is the array of Customer OK? Is there a tradeoff I’m missing?

Also, I’m assuming that Collection of T makes the old loosely-typed ArrayList obsolete. Am I right there?

Answer 1

No one has mentioned the Framework Guidelines advice: Don’t use List<T> in public API’s:

We don’t recommend using List in public APIs for two reasons.

• List<T> is not designed to be extended. i.e. you cannot override any members. This for example means that an object returning List<T> from a property won’t be able to get notified when the collection is modified. Collection<T> lets you overrides SetItem protected member to get “notified” when a new items is added or an existing item is changed.

• List has lots of members that are not relevant in many scenarios. We say that List<T> is too “busy” for public object models. Imagine ListView.Items property returning List<T> with all its richness. Now, look at the actual ListView.Items return type; it’s way simpler and similar to Collection<T> or ReadOnlyCollection<T>

Also, if your goal is two-way Databinding, have a look at BindingList<T> (with the caveat that it is not sortable ‘out of the box’!)