¿Cuándo usamos MVVM?

Question

He estado escuchando mucho sobre MVVM para WPF.
¿Cuándo lo usamos?
¿Es un uso para todo o solo tiene usos específicos?
¿Vale la pena por cada proyecto?

Answer 1

Puede ser útil en cualquier proyecto, pero me resulta especialmente útil en situaciones donde se requiere una separación clara entre lógica comercial, lógica de interacción e interfaz de usuario (aplicaciones grandes o aplicaciones que involucran múltiples desarrolladores/diseñadores).

Modelo = lógica de negocios

• Contiene el modelo de cualquier proceso de negocio/objeto que estoy trabajando con.

ViewModel = Interacción lógica

• todo el código que controla cómo se accede y se modifica el modelo (por ejemplo, editar/deshacer la funcionalidad, la carga diferida, etc.)

Ver = Interfaz de usuario

• La interfaz (definida en XAML) con la que el usuario interactúa. Intento minimizar el uso de código subyacente en esta capa, introduciéndolo en Propiedades adjuntas o en ViewModel.

Sin duda hay muchos otros usos para MVVM, pero este escenario particular es el que he encontrado que es el más útil en mi propia experiencia de desarrollo de WPF.

Answer 2

Lo he encontrado útil incluso en proyectos relativamente pequeños, si uso mucho el enlace de datos y un modelo/modelos de datos de objeto.

Answer 3

En términos de WPF y Silverlight?

En teoría para todo, cada proyecto no trivial (y posiblemente incluso entonces). Es parte de un proceso más amplio (crea separación de preocupaciones y permite pruebas y otras cosas agradables). Básicamente, si lo vas a hacer (y creo que probablemente quieras hacerlo, ciertamente tengo la intención de hacerlo con nuevos proyectos), entonces deberías hacerlo en general.

Si aún no lo has hecho, ve el video vinculado desde aquí: http://blog.lab49.com/archives/2650 - Me pareció muy útil para aclarar mis ideas.

Answer 4

Es mejor preguntar: cuando no debería lo usa? El ejemplo más obvio es cuando el enlace de datos no es apropiado y usted tiene que manipular elementos de la vista directamente en el código; si, por ejemplo, su aplicación necesita actualizar el estado visual de cientos o miles de elementos visuales en tiempo real, puede no poder pagar la sobrecarga de enlace de datos.

Answer 5

Actualmente estoy trabajando en un proyecto grande, donde implementamos mvvm, CAL (Guía de aplicaciones compuestas) en Silverlight. Por supuesto, el nivel de separación de preocupaciones es muy alto ... pero

1) el código se vuelve demasiado robusto.

2) MVVM se ve genial para proyectos pequeños (todas estas muestras de hello-world en Internet), pero reduce sus oportunidades: por ejemplo, los eventos enrutados (gran instrumento) siguen siendo EVENTOS, pero, como usted sabe, está estrictamente prohibido usarlos directamente, tan pronto como este código esté detrás) si quiere seguir mvvm.

3) Command Binding STILL no funciona correctamente en Silverlight (.net4.0, vs2010). Es una historia larga, solo tenga en cuenta esa sorpresa cuando su delegado CanExecute no se active al inicio de la aplicación.

Una buena respuesta a su pregunta es "MVVM es bueno para proyectos con lógica de IU simple".

Gracias, Ilya.

Answer 6

Cada vez que se inicia en un proyecto simple y pienso "esto es tan simple, MVVM sería una exageración", aproximadamente 8 horas más tarde llego a un punto en que me di cuenta que el uso de MVVM haría las cosas mucho más simple.

Así que yo diría que la mayoría de las veces el uso de MVVM en realidad simplificará su lógica de UI, incluso si inicialmente piensa que será excesivo. Los proyectos tienen la costumbre de volverse más complejos con el tiempo, y la separación de la lógica de negocios y la lógica de vista impuesta por MVVM permite que el proyecto crezca de una manera mucho más controlada que tener su lógica empresarial y de UI mezcladas todas juntas.