tutorial español .net wpf design-patterns mvvm

.net - español - ¿Qué hace que MVVM se adapte exclusivamente a WPF?



mvvm wpf (4)

Model-View-ViewModel es muy popular entre WPF y Silverlight. He estado usando esto para mis proyectos más recientes y soy un gran admirador.

Entiendo que es un refinamiento de MVP . Sin embargo, me pregunto exactamente qué características únicas de WPF (y Silverlight) permiten a MVVM trabajar, y evitar (o al menos dificultar) que este patrón funcione con otros marcos o tecnologías.

Sé que MVVM tiene una fuerte dependencia de la poderosa tecnología de enlace de datos dentro de WPF. Esta es la característica que muchos artículos y blogs parecen mencionar como la clave para que WPF proporcione los medios de la fuerte separación de View from ViewModel. Sin embargo, el enlace de datos existe en muchas formas en otros marcos de interfaz de usuario. Incluso hay proyectos como Truss que proporcionan enlaces de datos estilo WPF a POCO en .NET.

¿Qué características, aparte de la vinculación de datos, hacen que WPF y Silverlight se adapten exclusivamente a Model-View-ViewModel?


Creo que el soporte de comando (ICommand) además de las excelentes capacidades de enlace de datos lo hace adecuado para WPF y Silverlight.


DataBinding, comandos, plantillas de control y XAML.

Sin uno de estos, MVVM sería mucho más difícil, si no imposible. Tome ASP.net por ejemplo, tiene la parte ASPX (que por el ejemplo es equivalente a XAML), tiene enlace de datos, pero no tiene comandos o plantillas de control, por lo que MVVM no es posible allí. En WinForms, tenemos enlaces de datos, y eso es prácticamente todo, por lo que tampoco es posible.


En resumen: es el enlace de datos.

Según la información general de enlace de datos de MSDN :

Si el enlace tiene la configuración correcta y los datos proporcionan las notificaciones adecuadas, entonces, cuando los datos cambian su valor, los elementos que están vinculados a los datos reflejan los cambios automáticamente. El enlace de datos también puede significar que si una representación externa de los datos en un elemento cambia, entonces los datos subyacentes se pueden actualizar automáticamente para reflejar el cambio. Por ejemplo, si el usuario edita el valor en un elemento TextBox, el valor de los datos subyacentes se actualiza automáticamente para reflejar ese cambio.

Si configura su XAML correctamente, solo tiene que interactuar con su interfaz de usuario utilizando el modelo de vista. WPF se ocupa de actualizar la interfaz de usuario cuando cambia el modelo de vista y de actualizar el modelo de vista cuando la interfaz de usuario cambia (por ejemplo, la entrada del usuario).


Implementé el patrón de primos de MVVM Model-View-Presenter en MFC, WinForms e incluso MATLAB. Estoy de acuerdo con la publicación original: WPF facilita el enlace de datos muy bien, pero puede utilizar los conceptos en otras plataformas (aunque con más código).

Al leer el blog de John Grossman , la verdadera diferencia distintiva es que la interfaz de usuario debe escribirse en un idioma diferente de la lógica comercial. Lo ideal parece ser que el desarrollo de la interfaz de usuario es realizado por "diseñadores" y no por programadores.

Esta es el área en la que WPF es único: no conozco ningún otro entorno de desarrollo que funcione para este ideal.

(Tenga en cuenta que nunca he trabajado en un equipo lo suficientemente grande como para garantizar diseñadores de UI dedicados. No puedo decir si este ideal es realmente alcanzable).