WPF: ¿Dónde se detiene MVVM y comienza el código subyacente?

Question

He creado una ventana que tiene un ListView para mostrar una colección de personas. También hay 3 TextBox es que se supone que muestran el nombre y apellido de la persona y una edad. Finalmente, hay un Button para guardar los datos de la nueva persona ingresados ​​en esos TextBox es.

La carga de personas en el ListView se realiza mediante la implementación de MVVM. ¡Funciona de maravilla! Además, agregar nuevas personas a la colección haciendo clic en Button también se realiza a través de MVVM.

Pero hay dos casos de uso que no estoy seguro si es más prudente usar comandos, es decir, MVVM, o simplemente código subyacente. Los casos de uso son:

1. Cuando el usuario selecciona una persona de la ListView, los TextBox es deben mostrar a la persona detalles.
2. Cuando el usuario escribe caracteres en lugar de dígitos en el TextBox que muestra edad de la persona, se le debe advertir que los datos ingresados ​​son incorrectos.

La razón por la que estoy seguro de si debería usar MVVM o de código subyacente es porque ambos casos de uso están relacionados con ver solamente (GUI), es decir, no hay interactividad con el modelo o la aplicación lógica de negocio. La fuente del elemento ListView está vinculada a una colección de personas ObservableColleciton<Person> y todos los datos relacionados con la persona seleccionada ya son pasados ​​ a la vista cuando ListView está lleno de elementos. En el segundo caso de uso, nuevamente, no hay necesidad de ir a ViewModel para permitir que se active el cuadro de mensaje sobre la entrada incorrecta del usuario. ¿Qué hay de la creación de una devolución de llamada de validación en la edad propiedad de dependencia de la clase ViewModel en su lugar?

Gracias por todas las aclaraciones.

Answer 1

La principal motivación detrás de MVVM es la separación de preocupaciones, es decir, la lógica separada de la presentación. Lo que está describiendo (búsqueda y validación) me parece más "lógico", así que lo pondría en el modelo de vista (suponiendo que no se pueda realizar con el enlace de datos, por supuesto).

• Tenga en cuenta que la vista es difícil de probar, así que si hay una posibilidad de que la lógica está implementando tiene errores significativos que podrían ser una razón para ponerlo en el modelo de vista.

• Un método alternativo (semi serio pero generalmente efectivo) para decidir si algo pertenece al modelo oa la vista. Model se pregunta qué pasaría si le da la vista (la ventana, UserControl o lo que sea) a su gráfico diseñador (incluso si no tiene uno, pretende que lo hace). Si está de acuerdo con la idea de que podría poner sus manos C#-incompetentes [*] en el código que está detrás (y desordenarlo) generalmente es una señal de que el código está estrictamente relacionado con la presentación y puede vivir de forma segura en el ver. La mayoría de las veces terminará moviéndolo al ViewModel.

[*] diciendo con fines educativos, muchos diseñadores son más C# competente que yo :-)

Answer 2

Los cuadros de texto pueden y definitivamente deben estar ocupados mediante consolidaciones en XAML cuando cambia la selección ListView, por ejemplo:

<ListView Name="people" .../> 

<TextBox Text="{Binding ElementName=people, Path=SelectedItem.FirstName}"/> 

o para reducir la codificación, poner los cuadros de texto en su propio panel con un conjunto DataContext, por ejemplo, :

<Grid DataContext="{Binding ElementName=people, Path=SelectedItem}"> 
    <TextBox Text="{Binding Path=FirstName}"/> 
    <TextBox Text="{Binding Path=LastName}"/> 
</Grid> 

validación se puede conectar en marcha en XAML, pero el código que hace la validación se lleva a cabo típicamente en una clase. Hay una conveniente clase abstracta en System.Windows.Controls llamada ValidationRule que se puede usar para crear rápidamente un validador. Ver this blog post para un ejemplo.

Answer 3

Puede usar un validation rule para su encuadernación. No mostrará un cuadro de mensaje (aunque probablemente sería posible), pero puede definir un ErrorTemplate que muestra el error.

Answer 4

La única vez que comienzan a caer código en los archivos de código subyacente es cuando no puede ponerlo en el ViewModel o más profundo en el gráfico de objetos.

Por ejemplo, su primera situación es, como se mencionó anteriormente por C. Lawrence Wenham, completamente solucionable en código XAML. No es necesario recurrir al código subyacente para lograr este efecto. Y este ejemplo se puede expandir a interacciones con una colección que no necesariamente se presenta en un control como un cuadro de lista. Puede escribir el código XAML que responde a los cambios en el elemento actual en una colección en el modelo de vista a través del enlace.

Su segunda situación también se puede lograr a través de las instalaciones de dvalidación dentro del ViewModel y la vinculación de datos a esas instalaciones con su XAML. IDataErrorInfo es un gran mecanismo creado para este propósito. Here is a nice little article demostrando un uso simple de IDataErrorInfo.

Los ejemplos de cuándo hay que pasar al código subyacente son, con suerte, pocos y distantes. Un ejemplo que he encontrado es cuando un control no es compatible con ICommand y no se puede vincular la funcionalidad a un elemento de comportamiento, un control de ejemplo es un ListBox. Pero hay algunas técnicas para evitar esta limitación, as demonstrated in this great SO question. Además, en caso de que necesite anular la representación en controles personalizados, tendrá que hacer esto en código subyacente o en una clase heredada.

Espero que esto agregue un poco más de información útil a las respuestas.