none
APLICACION WPF CON MVVM - PROBLEMA CON EL TAMAÑO DE LAS VISTAS (VIEWMODEL) RRS feed

  • Pregunta

  • Estoy haciendo una aplicación WPF con MVVM, de forma que separo la interfaz de usuario de la operativa que introduzco en archivos ViewModel  que se ocupa de todo de recoger los comandos de la IU, de crear las variables privadas y publicas que enlaza la IU mediante BINDINGS, de hacer las operaciones con los datos y del acceso a Base de datos. El resultado final es que los ViewModel resultan unas clases enormes en tamaño y responsabilidad y creo que esto no debe ser así, se termina creando programación estructurada disfrazada de ViewModel, y mi consulta hace referencia a si conocéis algún libro o artículo en que me pueda basar para hacer que la aplicación pueda ser mejor distribuida y no tenga tantos bloques enormes, o alguna aplicación de ejemplo para ver como se hace.

    un saludo y gracias

    domingo, 26 de junio de 2016 11:35

Respuestas

  • "Cuando la aplicación es demasiado complicada, añade más clases".

    Como primera medida, saca del ViewModel todos los accesos a base de datos. Ponlos en otra capa, y desde el ViewModel simplemente llama a esa capa cuando tengas que acceder a los datos.

    Una segunda consideración es que si tu ViewModel es enorme, probablemente se corresponde con una vista (xaml) complicadísima. Recorta la vista dividiéndola en varios UserControls (por ejemplo, si tienes un control de petañas, pon un UserControl en cada pestaña en lugar de rellenar cada pestaña completa en la vista principal). Y si tienes varias zonas en pantalla que piden distintos tipos de datos, sácalas igualmente a UserControls separados, y luego en la pantalla principal ubicas los UserControls.

    Cada USerControl tendrá su propio ViewModel, que de esta manera será más reducido y fácil de mantener. Y en la pantalla principal, el ViewModel se encargará de coordinar la interacción de los varios USerControls, quedando igualmente más breve y sencillo de mantener.

    • Propuesto como respuesta Christian AmadoMVP lunes, 27 de junio de 2016 14:13
    • Marcado como respuesta fjjcent lunes, 27 de junio de 2016 22:28
    domingo, 26 de junio de 2016 16:22

Todas las respuestas

  • "Cuando la aplicación es demasiado complicada, añade más clases".

    Como primera medida, saca del ViewModel todos los accesos a base de datos. Ponlos en otra capa, y desde el ViewModel simplemente llama a esa capa cuando tengas que acceder a los datos.

    Una segunda consideración es que si tu ViewModel es enorme, probablemente se corresponde con una vista (xaml) complicadísima. Recorta la vista dividiéndola en varios UserControls (por ejemplo, si tienes un control de petañas, pon un UserControl en cada pestaña en lugar de rellenar cada pestaña completa en la vista principal). Y si tienes varias zonas en pantalla que piden distintos tipos de datos, sácalas igualmente a UserControls separados, y luego en la pantalla principal ubicas los UserControls.

    Cada USerControl tendrá su propio ViewModel, que de esta manera será más reducido y fácil de mantener. Y en la pantalla principal, el ViewModel se encargará de coordinar la interacción de los varios USerControls, quedando igualmente más breve y sencillo de mantener.

    • Propuesto como respuesta Christian AmadoMVP lunes, 27 de junio de 2016 14:13
    • Marcado como respuesta fjjcent lunes, 27 de junio de 2016 22:28
    domingo, 26 de junio de 2016 16:22
  • Gracias Alberto por tus sugerencias intentaré hacerlo como me dices, pero en el fondo subyace el problema de no haber visto nunca una aplicación hecha con orientación a objetos siguiendo el principio de Simple responsabilidad  (SRP) por lo que me cuesta ver como se puede distribuir una aplicación en distintas clases, mis proyectos tienen siempre el mismo problema que las clases hacen muchas cosas y son muy grandes, mi regla siempre ha sido que la clase Clientes resuelve todo lo de Clientes, la de Proveedores todo lo de proveedores, pero esto es un esquema muy simple y las clases acaban efectivamente siendo muy grandes y luego lees la teorías de Metodología AGIL de SRP ... y te peguntas y como es eso en la practica y no hay forma de encontrar un ejemplo.

    Gracias

    lunes, 27 de junio de 2016 22:28
  • Quizá lo que te ocurre es que te falta separar un bloque más. Dentro de MVVM, tienes la primera "M" que es el Modelo, la "V" que es la vista, y el "VM" que es el VistaModelo. Aparentemente, solo estás usando las dos últimas, y estás metiendo en el VM ciertas cosas que normalmente deberían separarse al M. Es decir, dices que "la clase Clientes resuelve todo lo de Clientes". Esa clase Clientes debería separarse al Modelo. Y luego en el VistaModelo solo se pone lo necesario para transferir a la Vista (o recuperar desde la Vista) los datos cuyos cálculos u operaciones se han resuelto desde el Modelo.

    Esto es un nivel más de "separation of concerns", que permite ubicar en clases independientes las operaciones que son responsabilidad de esas clases, con lo que disminuye un poco más la complejidad de las mismas. Lamentablemente, no tengo ningún ejemplo que pueda poner a tu disposición.

    martes, 28 de junio de 2016 5:54
  • No mi estructura concreta es:

    1) Una clase ENTRADA que implementa un patrón Singleton y un patron Facade.

    2) A traves del patron Facade accedo a las clases del modelo que no son sino clases Model First de Entity Framework (ADO 4) y que resuelve los temas de Bases de datos mediante una clase Contexto (DBContext) 

    3)Un ViewModel que conecta con la IU para los Bindings y con ENTRADA para traer o llevar datos

    Yo pretendía crear un solo objeto Cliente, Proveedor etc. El problema con Model First es que los objetos creados en memoria tienen identidad propia y es necesario crearlos y destruirlos cada vez.

    A lo mejor estoy buscando algo que no existe y me estoy volviendo loco, pero yo leo en los libros que una clase solo debe tener una responsabilidad y de que no debe haber dependencia entre las clases, incluso he llegado a leer que las funcionalidades de la clase se deben hacer en base a un conjunto de clases auxiliares que resuelven cada necesidad, es decir en vez de la clase cliente crear un objeto correo y enviar un correo, inyectar en la clase cliente un objeto de la clase correo, por ejemplo en el constructor, y así con cada funcionalidad, y llevo leído mas de 100 libros sobre esto, pero aún no he visto ni un ejemplo, y pienso que puedo estar persiguiendo fantasmas que no existen.

    un saludo

     

    martes, 28 de junio de 2016 9:00