Why we don ' t recommend using list<t> on public APIs

Do not recommend List<t> API
The reasons are as follows two points:
1. First list<t> design is not designed to be extensible, we can not re-any of its methods. This means that when we operate the list<t>, we do not
can have any notification mechanism, and Collection<t> provides a SetItem virtual method for rewriting so that we modify the member information or add members to the
When you can customize the implementation notification mechanism.
2. Secondly, there are many members of the list<t> that are associated with a lot of usage scenarios, which is what we call list<t> to expose too many member methods,
Imagine that the Items property in the ListView returns List<t>, which contains many properties. Take a look at the return type of the actual listview.items;
Simpler, similar to collection<t> or readonlycollection<t>.

Because the content of list<t> and collection<t> is more, we are interested to look under, here only collection<t> part of the fragment
It's listed.

public class collection<t>: Ilist<t>, IList, ireadonlylist<t>
{
protected virtual void ClearItems ()

protected virtual void InsertItem (int index, T item)

protected virtual void RemoveItem (int index)

protected virtual void SetItem (int index, T item)
}
And its public methods are probably only about 10, and list<t> 's public development method is roughly estimated at least 30. So obviously, you can see
, for the internal use of the system in order to facilitate,list<t> to provide more convenient operation, and performance, storage has done a lot of optimization. But if as
The API is obviously a bit too big and uncontrolled.

(Original: http://blogs.msdn.com/b/kcwalina/archive/2005/09/26/474010.aspx)