Evite la referencia circular en el modelo de dominio

Question

este debe ser un escenario tan común que ya se ha escrito mucho sobre él, con suerte incluso un patrón realmente bueno. Tengo un modelo de dominio en el que un contenedor personalizado contiene entidades. Por ejemplo (propiedades e interfaces excluidos por razones de brevedad):

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

    } 
} 

ahora puedo atravesar fácilmente mi gráfico de objetos en ambos sentidos, pero han creado una referencia circular. ¿Crearías un tercer tipo para divorciar las dependencias?

Gracias de antemano

Answer 1

No hay nada malo con referencias circulares, per se, y se utilizan ampliamente en la .NET Framework, por ejemplo XmlNode.OwnerDocument, Control.Parent.

Si necesita atravesar el árbol, puede utilizar una referencia anterior.

En COM, las referencias circulares son complicadas porque si fuera el conjunto del contenedor y todos sus elementos secundarios a nada, entonces los objetos no se limpiarán correctamente ya que los niños todavía tienen referencias al elemento primario. Sin embargo, la recolección de basura .NET no tiene ningún problema con la forma en que se implementa.

Answer 2

¿El contenedor necesitan saber sobre el tipo de los contenidos? De lo contrario, los genéricos pueden evitar esto, es decir, Container<T>, donde ocurre para usar Container<Entity>. Aparte de eso; introducir los detalles necesarios en una interfaz (o clase base) en un conjunto al que ambos pueden hacer referencia es un enfoque común.

Personalmente, trataría simplemente de evitar la necesidad de que el niño sepa sobre el padre.

También; tenga en cuenta que si hace baje por la ruta de abstracción (interfaz, etc.); esto puede tener una gran implicación si está utilizando (por ejemplo) serialización xml.

---

(re) editar comentarios de OK; primero: qué problema está causando la referencia circular (dentro de un ensamblaje); si ninguno, déjalo en paz. Si hay un problema, necesitarás un tipo adicional; presumiblemente algunas interfaces para representar los tipos de hormigón - es decir, cuando Entity : IEntity y EntityContainer sólo conoce IEntity (o vv con IEntityContainer, o ambos),

Answer 3

Como tal, no veo un problema con su modelo de clase pero podría hacer un corte limpio. Haga que Entity implemente una interfaz IEntity y haga que EntityContainer contenga un IList y, a menos que tenga un motivo muy específico para usar IList, debe considerar IEnumerable, lo haría más fácil para el consumidor de la EntityClass que utiliza. Como pasar cualquier matriz de IEntity, o la expresión linq seleccionando IEntities sería posible

Answer 4

El uso de objetos de referencia circular está bien en mi libro siempre que esté utilizando algún tipo de patrón de carga diferida al diseñar esos objetos.

p. Ej.

que desea acceder: Company.Employee Y en otro escenario: Empleado.Company

Lo que hace una referencia circular es decir Company.Employee.Company.Employee etc.

Si estas propiedades no son-lazy cargado, por ejemplo, Un objeto de la Compañía siempre carga su propiedad de Empleado y el objeto Empleado siempre carga su propiedad de Compañía, entonces no va a funcionar demasiado bien cuando introduce una fuente de datos.