Servicio de interacción vs Objetos de solicitud de interacción

Question

Me gustaría saber si al utilizar Prisma, los Objetos de solicitud de interacción son preferibles al uso del patrón del Servicio de interacción. En cuanto a mí, el Servicio de Interacción debe usarse en casos simples, es decir, cuando tiene un mensaje emergente estándar, y solo se cambiará el contenido del texto. Por otro lado, los objetos de solicitud de interacción son más adecuados cuando la interfaz de usuario es más complicada. Pero el servicio de interacción es mucho más fácil de implementar y requiere menos código. ¿Qué opinas?

Answer 1

Estoy de acuerdo con usted en que un servicio de interacción puede ser adecuado para el comportamiento de interacción común, tales como cuadros de mensaje, etc.

En mi opinión, que se reduce a la responsabilidad clase. En otras palabras, ¿quiere que el ViewModel o la View sean responsables de especificar qué tipo de interacción debería tener lugar?

Considérese una interfaz básica de servicio de interacción:

public interface IInteractionService{ 
    MessageBoxResult ShowMessageBox(string messageBoxText, string caption, MessageBoxButton button); 
} 

Es bastante obvio a partir de la observación de la interfaz de qué tipo de ShowMessageBox comportamiento se va a producir. Esto le da al ViewModel cierto grado de control en términos de especificar qué tipo de comportamiento de interacción espera que ocurra. El problema con este enfoque es que su ViewModel ahora tiene una dependencia en IInteractionService además de ser explícito en sus expectativas de comportamiento de interacción. Esto podría hacer que su ViewModel sea menos reutilizable.

Con objetos de interacción, puede colocar más de la responsabilidad del comportamiento de interacción en la vista. En otras palabras, puede cambiar el comportamiento y la apariencia de la interacción sin afectar directamente al ViewModel. Por ejemplo, V1 de la solicitud de interacción podría mostrar un MessageBox simple. La V2 de la solicitud de interacción podría ser un diálogo más complejo que requiere más interacción del usuario que un simple clic del botón. Este tipo de cambio de comportamiento de interacción se puede gestionar sin requerir la modificación de ViewModel. Esto puede ser útil si tiene un diseñador de UI trabajando en el proyecto que quiere la opción de cambiar o cambiar el comportamiento o la apariencia de una vista vinculada a una solicitud de interacción.

Puede usar ambas estrategias si lo desea. En otras palabras, un servicio de interacción para comportamientos de interacción comunes y objetos de interacción para un comportamiento más complejo.

En resumen, los Servicios de Interacción pueden ser más fáciles de usar, pero los Objetos de Interacción pueden hacer que sus Modelos de Vista sean más reutilizables, en mi opinión.

Answer 2

El gran inconveniente de utilizar un servicio de interacción para mostrar un cuadro de mensaje es la ventana primaria, o más bien, la falta de una.

¿Qué ventana debe proporcionar como padre del cuadro de mensaje, desde el modelo de vista o la implementación del servicio? Si elige Application.Mainwindow, está haciendo una gran suposición sobre el diseño general de la aplicación.

La única entidad en el proceso que conoce cómo muestra la interacción es la vista. Ya sea utilizando un cuadro de mensaje o una superposición dentro de la página.

Existen pocos argumentos válidos a favor si se usa un servicio de interacción. El que se usa a menudo es que es más fácil. Esto puede ser cierto, pero también es cierto para muchas otras cosas que no se deben hacer, p. código detrás, etc.