The reason why Collection<T>, ReadOnlyCollection<T>, and KeyedCollection<TKey,TValue> were moved to System.Collections.ObjectModel namespace
Avevo letto questo post un po’ di tempo fa. Ci sono ricapitato l’altro giorno e mi sono deciso a postarlo.
Quando abbiamo a che fare con le nuove collection del .NET Framework, una delle cose che saltano subito all’occhio è che alcune di esse “non sono dove dovrebbero essere”, ossia nel namespace System.Collection.Generics, ma nel namespace System.Collection.ObjectModel.
Di seguito la chiarissima spiegazione fatta direttamente da Cwalina:
Several people asked me why Collection<T>, ReadOnlyCollection<T>, and KeyedCollection<TKey,TValue> were moved to System.Collections.ObjectModel namespace. Here are the two main reasons:
1. Microsoft.VisualBasic namespace contains a non-generic type called Collection. The namespace is imported by default by the VB project template and we were afraid that it would confuse developers who import System.Collections.Generic namespace as well and would see two types called ‘Collection’ in their intellisense (given one of them generic, but still). We were faced with either renaming Collection<T> to something else or moving it to another namespace. We really did not want to rename it because Collection<T> is just the best name for the type (with not many good alternatives) and it will show in many APIs.
2. We also thought that not many people will need to declare variables of thses types. Most developer who will directly use (instantiate) the collections are framework (object model) designers. Developers writing applications (majority) would simply call Directory.Files.Count for example (and not even realize it’s a Collection<FilerInfo>) or they will/should use List<T> instead. Having said that, recently I started to be concerned that some people will have to declare Collection<X> variables to cache collection instances they get from APIs, but I have not received any substantial feedback on this. BTW, this will be mitigated by many APIs actually returning subclasses of Collection<X> instead of the base class.
Some people also commented that the name “ObjectModel” is a bit “kooky” (direct quote). I have received some feedback (not much but some) about it from customers, but I think the main issue is that the term is so overloaded and many people mean many different things when they say “object model”. Anyway, we would probably try to come up with some less controversial name if we were in the design phase today, but it’s kind of late in the product cycle now to make such changes.