WCF - Objetos de dominio y IExtensibleDataObject

Question

Escenario típico. Utilizamos los servicios web XML de la vieja escuela internamente para comunicarnos entre una granja de servidores y varios clientes locales distribuidos y . No hay terceros involucrados, solo nuestras aplicaciones utilizadas por nosotros mismos y nuestros clientes.

Actualmente estamos considerando cambiar de XML WS a un WCF / basado en objetos y hemos estado experimentando con varios enfoques. Uno de ellos implica transferir los objetos / agregados del dominio directamente a través del cable, posiblemente invocando atributos DataContract en ellos.

Al utilizar IExtensibleDataObject y un DataContract usando la propiedad Order en DataMembers , deberíamos poder hacer frente a los problemas simples de versión de la propiedad ( recuerde, controlamos a todos los clientes y podemos actualizarlos fácilmente.

Sigo escuchando que deberíamos usar Objetos de Transferencia de Datos dedicados y de solo transferencia ( DTOs ) a través del cable.

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

Entonces, ¿por qué necesitamos usar DTOs ?

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 específicamente dedicado a esa definición.
2. Aislando el resto de su aplicación, cliente y servidor, de futuros cambios.
3. Interoperabilidad con sistemas fuera de la red. Los DTO no son un requisito, pero hacen que sea más fácil diseñar " seguro " tipos.

En su escenario, estas características de diseño pueden no importar mucho. He usado WCF con DTO estrictos y objetos de dominio compartidos y en ambos escenarios funcionó muy bien. 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 formas inesperadas) de lo que necesitaba. Esto probablemente se debió más a mi falta de experiencia con WCF que a cualquier otra cosa; pero es algo de lo que deberías tener cuidado si eliges ir por esa ruta.

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 controlas a todos los clientes, pero de mis experiencias pasadas, usualmente uso DTO a menos que se desarrolle La velocidad era la esencia.

Si hay alguna posibilidad de que no siempre tengas el control de los clientes, definitivamente recomendaría DTO, porque tan pronto como compartes tus objetos de dominio con la aplicación de cliente de otra persona, comenzarás a vincular sus partes internas con el de otra persona. ciclo.

También encontré a los DTO útiles cuando trabajaba en un entorno de servicio versionado, lo que nos permitió cambiar radicalmente las partes internas de nuestra aplicación, pero aún así aceptar llamadas a las versiones anteriores de nuestras interfaces de servicio.

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