wpf - single - principios solid pdf

¿El modelo actual de vista de MVVM es una violación del principio de responsabilidad única?

Question

Con las prácticas actuales (al menos con WPF y Silverlight) vemos vistas vinculadas a través de enlaces de comandos en el modelo de vista o al menos vemos eventos de vista manejados en modelos de vista. Esto parece ser una violación de SRP porque el modelo de vista no solo modela el estado de vista, sino que responde a la vista (usuario). Otros han preguntado cómo crear modelos de vista sin violar el SRP o preguntaron si sus implementaciones lo hacen (este último es el controlador en MVC, pero más o menos análogo).

Entonces, ¿son las prácticas actuales una violación de SRP? ¿O es "ver modelo" realmente una colección de cosas que no violan el SRP? Para encuadrar esto un poco, parece que necesitamos saber cuál es la responsabilidad única o si existen múltiples responsabilidades en el concepto , si las responsabilidades individuales están divididas, de acuerdo con el SRP. No estoy seguro.

La definición de Wikipedia del modelo de vista dice

[E] l ViewModel es un "Modelo de la Vista", lo que significa que es una abstracción de la Vista que también sirve en el enlace de datos entre la Vista y el Modelo

Esto parece lo suficientemente bueno para SRP, pero luego la entrada dice (se agregó mi énfasis)

[El ViewModel] actúa como un enlazador / convertidor de datos que cambia la información del modelo a la información de la vista y pasa los comandos de la vista al modelo

En una publicación del blog de Prism sobre el papel del modelo de vista, el autor dice (nuevamente, mi énfasis)

Lo que se reduce es que el modelo de vista es un compuesto de lo siguiente :

• una abstracción de la vista
• comandos
• convertidores de valor
• ver el estado

Estoy seguro de que me he perdido muchas definiciones, pero parecen caer en estas categorías:

1. Una sola responsabilidad "vaga" de modelar el estado de vista (entonces, ¿qué entendemos por estado?)
2. Múltiples responsabilidades (ver estado, interacción del usuario (es decir, comandos))
3. Un compuesto de responsabilidades específicas individuales (abstracción, estado, interacción, conversión), que tienen una única responsabilidad: "gestionar todo eso".

Si tiene curiosidad, me "importa" esto porque (2) se siente bien, pero parece contrario a las implementaciones prevalecientes.

Answer 1

Lo que se reduce es que el modelo de vista es un compuesto de lo siguiente:

• una abstracción de la vista
• comandos
• convertidores de valor
• ver el estado

No veo por qué has separado los dos primeros elementos. Los comandos son parte de la vista.

En cuanto al resto, tienes razón. En algunos casos. Construí aplicaciones donde las tareas de conversión de valor y mantenimiento del estado de vista eran lo suficientemente complejas como para que no tuviera sentido que una sola clase de modelo de vista lo hiciera todo, y las dividí en clases separadas que interactúan con las máquinas virtuales.

¿Asi que?

Answer 2

Única responsabilidad como lo define Martin :

"NUNCA DEBE SER MÁS DE UNA RAZÓN PARA UNA CLASE A CAMBIO".

Un ViewModel, en lo que respecta a MVVM, es en realidad solo una implementación especializada de un Modelo de Presentación .

Entonces, aunque se podría argumentar que un Modelo de presentación solo debe representar el estado de la IU, y que un Presentador / Controlador siempre debe negociar los comandos entre la IU y el Modelo de presentación. Si uno sigue esta idea, con SRP dividiéndose en Estado y Comandos , entonces agregar un comando no debería afectar la clase que representa el estado. Por lo tanto MVVM rompería SRP.

Sin embargo...

Creo que esto es agarrar a las pajitas. MVVM es una implementación bastante especializada que se usa básicamente en WPF / Silverlight ( y ahora en los clientes del navegador ).

Los patrones están diseñados para simplificar los diseños donde la alternativa sería más complicada o menos fácil de mantener . Ya que MVVM está diseñado para aprovechar las capacidades de enlace de datos extremadamente ricas de las tecnologías de presentación, entonces es una compensación que vale la pena.

Answer 3

¡No! MVVM no viola SRP, (el programador lo hace, jajaja)

No hay ninguna razón por la que el uso del patrón MVVM deba ignorar el SRP. MVVM no significa que solo haya una Clase de modelo, una Clase de modelo de vista y una Clase de vista. Ciertamente, si solo tenía una clase de vista, solo podría mostrar una pantalla simple.

Las clases que están en el nivel de Vista, deben ser responsables de una cosa; Haciendo, decidiendo, o conteniendo. Una vista puede consistir en varias subvistas sobre quiénes son los trabajos que deben realizar ciertas partes de las interracciones de los usuarios. Considere una forma básica, tiene una cuadrícula de visualización, los elementos de la cuadrícula se pueden editar y hay un botón "Guardar".

La vista principal sería un contenedor para otras dos vistas; el datagrid (un control de usuario, o algo) y un control de comando. Entonces, el datagrid es responsable de elegir la vista infantil correcta para representar los datos; En esencia es un contenedor que contiene datos. La Vista para editar elementos es una vista secundaria de la cuadrícula de datos, que a su vez es un elemento secundario de la Vista principal. Por último, el control de comando es un conjunto de botones (en este caso uno solo) cuya única responsabilidad es generar señales de que el usuario ha emitido comandos.

De este modo, la Vista de edición (utilizada por el DataGrid) es independiente de lo que la usa y tiene una responsabilidad; Lo mismo con el control de comando. Del mismo modo, a DataGrid no le importa quién lo use, solo que puede contener la Vista de edición (secundaria). Niza SRP allí.

Los modelos de vista para que coincidan con las vistas (y los niños) también son responsables de una cosa. El modelo de vista de edición es un contenedor al que se enlaza la vista de edición; simplemente contiene los campos de datos que se pueden mostrar / editar. No le importa nada más que la señalización cuando una de sus propiedades cambia. El modelo de vista de botón de comando es una clase que hace cosas. Sus comandos están vinculados a los botones y funcionarán en función de lo que haga clic el usuario. Tendrá que tener acceso a otras partes del ViewModel (s) para hacer su trabajo.

El modelo de vista de la página principal está ahí para contener las otras vistas secundarias. Es su responsabilidad exclusiva como inicializador, realizar todas las instancias de ViewModel requeridas y pasar los parámetros del constructor a otras instancias de ViewModel (por ejemplo, el Modelo de Vista del Botón de Comando para que sepa dónde obtener datos para su trabajo)

Es natural agrupar un montón de funcionalidades en un único ViewModel al que se uniría una gran vista. Pero no tiene que ser así, y SRP puede mantenerse en MVVM.

El objetivo principal de MVVM es permitir un diseño comprobable, la capa del Modelo se puede probar de forma independiente, todas las clases en el Modelo pueden seguir fácilmente el SRP. El ViewModel se puede probar sin la necesidad de una vista; es más difícil pensar en SRP en el ViewModel, pero ciertamente es factible; solo recuerda romper tus clases para que solo tengan una preocupación. La vista está obligada a separar los modelos de vista, con un poco de suerte, su prueba del modelo de vista hace que el ajuste de las vistas sea súper fácil. Recuerde que puede hacer que cada Vista se adhiera a SRP para formar parte de una Vista conglomerada más grande (contenedor).

TL; DR? Para responder su pregunta directamente, la Vista es una colección de clases que no rompe el SRP. Por lo tanto, cuando el ViewModel se abstrae de la (s) Vista (s) (Ver primero), también son una colección de clases que se adhieren a un buen SRP.

Answer 4

Considero que muchas de las prácticas actuales en torno a MVVM violan SPR (al menos). Esta es otra situación en la que simplemente agregar controladores de nuevo a MVVM resolvería todos los problemas de manera limpia. Yo lo llamo MVCVM :)

El patrón que estamos usando con éxito en todos los proyectos recientes es registrar solo los controladores, en los módulos, e inicializarlos al inicio. Los controladores son muy ligeros / delgados y lo único que necesita quedarse durante toda la vida de la aplicación para escuchar o enviar mensajes . En sus métodos de inicialización, luego registran todo lo que necesitan para poseer (vistas y modelos de vista, etc.). Este patrón ligero de solo memoria en la lógica también lo hace para aplicaciones más delgadas (por ejemplo, mejor para WP7).

Como ha descubierto, el problema con el uso de máquinas virtuales simplemente es que eventualmente se topa con casos en los que necesitan saber sobre vistas, comandos u otras cosas con las que ViewModel no debe involucrarse.

Las reglas básicas que seguimos son:

• Los controladores toman decisiones basadas en eventos
• Los controladores obtienen datos y los colocan en las propiedades apropiadas del Modelo de Vista
• Los controladores configuran las propiedades ICommand de los modelos de vista para interceptar eventos
• Los controladores hacen que aparezcan vistas (si no están implícitas en otro lado)
• Ver modelos son "tontos". Los datos de espera para el enlace y nada más.
• Las vistas saben que muestran una cierta forma de datos, pero no tienen idea de dónde vienen.

Los dos últimos puntos son los que nunca debe romper o la separación de preocupaciones desaparece por la ventana.

El simple hecho de volver a agregar controladores a la mezcla de MVVM parece resolver todos los problemas que hemos encontrado. MVVM es algo bueno, pero ¿por qué no incluyeron los controladores? ( pero esto es, por supuesto, solo mi opinión ) :)