A menudo se especifica en los diversos tutoriales de MVVM, que el objetivo de MVVM no es eliminar el código subyacente y que aún puede ser necesario algún manejo de eventos en el código subyacente.Eventos en lugar de comandos en MVVM?
¿Cuáles son los escenarios en los que necesita escribir eventos en código subyacente en lugar de usar comandos en viewmodel?
En general, si su código pertenece a la lógica de la interfaz de usuario, manténgalo en el XAML de la vista o en el código subyacente. El modelo de vista solo es responsable de enlazar y vincular datos entre la vista y el modelo.
Un ejemplo se puede encontrar en una de mis preguntas, How do I make a WPF window movable by dragging the extended window frame? Uno de los eventos que uso es SourceInitialized, en la que puedo acceder a la manija de la ventana Window 's para llevar a cabo un poco de magia API de Windows. Pero todo esto se relaciona con la ventana, y no tiene nada que ver con la lógica de la aplicación más allá de la ventana, así que lo restrinjo al archivo de código subyacente de la ventana, dejando al modelo de vista completamente ignorante de él.
En mi opinión, en MVVM, cuando los eventos relacionados con la interfaz de usuario, algo así como la animación, puede escribir en el archivo de código subyacente.
Toda la lógica comercial debe estar en el modelo de vista.
Creo que existe la posibilidad de que los controles de usuario personalizados utilicen el código.
Digamos que crea una clase de elemento de pestaña que se puede cerrar que hereda TabItem. Puede manejar esa acción de cierre usando eventos y vincularla a un DP.
Esto es, por supuesto, genérico y podría usarse varias veces.
Supongo que el código subyacente es aceptable cuando el evento tiene que ver con la interfaz de usuario y no con el modelo de datos u otra actividad.
En mi experiencia, el uso de controles de terceros que no son compatibles con el enlace de MVVM dará lugar a la escritura de código en el código detrás del archivo. Esto sucedió incluso para usos simples como seleccionar un elemento actual, leer el elemento seleccionado actualmente, etc. que debería ser bastante simple de implementar en el control pero no lo fue.
Un ejemplo de esto es la propiedad SelectedItem del control Silverlight TreeView, que en lugar de ser DependencyProperty (que es enlazable) es una propiedad normal por lo que no se puede enlazar.
También como se menciona @BoltClock, a veces parece lógico poner algún código en el código detrás del cual están realmente relacionados con lo que hace la vista y no tiene nada que ver con la lógica "detrás" de la vista. Lo mejor es poner este tipo de lógica en el código subyacente.
Un caso que he encontrado es con los controles de terceros. Algunos controles de terceros, como la cuadrícula de telerik, usan internamente sus propios tipos de datos personalizados para representar las filas de la cuadrícula, etc., y usted necesita manejar los diversos eventos de cuadrícula para convertir esos tipos específicos de interfaz de usuario a sus tipos de experiencia y luego pasarlos a VM.
Diría que cualquier "lógica" que tendría que ser diferente si transfiriera a otra IU de escritorio (por ejemplo, el mac) debería estar en el código subyacente. (Por ejemplo, otra plataforma con aproximadamente la misma necesidad lógica de IU)
Así que enganchar todos los eventos para separar cuando el uso está "suspendido" sobre un campo de entrada debe estar en el código detrás, pero decidir qué mostrar en el "estado" línea "cuando un usuario vuela por el aire debe estar en el modelo de vista.
¿Qué relevancia tiene esto cuando se orienta a .NET Framework? Si el marco es compatible con Mac, Linux, etc., las llamadas WPF también serán compatibles. A menos que haya funciones específicas que solo sean parcialmente compatibles (no se han seguido mono, así que no lo sabría). –
@Josh, te ayuda a pensar sobre lo que es parte de la lógica de la interfaz de usuario de la aplicación y lo que es solo "apariencia". –
¿Y está diciendo que la "apariencia y sensación" pertenece a la interfaz de usuario y que la lógica de la interfaz de usuario podría ir en la máquina virtual? Tiene sentido para mi. –
Siempre se encontrará con puristas que dicen que nunca debe haber CUALQUIER código en el archivo de código subyacente. Normalmente soy un purista, pero no en este caso.
Si tiene una lógica que es muy específica para la vista, debe ir en el archivo de código subyacente. Cuando escribo vistas complicadas que necesitan realizar grandes cambios en la estructura del árbol visual en función de las propiedades o cambios en el modelo de vista, pongo este código en la vista. El modelo de vista no debe saber nada sobre la vista, por lo que no puede (y no debe) controlar estos cambios directamente. A veces, estos cambios se pueden implementar con Triggers en un Style o DataTemplate, pero a veces un buen código pasado de moda es la mejor manera.
No encontré una buena manera de encuadernar la selección de varios elementos en listboxes y tuve que hacerlo en el código subyacente. Pero no es "no limpio"
puede implementar la selección de múltiples elementos de listbox sin código subyacente. Está limpio y funciona muy bien. Puede consultar el siguiente enlace para la solución http://grokys.blogspot.com/2010/07/mvvm-and-multiple-selection-part-iii.html –
@Hasan, ¡gracias! justo lo que necesitaba. Tuve problemas para conseguir que el enlace bidireccional de selecciones múltiples funcionara, ¡creo que esto será mucho mejor! – Karel
Observe cómo mi pregunta (y mi propia respuesta) no dicen absolutamente nada sobre MVVM; además del hecho de que WPF y MVVM no son exactamente sinónimos, también dice mucho sobre el alcance del código que se encuentra en ellos. – BoltClock