6

Considere el siguiente código (que se ha simplificado). Tengo una clase de servicio que devuelve una lista de objetos DTO específicos que cada uno implementa su propia interfaz específica. En el código actual, estos se están poblando al iterar a través de un Dataset, ya que estoy trabajando con el código heredado.Inyección de dependencia: ¿se usa con objetos de transferencia de datos (DTO)?

Preguntas:

  1. ¿Cómo podemos crear/usar un DTO sin Newing hacia arriba o utilizando el anti-patrón Service Locator? No tiene mucho sentido componer un objeto DTO vacío en Composition Root e inyectarlo en la clase Service a través del constructor, porque en realidad estaría utilizando el DTO como una variable temporal de tipo al completar una lista.

  2. En el código puede ver un ejemplo de cómo estoy actualizando el DTO. Pero esto no se siente mucho mejor que que si hubiera hecho que los DTO no implementaran interfaces en primer lugar. Entonces, ¿no deberían implementar interfaces entonces y por lo tanto, no usar DI con DTO?


public class Services : IServices 
{  
    public IList<IDTO> GetDTOs() 
    {  
     ... 
     List<IDTO> dtos = new List<IDTO>(); 
     foreach (c in d) 
     { 
      DTO dto = new DTO(); 
      dto.x = c.x; 
      dto.y = c.y; 
      dto.z = c.z; 
      dtos.Add(dto); 
     } 
     return dtos; 
    }  
} 
+0

relacionados: http://stackoverflow.com/questions/4835046/why-not-use-an-ioc-container-to-resolve-dependencies-for-entities-business-objec –

+0

duplicado con respuestas interesantes: http://stackoverflow.com/questions/8135894/c-sharp- dto-constructor-and-dependency-injection/8136059 # 8136059 –

Respuesta

12

que no tiene mucho sentido para mí utilizar cualquier DI para dtos. Probablemente usaría Factory Pattern para obtener DTO para mis objetos modelo.

Los DTO no necesitan su ciclo de vida administrado por el contenedor; Solo los llamaría new. No sobre-ingeniero.

8

No creo que los DTO implementen interfaces, porque es probable que no implementen un comportamiento que cambie.

Tampoco se deben inyectar. No todos los objetos deberían ser Creo que esta es una llamada apropiada a lo nuevo: crear el objeto, usarlo, dejarlo fuera del alcance y ser GC.

1

Eche un vistazo a AutoMapper. Y estoy de acuerdo con @duffymo, no usaría interfaces con DTO. AutoMapper es un objeto basado en convenciones para mapeador de objetos que creará y poblará sus DTO por usted. Si nada más te ahorrará un montón de tipeo. He pasado por el ejercicio de escribir rutinas de conversión a/desde DTO con errores tipográficos asociados. Ojalá hubiera encontrado AutoMapper un poco antes. En el caso de que su ejemplo (donde he hecho nominalmente "de" objeto de tipo de pedido):

public class Services : IServices 
{  
    public IList<DTO> GetDTOs() 
    {  
     ... 
     Mapper.CreateMap<Order, DTO>(); // move map creation to startup routine 
     var dtos = new List<DTO>(); 
     foreach (c in d) 
     { 
      dtos.Add(Mapper.Map<Order, DTO>(c)); 
     } 
     return dtos; 
    } 
} 

O usando LINQ

public class Services : IServices 
{  
    public IList<DTO> GetDTOs() 
    {  
     ... 
     Mapper.CreateMap<Order, DTO>(); // move map creation to startup routine 
     return d.Select(c => Mapper.Map<Order, DTO>(c)).ToList(); 
    } 
} 
+1

+1 Buena respuesta. Sin embargo, debería utilizar el soporte integrado de AM para mapear matrices, es decir, puede 'Mapper.Map (xs)'. No estoy seguro si un IList es a) necesario b) apoyó a OOTB por AM, pero si lo hiciera obv ToList haría lo necesario –

Cuestiones relacionadas