Why does the entity framework need an ICollection for lazy loading?

domain-driven-design, entity-framework, lazy-loading

Solution

I think i found the solution...See here for more details: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/47296641-0426-49c2-b048-bf890c6d6af2/

Essentially you want to make the ICollection type protected and use this as the backing collection for the public IEnumerable

public class Product
{

   // This is a mapped property
   protected virtual ICollection<Photo> _photos { get; set; }

   // This is an un-mapped property that just wraps _photos
   public IEnumerable<Photo> Photos
   {
      get  { return _photos; }
   }

   public void AddPhoto(){...}
   public void RemovePhoto(){...}

}

For lazy loading to work the type must implement ICollection and the access must be public or protected.

Problem

I want to write a rich domain class such as ``` public class Product { public IEnumerable<Photo> Photos {get; private set;} public void AddPhoto(){...} public void RemovePhoto(){...} } ``` But the entity framework (V4 code first approach) requires an ICollection type for lazy loading! The above code no longer works as designed since clients can bypass the AddPhoto / RemovePhoto method and directly call the add method on ICollection. This is not good. ``` public class Product { public ICollection<Photo> Photos {get; private set;} //Bad public void AddPhoto(){...} public void RemovePhoto(){...} } ``` It's getting really frustrating trying to implement DDD with the EF4. Why did they choose the ICollection for lazy loading? How can i overcome this? Does NHibernate offer me a better DDD experience?

Original source