Vermeiden Sie Zirkelverweis in Domain-Modell

Question

Dies muss ein so häufiges Szenario sein, dass schon viel darüber geschrieben wurde, hoffentlich sogar ein wirklich gutes Muster. Ich habe ein Domänenmodell, in dem ein benutzerdefinierter Container Entitäten enthält. Zum Beispiel (Eigenschaften und Schnittstellen der Kürze halber nicht inbegriffen):

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); 

    } 
} 

kann ich jetzt meine Objektgraphen leicht in beide Richtungen durchlaufen, haben aber einen zirkulären Verweis erstellt. Würden Sie einen dritten Typ erstellen, um die Abhängigkeiten zu trennen?

Vielen Dank im Voraus

Answer 1

Es ist nichts falsch mit zirkulären Referenzen, per se, und sie werden in großem Umfang in denen verwendet .NET Framework, z XmlNode.OwnerDocument, Control.Parent.

Wenn Sie den Baum nach oben durchlaufen müssen, können Sie einen Rückverweis verwenden.

In COM sind Zirkelverweise schwierig, denn wenn Sie den Container und alle seine untergeordneten Elemente auf nichts festlegen, werden Objekte nicht ordnungsgemäß bereinigt, da die untergeordneten Elemente weiterhin Verweise auf das übergeordnete Element enthalten. Die .NET Garbage Collection hat jedoch kein Problem damit, wie es implementiert ist.

Answer 2

Braucht der Behälter über den Typ des Inhalts wissen? Wenn nicht, können Generika dies vermeiden - d. H. Container<T>, wo Sie Container<Entity> verwenden können, um zu verwenden. Andere als das; Die erforderlichen Details in eine Schnittstelle (oder Basisklasse) in einer Baugruppe zu übertragen, auf die beide verweisen können, ist ein üblicher Ansatz.

Persönlich würde ich versuchen, einfach die Notwendigkeit für das Kind zu vermeiden, über den Elternteil zu wissen.

Auch; Beachten Sie, dass wenn Sie tun gehen Sie die Abstraktion (Schnittstelle usw.) Route; Dies kann große Auswirkungen haben, wenn Sie beispielsweise die XML-Serialisierung verwenden.

---

(Kommentare bearbeiten) OK; Erstens: Welches Problem verursacht die zirkuläre Referenz (innerhalb einer Baugruppe)? wenn nicht, lass es in Ruhe. Wenn ein Problem auftritt, benötigen Sie einen zusätzlichen Typ. vermutlich einige Schnittstellen, die konkreten Typen darzustellen - also dort, wo Entity : IEntity und EntityContainer nur etwa IEntity (oder vv mit IEntityContainer oder beides) wissen,

Answer 3

Da sehe ich kein Problem mit Ihrem Klassenmodell, aber Sie könnten leicht einen sauberen Schnitt machen. Stellen Sie Entity eine Schnittstelle IEntity implementieren und EntityContainer halten eine IList und wenn Sie einen ganz bestimmten Grund für die Verwendung von IList haben, sollten Sie IEnumerable betrachten, Es würde es für den Verbraucher der EntityClass, die Sie verwenden, einfach. Seit dem Übergeben eines beliebigen Feldes von IEntity oder eines linq-Ausdrucks ist die Auswahl von IEntitäten möglich.

Answer 4

Die Verwendung zirkulärer referenzierter Objekte ist in meinem Buch in Ordnung, vorausgesetzt, Sie verwenden beim Entwerfen dieser Objekte eine Art Lazy-Loading-Muster.

z.B.

Sie wollen Zugang: Company.Employee Und in einem anderen Szenario: Mitarbeiter.Firma

Welche d.h. Company.Employee.Company.Employee usw.

eine kreisförmige Referenzvoll ist, wenn diese Eigenschaften nicht lazy z.B. belastetes sind Ein Unternehmensobjekt lädt immer seine Employee-Eigenschaft, und das Employee-Objekt lädt immer seine Company-Eigenschaft, dann wird es nicht zu gut funktionieren, wenn Sie eine Datenquelle einführen.