WCF Diseño Objeto - POO vs SOA

Question

Cuál es la forma correcta de manejar los objetos de negocio polimórficos en un mundo WCF/SOAP?

Me parece que SOA y OOP están en desacuerdo entre ellos: para exponer un WSDL limpio necesita objetos concretos, por lo general, incluso sin utilizar la herencia. Por otro lado, presumiblemente en el sistema subyacente, querrá seguir el diseño correcto de OO.

¿Qué la gente suele hacer aquí? Construya un conjunto de objetos contractuales WCF, renunciando a los principios OOP, y luego conviértalos a otro conjunto de objetos en las capas lógicas reales.

Answer 1

¿Qué hace la gente normalmente aquí? Construya un conjunto de objetos contractuales WCF, renunciando a los principios OOP, y luego conviértalos a otro conjunto de objetos en las capas lógicas reales.

Sí.

La forma en que WCF serializa las cosas termina imponiendo muchas limitaciones sobre lo que puede y no puede hacer con los objetos del contrato. Lo que no puedes hacer termina siendo "casi todo lo útil".

He encontrado que hace las cosas mucho más claras si se piensa en los objetos del contrato WCF como solo un mecanismo de transferencia de datos. Básicamente me gusta XML fuerte/estáticamente tipado.
En lugar de convertir su objeto comercial en una cadena XML (y viceversa), convierta su objeto comercial en un objeto WCF-contract (y viceversa), pero es similar

Answer 2

Después de la lectura de la biblioteca de Thomas Erl, llegué a la siguiente conclusión:

pienso en los contratos de WCF/SOAP mensaje como un simple mensaje de que los servicios utilizan para comunicarse (no ate firmemente que a los objetos de tu codigo).

A continuación, puede usar OOP para diseñar una base de código que maneje con gracia esos mensajes utilizando técnicas de OOP comunes.

Answer 3

Se utiliza una abstracción (tipo de interfaz) anotado con WCF atributos con el fin de definir su contrato de servicio.

Esto depende tanto de la abstracción, que está de acuerdo con OOP, como de la definición de un punto final de servicio, que es SOA.

En general, si encuentra objetos de negocios con dependencias, debería considerar establecer dichas dependencias hasta la capa de negocio de servicios en lugar de inyectar dependencias en los objetos de negocio. capa de negocio El servicio actuará entonces como un mediador que actúa tanto en el proxy de servicio WCF, así como los objetos de negocio. A diferencia de tener los objetos comerciales actuando sobre el proxy del servicio WCF.

Answer 4

¡Todos los comentarios excelentes sobre este tema! Agregaré mi voto a la noción de un adaptador para la mediación entre la orientación de su servicio y la orientación del objeto. También me gusta el enfoque de Thomas Erl en el que, en su modelo de servicio, introduce la noción de "servicios de aplicaciones" y "servicios comerciales". Estos son el camino a seguir para sus puntos de integración con su entorno de aplicación/negocio específico (es decir, el orientado orientado a objetos y componentes marco/API). De esta manera, debería resultar en una capacidad de compilación mucho mejor y, por lo tanto, en capacidad, para los gurús de framework empresariales que existen.