¿Es una buena práctica usar los controles de usuario para estructurar los formularios WPF incluso si estos controles de usuario solo se usan una vez?

7

Desarrollo una aplicación WPF utilizando MVVM y estoy aprendiendo a hacer las cosas mejor.

Tengo un formulario WPF con selectores, dos listas con campos de búsqueda y algunos otros elementos. Actualmente todo está en una forma y funciona. Pero ahora la máquina virtual para esa forma tiene más de 800 líneas y aún no está terminada.

Quiero estructurar mejor este formulario y el código. Pensé en regiones, archivos con clases parciales y controles de usuario. Creo que los controles de usuario serían los mejores porque encapsulan un par de controles y lógica. Si utilizara los controles de usuario, la cantidad de código en esa ventana y VM se reduciría drásticamente.

Para hacer esto correctamente, trabajo en el libro "Pro WPF 4.5 In C # 4th Edition", Capítulo 18 - Elementos personalizados y la muestra ColorPickerUserControl. La muestra trata sobre un selector de color con tres controles deslizantes y tiene 150 líneas de código.

Creo que entiendo cómo funciona, pero me parece que crear controles de usuario, incluso con una funcionalidad muy limitada como en esa muestra, es mucho trabajo . Si quisiera usar estos controles varias veces, entonces entiendo que tendría sentido hacer esto. Pero si uso los controles solo una vez y hago esto solo para estructurar mi formulario, entonces esto parece ser un montón de trabajo para una pequeña ganancia.

Mi pregunta es: ¿es una buena práctica usar los controles de usuario para estructurar formularios incluso si estos controles de usuario solo se usan una vez? Si no es así, ¿hay alguna alternativa mejor?

Editar (no es necesario leer, solo más información): hasta ahora no escribí ningún detalle porque quería aprender sobre el principio, pero después de leer la interesante respuesta de 17 de 26, aquí hay algunos Detalles: Este formulario es para seleccionar títulos de música.

  • Grupo A: (posible control A del usuario) es sobre el tipo de selección, como selección por artista o álbum, con o sin video, tal vez año de publicación, etc.

  • Grupo B: esta lista contiene nombres de artistas que se filtran según el criterio A. El usuario puede filtrar la lista, es decir, que muestra solo los nombres de artistas que contienen "top".

  • Grupo C: esta lista muestra los títulos del artista seleccionado en B que también utilizan los criterios de A (es decir, audio o video). Puede filtrarse de forma similar a B, es decir, solo los títulos que contienen "usted".

La mayoría de la lógica ocurre en la VM (DataContext del formulario). Las listas de A y B provienen de una base de datos. Las listas se filtran y se preparan para la presentación (es decir, varios títulos con el mismo nombre pero en álbumes diferentes). El usuario selecciona un título en la Lista C haciendo doble clic o utiliza la función de arrastrar y soltar en otro formulario WPF.

Lo que quiero: quiero un código legible para poder enmendarlo fácilmente. Si quiero agregar, es decir, otro filtro, digamos para mostrar solo artistas femeninas, sería bueno si pudiera vaya al control de usuario A y agregue casillas de verificación para artistas masculinos y / o femeninos.

El XAML en la forma actual no es un problema, está bien estructurado. Pero la máquina virtual tiene código para todo lo anterior. Algunas cosas están en el constructor, otras en la sección de comandos, algunas propiedades y campos de respaldo. Todavía puedo encontrar cosas ahora, pero creo que sería mejor si el código estuviera más estructurado. Por eso pienso en los controles de usuario.

Intento seguir MVVM porque creo que la lógica detrás de esto tiene mucho sentido. Pero no soy un fanático seguidor de ninguna práctica teórica. I.e. Si puedo hacer algo en 5 líneas de CodeBehind o en 50 líneas en la máquina virtual, lo haré probablemente en CodeBehind. Mi pregunta es sobre el principio de cómo crear formas estructuradas en WPF. El formulario que describo anteriormente es un buen ejemplo, pero la respuesta no debe concentrarse en este solo, sino en la idea de cómo estructurar los formularios WPF, es decir, con (o sin) controles de usuario.

Sobre por qué creo que los controles de usuario son mucho trabajo: Tienen propiedades de dependencia, eventos enrutados, etc. Todo esto me parece mucho más complicado que las propiedades "normales" con campos de respaldo y Iniciar Pero tal vez solo deba acostumbrarme a las propiedades de dependencia, eventos enrutados, etc.

    
pregunta Edgar 13.04.2018 - 10:35

3 respuestas

5

Absolutamente sí. Es una buena idea de la misma manera que es una buena idea aplicar la separación de inquietudes en las clases para que cada una sea propia y realice una sola tarea. Puede que solo tengas una instancia de esa clase, pero no importa. La optimización no es en términos de rendimiento del programa, sino en términos de organización y programa general "salud".

Desea poder volver a su programa un día y no tener que desplazarse por varios cientos de páginas de código, incluso si se coloca en regiones (usar regiones en clases con mucho código es como poner un lápiz de labios en un cerdo) , por cierto). Si algún día decide utilizarlo en otro lugar, puede hacerlo con gracia y sin muchos problemas.

Simplemente no intente dar al usuario acceso de control al formulario principal. Si lo hace de esta manera, use eventos para transmitir información al padre, con el formulario padre como suscriptor.

    
respondido por el Neil 13.04.2018 - 11:28
3

Esta es una pregunta realmente difícil de responder sin ver el código real. También estás mezclando términos un poco. Los controles de usuario no son una asignación 1: 1 con ViewModels.

Los controles de usuario tienen un propósito específico en la vida: son una composición de varios elementos de la interfaz de usuario que se utilizan como una unidad. Los controles de usuario son subsecciones de una vista. Esto es muy diferente de un ViewModel, que contiene la lógica a la que está vinculada una vista.

Tal vez tenga sentido dividir tu XAML en múltiples controles de usuario, todos controlados por un único ViewModel. Tal vez tenga sentido dividir su código XAML y C # en múltiples pares View-VM. Tal vez tenga sentido dejarlo como lo tienes ahora. Imposible saberlo sin ver el código en cuestión.

¿Cuál es tu meta final aquí? ¿El tamaño del código le está causando dolor o es solo para seguir alguna práctica teórica?

¿Estás tratando de reducir el tamaño de tus Vistas XAML o el tamaño de tus ViewModels en C #? Estas son dos tareas muy diferentes en el mundo de MVVM de WPF.

800 líneas no es terriblemente grande para una máquina virtual que respalda una interfaz de usuario que tiene algún tipo de complejidad. Romper una máquina virtual a menudo puede causar más problemas de los que resuelve. ViewModels toma decisiones como "deshabilitar esta característica cuando esta otra lista está vacía". Tratar de dividir ese tipo de toma de decisiones en múltiples componentes a menudo no tiene sentido y solo agregará complejidad al código.

Ahora, dicho esto, es posible que haya un trabajo que esté haciendo en la VM que no tenga nada que ver con su lógica de ViewModel y se pueda particionar fácilmente en su propia clase. Esto reduciría el tamaño de ViewModel sin aumentar la complejidad general del código.

Supongo que esa era una manera muy larga de decir "depende, y no podemos decirlo sin ver el código en cuestión".

    
respondido por el 17 of 26 13.04.2018 - 14:23
0

Si yo, que no sé nada acerca de su aplicación, tuviera que agregar un nuevo campo sobre el campo del apellido, o cambiar el orden de algunos campos ... ¿Me resultaría fácil o desalentador?

No confío en las regiones porque el compilador no comprobará si has perdido algo en la región incorrecta

Tienes que desarrollar software con el objetivo de facilitar a las personas el desarrollo de lo que creaste.

    
respondido por el A Bravo Dev 13.04.2018 - 16:05

Lea otras preguntas en las etiquetas