Evita il riferimento circolare nel modello di dominio

Question

questo deve essere uno scenario talmente comune che è già stato scritto molto, speriamo anche in uno schema davvero valido. Ho un modello di dominio in cui un contenitore personalizzato contiene entità. Per esempio (proprietà e interfacce esclusi per brevità):

class Entity 
{ 
    public int Id; 
    public EntityContainer ParentContainer; 
} 


class EntityContainer 
{ 
    public int Id; 
    public IList<Entity> Entities = new List<Entity>(); 

    public void AddEntity(Entity entity) 
    { 
     entity.ParentContainer = this; 
     Entities.Add(entity); 
    } 
} 


class Main 
{ 
    public Main() 
    { 
     Entity entity1 = new Entity(); 
     Entity entity2 = new Entity(); 
     EntityContainer entityContainer = new EntityContainer(); 
     entityContainer.AddEntity(entity1); 
     entityContainer.AddEntity(entity2); 

     // Can now traverse graph easily, e.g. 
     Console.WriteLine("entity1's parent container ID = " + entity1.ParentContainer.Id); 
     Console.WriteLine("Container contains at least this entity ID: " + entityContainer.Entities[0].Id); 

    } 
} 

posso ora facilmente attraversare mio oggetto grafico entrambi i modi, ma hanno creato un riferimento circolare. Vuoi creare un terzo tipo per divorziare dalle dipendenze?

Grazie in anticipo

Answer 1

Non c'è niente di sbagliato con i riferimenti circolari, di per sé, e sono ampiamente utilizzati nella .NET Framework, ad es XmlNode.OwnerDocument, Control.Parent.

Se è necessario attraversare l'albero, è consigliabile utilizzare un riferimento posteriore.

In COM, i riferimenti circolari sono complicati perché se si imposta il contenitore e tutti i suoi figli su nulla, gli oggetti non verranno eliminati correttamente poiché i bambini conservano ancora i riferimenti al genitore. Tuttavia, la garbage collection di .NET non ha alcun problema con il modo in cui è implementata.

Answer 2

Does il contenitore bisogno di conoscere il tipo dei contenuti? In caso contrario, i farmaci generici possono evitare questo, ad esempio Container<T>, dove succede per utilizzare Container<Entity>. Oltre a quello; spingere i dettagli necessari in un'interfaccia (o classe base) in un assieme che entrambi possono fare riferimento è un approccio comune.

Personalmente, proverei semplicemente a evitare che il bambino sappia del genitore.

Inoltre; si noti che se si do si scende alla rotta di astrazione (interfaccia ecc.); questo può avere una grande implicazione se si utilizza (per esempio) la serializzazione xml.

---

(modifica commenti) OK; primo: quale problema è il riferimento circolare (all'interno di un assieme) che causa; se nessuno, lascia stare. Se c'è un problema, allora avrai bisogno di un tipo extra; presumibilmente alcune interfacce per rappresentare i tipi concreti - cioè dove Entity : IEntity e EntityContainer conosce solo IEntity (o vv con IEntityContainer, o entrambi),

Answer 3

Come così non vedo un problema con il modello di classe, ma si potrebbe facilmente fare un taglio pulito. Fai in modo che Entity implementa un'interfaccia IEntity e fai in modo che EntityContainer tenga un IList e, a meno che tu non abbia una ragione molto specifica per usare IList, dovresti avere IEnumerable, renderebbe facile per il consumatore l'EntityClass che usi. Dal momento che passa qualsiasi array di IEntity, o l'espressione linq selezionando IEntities sarebbe possibile

Answer 4

L'utilizzo di oggetti di riferimento circolari è ok nel mio libro, purché si stia utilizzando una sorta di modello a caricamento lento durante la progettazione di tali oggetti.

ad es.

si desidera accedere: Company.Employee E in un altro scenario: dipendenti.Società

che rende un riferimento circolare cioè Company.Employee.Company.Employee ecc

Se queste proprietà non sono pigri-caricato esempio Un oggetto Company carica sempre la proprietà Employee e l'oggetto Employee carica sempre la proprietà Company, quindi non funzionerà troppo quando si introduce un'origine dati.