WCF-Domain Objects y IExtensibleDataObject

serialization soap

Question

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

Actualmente estamos reflexionando sobre 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).

Sigo oyendo que deberíamos 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? Utilizamos el mismo modelo de dominio en el 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, los DTO son más útiles para:

1. Definir estrictamente lo que se enviará por cable y tener un tipo dedicado específicamente a esa definición.
2. Aislar 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 compartidos es cuando no controlas a todos los clientes, pero por mis experiencias pasadas solía usar DTOs a menos que la velocidad de desarrollo fuera de la esencia.

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

También encontré DTO útiles cuando trabajé en un entorno de servicio versionado, lo que nos permitió cambiar radicalmente las funciones internas 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 entonces está protegido con un servicio fácilmente versátil.