entity-framework - para - instalar entity framework visual studio 2017

¿Cómo lidiar con los objetos de valor en Entity Framework?

Question

¿Cómo puedo conservar los objetos de valor en Entity Framework sin contaminar mi modelo de dominio? EF (bueno, las bases de datos relacionales en general) me requieren definir una clave, que mis objetos de valor no tienen fuera de la caja, por ejemplo

public class Tag : ValueObject<Tag>
{
   private readonly string name;

   public Tag(string name)
   {
      this.name = name;
   }

   public string Name { get { return this.name; }}
}

Por otro lado, no debería abordar las preocupaciones de persistencia en el modelo. ¿Realmente se supone que debo crear otra clase que incluya todos los campos del objeto de valor más una propiedad clave y luego asignarlos entre sí? Preferiría no.

¿Hay tal vez una solución más elegante?

Answer 1

Actualmente estoy trabajando en algunos de estos mismos desafíos. Realmente no soy un fanático de agregar un Id a su clase ValueObject<T> , ya que esto le da un Id a todos los objetos de valor, ya sea que se necesiten o no, más como un objeto de valor por definición no tiene Id, es algo que hereda esa base tipo ya no será un objeto de valor en el sentido puro.

Antes de seguir adelante, observaría que un concepto clave en la codificación de DDD es que no tiene que ser DDD puro en todas partes, siempre que sepa qué concesiones está haciendo y cuáles son sus concesiones. Dicho esto, su enfoque ciertamente puede considerarse bueno, sin embargo, creo que agrega una concesión que puede no ser realmente necesaria. Principalmente, esto afecta la igualdad de sus objetos de valor. Con la adición de la identificación, dos etiquetas, incluso con el mismo nombre ya no son iguales.

Estos son mis enfoques para esta situación: primero el fácil, no realmente aplicable a lo que creo que es su problema, pero es importante. Este es el objeto de valor único en la primera parte de la respuesta de Martin.

• Convertir el objeto de valor en una propiedad de una entidad.

Siempre que su objeto de valor consista solo en propiedades de tipo simple, Entity Framework lo mapeará bien.

Por ejemplo:

    public class BlogEntry : Entity<Guid>
    {
         public String Text { get; private set; }
         public Tag Tag { get; private set; }

         // Constructors, Factories, Methods, etc
    }

Entity Framework manejará eso muy bien, lo que terminará con una tabla única de BlogEntry que consiste simplemente en:

• Carné de identidad
• Texto
• Tag_Name

Ahora me imagino que eso no es realmente lo que buscas en este caso, pero para muchos objetos de valor funciona muy bien. Uno que uso con frecuencia es un objeto de valor DateRange que consta de varias propiedades. Luego, en mis objetos de dominio simplemente tengo una propiedad de Type DateRange. EF los asigna a la tabla para el objeto de dominio en sí.

Lo ValueObject<T> porque volviendo a la concesión que hicimos al agregar Id al tipo base ValueObject<T> , a pesar de que es posible que la Id no esté incluida en la implementación concreta de su objeto de dominio, todavía está allí y aún será recogida por Entity Framework, que para esto, probablemente el caso de uso de objetos de valor más común ya no funciona tan bien.

Bien, finalmente, en tu caso específico (que también me he topado varias veces). Aquí es cómo he optado por manejar la necesidad de que una entidad contenga una lista de objetos de valor. Básicamente se reduce a expandir nuestra comprensión del dominio. Suponiendo que el objeto de valor de Etiqueta es para grabar etiquetas en una publicación de blog, la forma en que lo veo es que un BlogPost contiene una lista de PostTag con el valor de Etiqueta. Sí, es una clase más, pero no es necesario agregarla para cada objeto de valor, solo se necesita cuando se tiene una lista de objetos de valor, y creo que es mejor expresar lo que está sucediendo.

Así que aquí hay un ejemplo de cómo agregar una lista de un objeto de valor a una entidad (usando su objeto de valor de Etiqueta anterior):

    public class BlogEntry : Entity<Guid>
    {
         public String Text { get; private set; }
         public ICollection<PostTag> PostTags { get; private set; }

         // Constructors:
         private BlogEntry(Guid id) : base(id) { }
         protected BlogEntry() : this(Guid.NewGuid()) { }

         // Factories:
         public static BlogEntry Create (String text, ICollection<PostTag> tags = null)
         {
             if(tags == null) { tags = new List<PostTag>(); }
             return new BlogEntry(){ Text = text, Tags = tags };
         }        

         // Methods:
         public void AddTag(String name)
         {
             PostTags.Add(PostTag.Create(name));
         }
    }

    public class PostTag : Entity<Guid>
    {
        // Properties:
        public Tag Tag { get; private set; }
        public DateTime DateAdded { get; private set; } // Properties that aren''t relevant to the value of Tag.

        // Constructors:
        private PostTag(Guid id) : base(id) { }
        protected PostTag() : this(Guid.NewGuid()) { }

        // Factories:
        public static PostTag Create(Tag tag) 
        { 
            return new PostTag(){ Tag = tag, DateAdded = DateTime.Now };
        }

        public static PostTag Create(Tag tag, DateTime dateAdded) 
        { 
            return new PostTag(){ Tag = tag, DateAdded = dateAdded };
        }
    }

Eso permitirá que BlogEntry contenga varias etiquetas sin comprometer los objetos de valor y Entity Framework lo mapeará bien sin la necesidad de hacer nada especial.

Answer 2

Vaughn Vernon escribe sobre Objetos de valor persistente (página 248) en su excelente libro Implementing Domain-Driven Design .

ORM y objetos de valor único

La idea básica es almacenar cada uno de los atributos del Valor en columnas separadas de la fila donde se almacena su Entidad principal. Dicho de otra manera, un solo Objeto de Valor se desnormaliza en la fila de la Entidad principal. Hay ventajas al emplear la convención para nombrar las columnas para identificar claramente y estandarizar la forma en que se nombran los objetos serializados.

ORM y muchos valores respaldados por una entidad de base de datos

Un enfoque muy directo para la persistencia de una colección de instancias de valor utilizando un ORM y una base de datos relacional es tratar el tipo de valor como una entidad en el modelo de datos. (...) Para lograr esto podemos emplear un Supertipo de Capa .

Los contextos delimitados de muestra en C # se pueden encontrar aquí: https://github.com/VaughnVernon/IDDD_Samples_NET