Pourquoi le framework d'entité a-t-il besoin d'une ICollection pour le chargement paresseux?

domain-driven-design entity-framework lazy-loading

Question

Je veux écrire une classe de domaine riche telle que

public class Product    
{    
   public IEnumerable<Photo> Photos {get; private set;}    
   public void AddPhoto(){...}    
   public void RemovePhoto(){...}
 }

Mais le framework d'entité (première approche en code V4) nécessite un type ICollection pour un chargement paresseux! Le code ci-dessus ne fonctionne plus comme prévu, car les clients peuvent contourner la méthode AddPhoto / RemovePhoto et appeler directement la méthode add sur ICollection. Ce n'est pas bien.

public class Product    
{    
   public ICollection<Photo> Photos {get; private set;} //Bad    
   public void AddPhoto(){...}    
   public void RemovePhoto(){...}    
 }

Cela devient vraiment frustrant d'essayer de mettre en œuvre DDD avec le EF4. Pourquoi ont-ils choisi ICollection pour le chargement paresseux?

Comment puis-je surmonter cela? Est-ce que NHibernate m'offre une meilleure expérience DDD?

Réponse populaire

Je pense avoir trouvé la solution ... Voir ici pour plus de détails: http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/47296641-0426-49c2-b048-bf890c6d6af2/

En gros, vous souhaitez protéger le type ICollection et l'utiliser comme collection de sauvegarde pour le 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(){...}

} 

Pour que le chargement différé fonctionne, le type doit implémenter ICollection et l'accès doit être public ou protégé.



Related

Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow
Sous licence: CC-BY-SA with attribution
Non affilié à Stack Overflow