¿Por qué se necesita "Reparación" para Persistencia Ignorante POCO en EF 4?

Question

Una de las funciones más esperadas de Entity Framework 4 es la capacidad de utilizar POCO (Objetos Clair Old CLR) de una manera Ignorante de persistencia (es decir, no "saben" que se persisten con Entity Framework vs. otro mecanismo).

Estoy tratando de entender por qué es necesario realizar correcciones de asociación y utilizar FixupCollection en mi objeto comercial "simple". Ese requisito parece implicar que el objeto comercial no puede ignorar por completo el mecanismo de persistencia después de todo (de hecho, la palabra "corrección" parece que algo necesita ser arreglado/alterado para funcionar con el mecanismo de persistencia elegido).

Específicamente me refiero a la región Asociación Fixup que se genera por el ADO.NET POCO Entidad Generador, por ejemplo .:

#region Association Fixup 

    private void FixupImportFile(ImportFile previousValue) 
    { 
     if (previousValue != null && previousValue.Participants.Contains(this)) 
     { 
      previousValue.Participants.Remove(this); 
     } 

     if (ImportFile != null) 
     { 
      if (!ImportFile.Participants.Contains(this)) 
      { 
       ImportFile.Participants.Add(this); 
      } 
      if (ImportFileId != ImportFile.Id) 
      { 
       ImportFileId = ImportFile.Id; 
      } 
     } 
    } 

    #endregion 

, así como el uso de FixupCollection. Otros ORM persistentes e ignorantes no tienen restricciones similares.

¿Esto se debe a decisiones de diseño fundamentales en EF? ¿Hay algún nivel de no ignorancia aquí para permanecer incluso en versiones posteriores de EF? ¿Existe alguna forma inteligente de ocultar esta dependencia de persistencia del desarrollador de POCO?

¿Cómo funciona esto en la práctica, de principio a fin? Por ejemplo, entiendo que recientemente se agregó soporte para ObservableCollection (que es necesario para Silverlight y WPF). ¿Hay errores en otras capas de software a partir de los requisitos de diseño de los objetos POCO compatibles con EF?

Answer 1

Encontré algunas explicaciones: ¡compruébalo!

POCO Template Code Generation Options (blog del equipo EF)

Fixup

Un método de corrección está escrito para cada propiedad navegación en una entidad y se llama desde el colocador de la propiedad de navegación siempre que su valor cambios. Su propósito es garantizar que cada extremo de una relación bidireccional se mantenga sincronizada con la otra. Por ejemplo, en una relación de uno a muchos entre Cutomer y Orden, cada vez que se establece Order.Customer, método de la corrección asegura que la Orden está en los pedidos del cliente de recogida. También mantiene la propiedad de clave foránea correspondiente a saber. Order.CustomerID en sincronización con el nuevo valor de clave principal (ID) del cliente. Esta lógica puede ser útil si las entidades POCO se utilizan independientemente de la pila EF , como para escribir pruebas contra ellas que no afectan a la base de datos . La reparación se asegura de que el gráfico de objetos esté conectado de la misma manera como se esperaría al usar con EF. Los métodos de reparación son un poco complejo para escribir y, por lo tanto, es útil para tenerlos generados automáticamente si está planeando usar las entidades en un escenario independiente de EF.

Y también mira esto POCO in the Entity Framework Part 1 que también tiene algunas secciones sobre qué correcciones son y para qué se necesitan.