2012-05-31 14 views
7

Necesito crear algunas clases de DTO para transportar nuestros objetos comerciales a través de WCF.DTOs. Propiedades o campos?

Dado que se trata de bolsas de datos sin funcionalidad, ¿hay algún motivo por el que no pueda utilizar los campos, o hay alguna buena razón para exponerlos correctamente como propiedades?

//fields 
[DataContract] 
class CustomerDTO 
{ 
    [DataMember] public int  Id; 
    [DataMember] public string Name; 
} 

//or properties? 
[DataContract] 
class CustomerDTO 
{ 
    [DataMember] public int Id    { get; set; } 
    [DataMember] public string Name    { get; set; } 
} 

Respuesta

4

Dado que estos son sólo bolsas de datos con ninguna funcionalidad, ¿hay alguna razón por la que no puedo utilizar campos

No hay argumentos fuertes en contra de campos públicos aquí. Pero se dan cuenta de que es solo porque no hay lógica (comportamiento) dentro de los DTO, por lo que el argumento normal de encapsulación no se cumple.

Todavía preferiría propiedades pero en realidad no son necesarias aquí.

+0

Gracias chicos. Utilizará propiedades puramente por coherencia. – GazTheDestroyer

0

Nunca exponer campos directamente, la mayoría de las empresas prohíben esto en sus estándares. Efectivamente descartas por completo la encapsulación. Los DTO, que son representaciones anémicas de algo más complejo, son un caso extraño ya que sus propiedades prácticamente rompen la encapsulación de todos modos. Personalmente, utilizaría las propiedades ya que es para lo que están allí. También le permite implementar funcionalidades "sucias", etc. si lo necesita, lo cual no es tan fácil si está retocando campos directamente.

+0

Un problema con las propiedades es que si una propiedad tiene un tipo de estructura, el acceso a cualquier parte de esa estructura requerirá hacer una copia temporal adicional de todo. Tales operaciones de copia desperdiciadas no son necesarias cuando se expone un campo de estructura. – supercat

2

El atributo DataMember funcionará con los campos públicos y las propiedades, por lo que sería posible. Sin embargo, recomendaría seguir con las propiedades.

En particular, si está utilizando StyleCop, estaría rompiendo rule SA1401.

El motivo de la existencia de esta regla en realidad no se aplica en su caso, pero seguiría siendo un problema de mantenimiento si está ejecutando la validación de StyleCop como parte de una compilación en un servidor de integración continua.

+3

Si la solución coloca estas DTO en una ubicación específica, se puede tener una anulación stylecop en esta regla específica, solo para esa ubicación. – Oded

+0

De hecho, pero eso todavía es un problema de mantenimiento que debe ser resuelto. – devdigital

1

Puede usar cualquiera. Como no afecta el rendimiento, estarás más seguro yendo con propiedades en caso de que te topes con algún marco de serialización o similar que no funcione con campos públicos.

Tenga en cuenta que la generación de proxy WCF creará esos dtos en el lado del cliente con propiedades públicas y privadas que respaldan sus campos, incluso si utiliza campos públicos en el lado del servicio. Si de alguna manera no quiere eso, necesita compartir una biblioteca DTO entre el servicio y el cliente.

Cuestiones relacionadas