¿Cómo construir ViewModel en MVVM para no violar el Principio de Responsabilidad Individual?

Question

Robert Martin dice: "Nunca debería haber más de una razón para que una clase cambie".

Consideremos la clase ViewModel que está vinculada a una Vista. Es posible (o incluso probable) que ViewModel conste de propiedades que no están realmente relacionadas entre sí. Para vistas pequeñas, ViewModel puede ser bastante coherente, pero mientras la aplicación se vuelve más compleja, ViewModel expondrá los datos que estarán sujetos a cambios por razones diferentes y no relacionadas.

¿Hay que preocuparse por el principio de SRP en el caso de la clase ViewModel o no?

Answer 1

El modelo de vista única responsabilidad es la de proporcionar a la vista de la información que necesita. Si la vista necesita propiedades diferentes y no relacionadas, no es importante, ya que ViewModel solo tiene un motivo para cambiar y esa es la vista que muestra diferentes propiedades. Entonces no debes preocuparte demasiado.

Dicho esto, si el ViewModel se vuelve enorme, tal vez podría pensar en dividir la vista en varias subvistas para mejorar la reutilización y mantener las Vistas y los Modelos de Vista manejables.

Answer 2

Sí, pero eso no quiere decir que un mal diseño no podría forzar en él.

Answer 3

Acepto con gcores.

Una vez que vea ViewModel crecer a más de dos pantallas completas de texto, es el momento de considerar ViewModel división en varios modelos infantiles.

Otra regla general es que nunca tengo más de dos niveles de anidamiento dentro del archivo XAML: si una parte de la vista se vuelve demasiado compleja, es hora de refactorizar la vista, extraiga el XAML interno en UserControl por separado y cree ViewModel correspondiente, que será el contexto de datos predeterminado en la vista secundaria.

Answer 4

Estoy de acuerdo que la división de sus pantallas en múltiples vistas con múltiples ViewModels es necesario reducir la hinchazón y la complejidad. Aquí hay otro patrón que he empleado para ayudar a palo para SRP usando MVVM:

aquí es uno de los escenarios. Mi ViewModel necesita obtener datos y responder a los comandos de filtro desde la IU. Creo el ViewModel para que sea compuesto en estructura. Es decir, las clases secundarias que tienen acceso a miembros privados de ViewModel realizan tareas lineales, como administrar el filtrado. También podría tener otra clase infantil que realice la lógica necesaria para la selección de elementos según los criterios. Entiendes la idea. Una vez que ViewModel está realizando ciertas funciones que abarcan varios métodos, puede ser un buen candidato para delegar en una clase secundaria. Las clases secundarias siguen siendo parte del modelo principal de ViewModel, por lo que es solo una forma de reducir el tamaño del ViewModel y hace que la prueba de unidad de estas operaciones lineales sea más fácil.