serializar - wcf datacontract example

WCF DataContracts y estructuras de datos subyacentes

Question

Me pregunto qué tiene sentido en relación con qué objetos exponer a través de un servicio WCF. ¿Debería agregar las especificaciones de Serialización de WCF a mis entidades comerciales o implementar un convertidor que correlacione mis entidades comerciales con los DataContracts que quiero exponer a través de mi WCF? ¿Servicio?

En este momento tengo entidades en diferentes niveles: DataAccess, Business y Contract. Tengo conversores en el lugar que pueden mapear entidades de DataAccess a Business y de Business a Contract y viceversa. Implementarlos y mantenerlos consume mucho tiempo y es bastante tedioso. ¿Cuáles son las mejores prácticas en relación con esto?

Si estuviera usando un OR / M como NHibernate o Entity Framework ¿debería exponer directamente las entidades del ORM o debería abstraerlas de la misma manera que lo estoy haciendo ahora?

Gracias por adelantado.

Answer 1

En general, creo que desde el punto de vista de las mejores prácticas, no debe exponer la estructura de sus objetos comerciales como contratos de datos, sino definir las clases "específicas del contrato de datos" y convertir Business to Contract. Puede requerir trabajo adicional, pero a partir de una separación de preocupaciones y protección del punto de vista del cambio, el trabajo adicional probablemente valga la pena.

Los patrones y prácticas de Microsoft "Service Factory Modeling Edition" implementa esto, y también proporciona herramientas para autogenerar clases de convertidores de negocios <=> Contract - es un excelente complemento de VS, y también representa las mejores prácticas de Microsoft para WCF.

Answer 2

Normalmente no expongo mis negocios / entidades de datos a través del cable, ya que me gusta adherirme al principio de responsabilidad única (srp). Para explicar, las entidades de datos se crearon para mapear al modelo relacional (db) subyacente. Entonces, la única razón por la que deberían "cambiar" es por un cambio en el modelo relacional, eso es todo.

En el momento en que expone esas entidades para que puedan cruzar el cable, entonces están cumpliendo dos propósitos. Puede parecer exagerado, pero mantiene las cosas más limpias y transparentes ... lo que permite un diseño más simple.

Answer 3

Solo para agregar a las respuestas anteriores: El objeto que el servicio web expone se llama Objeto de transferencia de datos (DTO). Tener un DTO para mapear su Objeto de Entidad Comercial (BEO) es bueno debido a la separación que proporciona entre su servicio web y la implementación / lógica real que se encuentra detrás del servicio web.

Finalmente, aquí está cómo puede decorar el DTO para que cuando sea expuesto por el WSDL los nombres reflejen los objetos reales que representa (en lugar de objectNameDTO o algo así de feo).

//Business Entity
class Person
{
   public string Name{ get; set; }
   public int Age{ get; set; }
}


//Data transfer object
[DataContract(Name="Person")] //<-- this is what makes the WSDL look nice and clean
class PersonDTO
{
   [DataMember(Name = "Name", Order = 0)]
   public string Name{ get; set; }
   [DataMember(Name = "Age", Order = 1)]
   public int Age{ get; set; }
}

Answer 4

Algo que también debe tenerse en cuenta, estoy de acuerdo con la separación, pero generalmente termina conduciendo a "traductores" o algún código similar para copiar los datos del DTO a la entidad comercial. Aquí es donde una biblioteca como AutoMapper ( http://automapper.org/ ) resulta realmente útil y elimina la necesidad de escribir la capa de traducción.