DDD "Ver objetos"?

Question

Dada una aplicación que implique, por ejemplo, empresas, podría tener una clase de empresa. Tendré una capa de acceso a datos que rellena una lista <Company>. Sin embargo, habrá momentos (como mostrar un resultado de búsqueda) donde solo necesito mostrar el nombre de la empresa, el teléfono y las propiedades del código postal, y me parece que ocupar todo el objeto de la Compañía con todas sus propiedades parece un desperdicio.

¿Cuál sería la forma correcta de hacerlo en términos de un diseño DDD? ¿Crearía clases específicas de View, como un objeto CompanySearchResult que solo expone las propiedades que estoy interesado en mostrar?

Answer 1

Eso suena como un enfoque razonable para mí.

Más adelante, si el cliente es lo que le pide su SearchResult para mostrar algo no relacionado con el modelo Company - algo loco como el número de heladerías cercanas tendrá un tiempo mucho más fácil añadiendo esto a su CompanySearchResult de su objeto de dominio

Answer 2

Uso una migaja de los atributos de entidad. Por ejemplo:

// interface for "ID" attribute of Company entity 
public interface ICompany_ID { 
    Guid CompanyID{get;set;} 
} 
// interface for "Name" attribute of Company entity 
public interace ICompany_Name { 
    string Name{get;set;} 
} 
// interface for "Logo" attribute of Company entity 
public interface ICompany_Logo { 
    byte[] Logo{get;set;} 
} 

// interface for all attributes of Company entity 
public interface ICompany : ICompany_ID, ICompany_Name, ICompany_Logo { } 

// base class for classes based on Company entity 
public abstract class CompanyBase : ICompany_ID { 
    // implementation of ICompany_ID interface 
} 

// class for all attributes of Company entity 
public class Company : ICompany { 
    // implementation of ICompany interface (all attributes) 
} 

// class for Company name lookup 
public class CompanyNameLookup : CompanyBase, ICompany_Name { 
    // implementation of ICompany_Name interfade 
} 

Este crumble me permite trabajar con diferentes atributos de diferentes entidades y todo es seguro. sin embargo, su capa de datos debe admitir este escenario.

La siguiente forma es la creación dinámica de clases de búsqueda, pero es mucho más compleja. Por otro lado, es mucho más flexible.

EDIT: entonces la selección puede ser por ejemplo:

var companies = (from c in db.Table<ICompany>() 
       order by c.Name 
       select new CompanyNameLookup { ID = c.ID, Name = c.Name } 
       ).ToList(); 

o para tipos danymicly creados:

var companies = (from c in db.Table<ICompany>() 
       order by c.Name 
       select DynamicTypeFactory.New<ICompany_ID>(c.Id).And<ICompany_Name>(c.Name).Create() 
       ).ToList(); 

El DynamicTypeFactory es la clase con método estático New y la interfaz de fluido para danymic clases de creación en tiempo de ejecución.

Answer 3

Esto es lo que normalmente se conoce como un "modelo de vista" o un objeto de transferencia de datos. Es posible que no desee que su vista tenga acceso a todo el árbol de datos expuesto por su modelo de dominio. Especialmente si exponer su modelo de dominio significa que su vista tendrá que profundizar en su gráfico de objetos para extraer los datos que necesita, un Modelo de visualización puede tener mucho sentido para simplificar el trabajo con los objetos del modelo. En su caso, si simplemente está quitando propiedades directas del objeto modelo, tendría sentido si desea ocultar los datos extraños que no necesita el resto de su modelo de dominio.

Answer 4

El enfoque que sugiere puede aumentar rápidamente el número de DAO: s que necesita crear y convertirse en una pesadilla de mantenimiento. El enfoque que varios ORM tomar es aproximar el acceso a los datos, por lo que su capa de acceso de datos devolverá una lista de interfaces, y la llamada base de datos se pospondrá hasta que invoque el descriptor de acceso de datos, por ejemplo

list.getCompany(1).getName()

. Esto se llama carga lenta. Todavía tendrá que hacer una transacción entre hacer muchas consultas grandes o pequeñas. Este tipo de tareas es uno de los puntos fuertes de los ORM, por lo general, puede solicitarle a su ORM que realice una captación previa de las partes del gráfico de objetos que crea que se utilizarán y omita otras partes.