ICollection getting matrieralized to EntityCollection

Question

on beta 2 blog posting ado.net team blog it says

When either ICollection<T> or ISet<T> is used, the default collection type materialized is HashSet<T>, which among other advantages does not allow duplicate entries.

I dont find that true in all cases.  It is correct when you are using just POCO classes or lazy loading proxies. However when you use change tracking proxies 

you get an EntityCollection.. 

Is that correct?

Zeeshan

Answer 1

Hi Zeeshan,

Yes. The description in the blog post applies to "plain" POCO objects but not directly to change-tracking POCO proxy instances.

The way we deal in POCO proxies with collection navigation properties is that we set the corresponding EntityCollection<T> instances on the ICollection<T> properties at runtime and we take advantage of their change tracking abilities.

Incidentally, EntityCollection<T> uses a HashSet<T> for internal storage and so it presents similar characteristics (i.e. it doesn't allow duplicates).

As a side note, in plain POCOs you can still specify IList<T> as the property type, in which case we will materialize a List<T>. You can also make the property of any type that implements ICollection<T> and has a parameter-less constructor and we will materialize an instance of that type for you. Alternatively, you can write your class in such a way that the property getter will always return a collection instance, and it that case you can use even types without parameter-less constructors in most cases.

Hope this answers your question,
Diego

---

This posting is provided "AS IS" with no warranties, and confers no rights.