Creo que la lógica comercial debe existir en un modelo cuando se utiliza un patrón de diseño MVC o MVP, pero debe ocultarse detrás de un servicio en una arquitectura orientada a servicios.¿Puede MVC (o MVP) coexistir con SOA?
¿Puede un sistema de software utilizar el patrón de diseño MVC o MVP dentro de una arquitectura orientada a servicios? Si es así, ¿dónde se sienta el modelo?
Bueno, son animales totalmente diferentes. MVC tiene que ver con la presentación de datos, el control de la navegación del diálogo del usuario y la lógica comercial en la construcción del modelo de datos.
SOA se trata de recuperar datos de un proveedor de servicios.
En el lado del cliente, puede usar SOA dentro de la parte Modelo del patrón MVC para construir su modelo con datos de un servicio SOA.
En el lado del servicio, como no hay presentación ni diálogo de usuario, la mayoría del patrón MVC se vuelve redundante. Además, un buen diseño de SOA debe concentrarse en proporcionar un servicio útil independientemente del almacén de datos subyacente, por lo que la parte del "modelo" se vuelve en gran medida incidental.
Es cierto que muchos servicios son "con estado" (por ejemplo, los pedidos son validados, pagados, despachados y recibidos), pero estos estados son parte integral de la lógica comercial y no se prestan a la gestión de sesión típica del patrón MVC.
Buena pregunta. Creo que MVC y SOA deben y deben coexistir. MVC es la arquitectura más exitosa para la comunicación entre el usuario y el sistema. SOA es una arquitectura para una comunicación efectiva entre sistema y sistema. En la mayoría de las organizaciones, hay un lugar para ambos. Por lo tanto, creo que coexistirán.
En términos de cómo interactúan entre sí, mi opinión personal es que MVC se mantendrá (una vez que desaparezca la publicidad SOA) como patrón arquitectónico central con interfaces de servicios de exposición de modelos y controladores cuando corresponda.