WCF - Objetos de dominio e IExtensibleDataObject

Question

Escenario típico. Utilizamos los servicios web XML de la vieja escuela internamente para la comunicación entre una granja de servidores y varios clientes locales y distribuidos. No participan terceros, solo nuestras aplicaciones las utilizamos nosotros y nuestros clientes.

Actualmente estamos pensando en pasar de XML WS a un modelo WCF/basado en objetos y hemos estado experimentando con varios enfoques. Uno de ellos implica transferir los objetos de dominio/agregados directamente sobre el cable, posiblemente invocando los atributos de DataContract en ellos.

Al usar IExtensibleDataObject y un DataContract usando la propiedad Order en los DataMembers, deberíamos poder hacer frente a problemas simples de control de versiones de propiedades (recuerde, controlamos todos los clientes y podemos forzarlos a actualizarlos fácilmente).

Sigo oyendo que debemos usar Objetos de Transferencia de Datos (DTO) dedicados y de solo transferencia a través del cable.

¿Por qué? ¿Todavía hay una razón para hacerlo? Usamos el mismo modelo de dominio del lado del servidor y del lado del cliente, por supuesto, el llenado de colecciones, etc. solo cuando se considera correcto y "necesario". Las propiedades de recopilación utilizan el principio de localizador de servicios e IoC para invocar un "servicio" basado en NHibernate para obtener datos directamente (en el lado del servidor) y un cliente de "servicio" WCF en el lado del cliente para hablar con la granja de servidores WCF.

Entonces, ¿por qué tenemos que usar DTO?

Answer 1

En mi experiencia DTO son más útiles para:

1. estrictamente la definición de lo que se enviará a través del cable y tener un tipo dedicado específicamente a esa definición.
2. Aislando el resto de su aplicación, cliente y servidor, de futuros cambios.
3. Interoperabilidad con sistemas que no sean .Net. Los DTO ciertamente no son un requisito, pero hacen que sea más fácil diseñar tipos "seguros".

En su escenario, estas características de diseño pueden no importar mucho. Utilicé WCF con DTO estrictos y objetos de dominio compartidos y en ambos casos funcionó de maravilla. Lo único que noté al enviar objetos de dominio a través del cable fue que tendía a enviar más datos (y de maneras inesperadas) luego lo necesitaba. Probablemente esto se debió más a mi falta de experiencia con WCF que a cualquier otra cosa; pero es algo de lo que definitivamente deberías desconfiar si eliges seguir ese camino.

Answer 2

Habiendo trabajado con ambos enfoques (objetos de dominio compartido y DTO) diría que el gran problema con los objetos de dominio compartido es cuando no se controlan todos los clientes, pero de mis experiencias pasadas solía usar DTO a menos que la velocidad de desarrollo era esencial.

Si hay alguna posibilidad de que no siempre controle a los clientes, definitivamente recomendaría los DTO, porque tan pronto como comparte los objetos de su dominio con la aplicación cliente de otra persona, comienza a atar sus partes internas a la de otra persona ciclo de desarrollo

También encontré DTO útiles cuando trabajé en un entorno de servicio versionado, lo que nos permitió cambiar radicalmente el funcionamiento interno de nuestra aplicación, pero aún aceptamos llamadas a las versiones anteriores de nuestras interfaces de servicio.

Finalmente, si tiene muchas aplicaciones cliente, también podría ser beneficioso usar DTO ya que está protegido con un servicio fácilmente versionable.