c# - deserializar - el atributo contract no es valido

Cómo organizar y nombrar los DTO que se utilizan como contratos de datos en un servicio web de WCF

Question

Estamos utilizando DTO como Contratos de Datos en nuestro servicio web WCF. El propósito de estos DTO es exponer solo la información que es relevante para un método API específico.

Lo que estoy buscando de ustedes es un consejo sobre las mejores prácticas aquí.

Por ejemplo, considere el siguiente modelo simple:

class Order
{
    int CreatedBy { get; set; }
    DateTime CreatedOn { get; set; }
    string Description { get; set; }
    int Id { get; set; }
    string Name { get; set; }
}

Suponiendo que nuestra API permite que un consumidor cree, actualice y obtenga un pedido, hemos creado los siguientes DTO. Los atributos DataMember y DataContract se eliminan por simplicidad.

Método de creación : un usuario no puede especificar las propiedades Id y CreatedOn , por lo que el DTO se ve así:

class CreateOrderData
{
    int CreatedBy { get; set; }
    string Description { get; set; }
    string Name { get; set; }
}

Método de actualización : un usuario no puede especificar las propiedades Id , CreatedOn y CreatedBy , por lo que el DTO tiene este aspecto:

class UpdateOrderData
{
    string Description { get; set; }
    string Name { get; set; }
}

Método de obtención : un usuario debe poder ver todo para el pedido, para que el DTO tenga este aspecto:

class OrderData
{
    int CreatedBy { get; set; }
    DateTime CreatedOn { get; set; }
    string Description { get; set; }
    int Id { get; set; }
    string Name { get; set; }
}

Asi que aqui están mis preguntas:

• Suponiendo que hay más propiedades en el modelo de pedido y muchas de esas propiedades se comparten entre los DTO "Crear" y "Actualizar", ¿tiene sentido que estas clases se extiendan desde una clase base común? En caso afirmativo, ¿debería extenderse también el DTO "Obtener" (OrderData) de esa clase? Si hacemos eso, ¿no dejan estos DTOs demasiado dependientes unos de otros?

• Si todas las propiedades son comunes entre los DTO "Crear" y "Actualizar", ¿deberíamos seguir creando dos DTO diferentes? ¿Si es así por qué? De lo contrario, (ahora es solo una pregunta de nomenclatura) ¿a qué debería llamarse el DTO "CreateOrUpdate" para que el nombre sea obviamente diferente del DTO "Get"?

• ¿Está bien el sufijo de todos los DTO con algo como "Data" o "DataObject" o "Dto"?

• ¿Estamos en el camino correcto aquí? Si no, ¿cómo se puede mejorar este diseño?

Actualizar:

Creo que no me gusta la herencia en DTO porque la clase base también estará expuesta en el WSDL y el cliente podrá verla e instanciarla, lo que me parece sucio (vea esto: ¿ Serialización de WCF con herencia de objeto? ) . ¿Qué le parece usar Interfaces en DTO para imponer propiedades comunes en lugar de la herencia? Como los DTO no deben tener ningún comportamiento en ellos, no estamos perdiendo mucho al reemplazar la herencia.

Answer 1

Ya que esto es mucho sobre preferencias personales, yo haría esto ...

1. No crearía una clase base común ya que no se adheriría a L en SOLID. Si le preocupa DRY, podría crear una agregación.

2. Si todas las propiedades son comunes, entonces tiene sentido crear un Guardar que tome ese objeto, la orden Dto clase tendrá una propiedad (es) clave que indicaría si es un orden existente o no.

3. Solucionaré todo con Dto, porque muchos de los nombres de clase Dto son iguales a las clases de dominio, se vuelven confusos ya que estarán juntos en el mismo método. Luego, puede decorar sus Dtos con DataContract (Name = "Order", Namespace = "htp: // yourdomain / .."]. De esta manera, estarán expuestos al mundo exterior de acuerdo con sus propias preferencias.

He estado en varios proyectos que usan la misma arquitectura general, generalmente uso AutoMapper para asignar dtos a dominio. ¡Ha funcionado muy bien para mí!