He leído el artículo de MSDN en MVVM y no estoy muy convencido. Si el modelo ya implementa INotifyPropertyChanged/INotifyCollectionChanged, ¿qué hay de malo con el enlace de visualización directamente contra el modelo? Parece que el ModelView adicional introduce algún código sin mucho beneficio. ¿Me estoy perdiendo algo?¿Es MVVM realmente útil?
También era un poco escéptico sobre MVVM hasta que vi esto great presentation por Jason Dolinger. Recomiendo a todos mis compañeros de trabajo que están comenzando en WPF y MVVM que lo miren.
Jason comenzó con una aplicación que uno escribiría en un “tradicional” manera, con pulsaciones de botón manejados por manipuladores de eventos en el código subyacente que entonces actualizados otras partes de la interfaz de usuario. Utilizando el enlace de datos de WPF, Comandos, y Unity, lo transformó, pieza por pieza, en un diseño mucho más manejable, encapsulado, legible y comprobable M-V-VM. Fue increíble.
Para responder a su pregunta de manera más directa, aunque parezca tonto para unirse a un modelo de vista cuando el modelo ya tiene todo, a menudo terminan necesitando un pequeño ajuste al modelo que se necesita sólo por la vista. Con el tiempo, estos pequeños cambios se infiltrarán en sus Modelos, donde no pertenecen. Hará que tus modelos sean más complicados de lo que deberían ser.
Lo que hago a menudo cuando tengo un modelo que "lo tiene todo", es que agrego un modelo de vista que contiene una propiedad, el modelo. Luego, en mis enlaces solo me ato a Model.Name, Model.Age, etc. Realmente no es un esfuerzo. Más adelante, si necesito ajustes solo para la Vista, ya tengo lista mi clase de ViewModel. Esto también hace que tu código sea más intuitivo y fácil de entender. No se preguntará, ¿me vinculé al Modelo o al Modelo de Vista en este caso? Siempre será el ViewModel.
INotifyPropertyChanged y INotifyCollectionChanged no son los únicos aspectos a tener en cuenta ... En muchos casos, los datos expuestos por el modelo no serán fácilmente utilizables por la vista. La función de ViewModel es actuar como un adaptador entre el modelo y la vista: exponer los datos en una forma que permita que la vista se vincule fácilmente a ellos, exponer los comandos a los que la vista puede vincularse para realizar acciones ... Por lo general, un modelo no expondrá ICommand s: si lo hace, entonces el modelo es específico de WPF, lo que nunca es bueno es que desee reutilizar en alguna otra aplicación que no sea WPF ...
Tengo estado utilizando MVVM durante algunos meses, y me hizo la vida mucho más fácil: no hay más "código de spaghetti" en archivos de código subyacente, clara separación de responsabilidades, limpieza de la arquitectura general ...
He estado usando MVVM para 2 proyectos y aquí hay algunas cosas que he estado haciendo en el modelo de vista:
y hay mucho más que hacer allí (que me olvidé) que no encajaría en el modelo en sí mismo, o que haría que la interfaz de usuario espaguetis.
Sin olvidar, el ViewModel le permite probar cosas que no podría probar si se implementara en la UI (como Comandos).
Finalmente, al usar MVVM, pude construir una versión de línea de comando de mi aplicación muy fácilmente usando ViewModels.
Estoy utilizando MVVM con MEF desde hace unos años y no estoy muy seguro de lo útil que realmente es. En nuestro desarrollo no reutilizamos ViewModels para diferentes vistas, tampoco tenemos diseñadores a los que solo se les permita cambiar la Vista (UI).
Y muchas cosas son difíciles de lograr en un ViewModel, como configurar el cursor según los cambios en el ViewModel (sí, es posible, pero agrega mucho desorden al código).
Lo bueno de MVVM es organizar los valores y los comandos como enlaces en lugar de configurar los campos directamente, pero esto podría hacerse sin ViewModel.
Yo también era escéptico cuando comencé con MVVM, luego vi ese video y ahora me siento mal al no usar alguna forma de MVVM con mis aplicaciones WPF. También la lectura de la fuente de Crack.NET por Josh Smith ayudó mucho. –
Ese enlace ya no existe. –