2010-06-13 24 views
6

Tengo una jerarquía bastante profunda de objetos que trato de persistir con Entity Framework 4, POCO, PI (Persistencia Ignorancia) y Code First. De repente las cosas comenzaron a funcionar bastante bien cuando me di cuenta de que no usaba el operador new(). Tal como se escribió originalmente, los objetos frecuentemente usan new() para crear objetos secundarios.Entity Framework 4 Código Primero y el nuevo() Operador

En su lugar estoy usando mi versión en el Patrón de repositorio para crear todos los objetos secundarios según sea necesario. Por ejemplo, dado:

class Adam 
{ 
    List<Child> children; 
    void AddChildGivenInput(string input) { children.Add(new Child(...)); } 
} 

class Child 
{ 
    List<GrandChild> grandchildren; 
    void AddGrandChildGivenInput(string input) { grandchildren.Add(new GrandChild(...)); } 
} 

class GrandChild 
{ 
} 

("GivenInput" implica algún tipo de procesamiento que no se muestra aquí)

defino como un AdamRepository:

class AdamRepository 
{ 
    Adam Add() 
    { 
     return objectContext.Create<Adam>(); 
    } 
    Child AddChildGivenInput(Adam adam, string input) 
    { 
     return adam.children.Add(new Child(...)); 
    } 
    GrandChild AddGrandchildGivenInput(Child child, string input) 
    { 
     return child.grandchildren.Add(new GrandChild(...)); 
    } 
} 

Ahora, esto funciona bastante bien. Sin embargo, ya no soy "ignorante" de mi mecanismo de persistencia ya que he abandonado el operador new().

Además, estoy en riesgo de anemic domain model ya que mucha lógica termina en el repositorio en lugar de en los objetos del dominio.

Después de mucha adiós, una pregunta:

O más bien varias preguntas ...

  • ¿Es este patrón requiere para trabajar con EF 4 Código de Primera?
  • ¿Hay una manera de conservar la utilización de la nueva() y siguen trabajando con EF 4/POCO/Código primero?
  • ¿Hay algún otro patrón que deje lógica en el objeto de dominio y aún funcione con EF 4/POCO/Code First?
  • ¿Esta restricción se levante en versiones posteriores del Código El primer soporte?

veces tratando de ir la ruta Persistencia La ignorancia POCO/ siente como nadar contra la corriente, otras veces se siente como nadar hasta Niagara Falls. Sin embargo, yo quiero creer ...

Respuesta

4

Aquí hay un par de puntos que podrían ayudar a responder a su pregunta:

En sus clases tiene un campo para la recogida de los niños y un método para añadir a los niños . EF en general (no solo Code First) actualmente requiere que las colecciones sean superficiales como propiedades, por lo que este patrón no es compatible actualmente. Más flexibilidad en la forma en que interactuamos con las clases es una pregunta común para EF y nuestro equipo está buscando cómo podemos apoyar esto en el momento

Usted mencionó que necesita registrar entidades explícitamente con el contexto, esto no es necesariamente el caso. En el siguiente ejemplo, si GetAdam() devuelve un objeto de Adam que se adjunta al contexto subyacente a continuación, el nuevo hijo Caín sería descubierto automáticamente por EF cuando se guarda y se inserta en la base de datos.

var adam = myAdamRepository.GetAdam();

var cain = new Child();

adam.Children.Agregar (cain);

~ Rowan

+0

Bienvenido a Stack Overflow. El problema fundamental es que realmente tengo una jerarquía de objetos profunda, donde cada nivel sabe cómo crear instancias de objetos del siguiente nivel. Mi comprensión y experiencia es que tendría que recorrer manualmente la jerarquía de objetos para adjuntar todos los objetos individualmente a un ObjectContext antes de que puedan persistir. Mi aplicación es bastante compleja, pero intentaré destilarla a un ejemplo simple y completo. No pasará hoy, sin embargo, espero que mañana. –

+1

@Eric J, eso no es lo que entendí por la respuesta de Rowan. Para mí, suena como "Si agregas algo a la colección pública de objetos relacionados, EF guardará automáticamente esa entidad incluso si no la has agregado explícitamente al ObjectContext". Esto es consistente con el comportamiento de LINQ to SQL. –

Cuestiones relacionadas