Finalmente tuve que hacer algo de desarrollo de Silverlight y me encontré con MVVM. Estoy familiarizado con MVC y el artículo que estaba leyendo decía que debido a XAML, MVC no funcionaría. No tener mucha experiencia en XAML es claramente la razón por la que no entendí este punto.Beneficios de MVVM sobre MVC
¿Alguien puede explicar por qué MVC no es adecuado y por qué MVVM es mejor para el desarrollo de Silverlight?
Gracias JD
Sus una distinción muy delgada, lo que me puede explicar mejor mediante la comparación de MVC en ASP.NET y MVVM en WPF.
En ASP.NET MVC, la solicitud proviene del servidor web y es manejada directamente por el controlador. El Controlador determina la Vista apropiada y la rellena con Modelos. El Controlador luego libera estas instancias al sistema subyacente que procesa un resultado para el cliente. Puedes ver que el controlador es el primero y el último en actuar.
En MVVM, la IU (la Vista) se enfrenta al usuario y recibe la entrada del usuario directamente. Dentro de la Vista, los Comandos dentro del ViewModel (que es el DataContext de la Vista) son activados por esta actividad. El control fluye al ViewModel que interpreta lo que View ha enviado y prepara sus Modelos. Después de que el control vuelva a la Vista, se actualiza según los cambios en los Modelos. Si se requiere una nueva Vista, ViewModel lo comunica con NavigationService (o con cualquier método de navegación que use su aplicación), que es competencia de los componentes Window o Frame - UI. Puede ver que ViewModel no es el primero ni el último en actuar; la Vista juega un papel mucho más importante que en MVC.
La arquitectura de WPF/Silverlight es la razón por la que las cosas se hacen de esta manera. Las infraestructuras de comando, enlace y navegación no pueden ser controladas/reemplazadas por el Controlador; están estrechamente integrados con la IU. Entonces el Controlador debe sentarse debajo de la Vista y tomar un rol más pasivo.
Gracias, brillante explicación. Eso ha aclarado algunas dudas. Gracias a todos los demás por responder. –
Creo que la idea es que MVVM es mejor adecuado para XAML que MVC. Decir que MVC 'no es adecuado' es un poco exagerado.
¿Y por qué es mejor MVVM? Principalmente debido a la excelente vinculación de datos y el enlace de comandos en XAML. Ver this article.
MVVM fue diseñado principalmente debido a XAML y para hacer que el enlace de datos sea aún más simple, es muy similar a MVP. Los principales beneficios son la forma más simple de manipular la interfaz de usuario (ViewModel o Presenter se encarga de esa tarea en lugar de que el Modelo tenga que disparar eventos a la Vista después de que haya sido manipulada por el Controlador).
Los dos mejores artículos que he encontrado que me ayudó a entender los principios son MVC vs MVP vs MVVM y MVVM for Tarded Folks Like Me or MVVM and What it Means to Me
Gracias por los enlaces. –
Gracias por los enlaces. Estoy un poco confundido por los patrones de MVP, MVC y MVVM y dónde usarlos. – gyurisc
creo que el otro beneficio es la curva de aprendizaje. Como la mayoría de los desarrolladores de las tecnologías frontend han utilizado el tipo de estilo de codificación MVVM, es más fácil para ellos adoptar lo mismo que ir con un modelo de controlador donde necesitan pasar cada solicitud de vista al controlador y hacer que se comunique con el modelo.
Componentes desacoplamiento
En MVC, que tienen una relación triangular entre los componentes. Es decir: el controlador posee la vista y el modelo. La Vista se basa en la definición del Modelo. El Modelo necesita cumplir con los requisitos de la Vista.Piense en una arquitectura Hub (controlador) y de radios (vista y modelo)
En MVVM, piense en ese triángulo que se aplana con cada componente solo conociendo uno de otro en la cadena. Es decir: Ver-> ViewModel-> Modelo
El modelo no tiene conocimiento de nada en la pila. El ViewModel solo conoce el Modelo La Vista solo tiene conocimiento del Modelo de Vista: no tiene conocimiento del Modelo.
¿Por qué es esto importante?
Este es el núcleo de la pregunta original.
El objetivo principal es una mayor abstracción de su arquitectura. Esto normalmente generará un poco más de código, pero menos puntos de contacto entre los objetos. Menos puntos de contacto son importantes porque esto lleva a un código más ágil. Cuanto mayor sea la clase A de acoplamiento/contacto con la Clase B, mayor será el impacto que tendrá un cambio en la Clase A. La reducción del impacto del cambio es uno de los beneficios clave de una buena arquitectura.
Para entender completamente esto, es útil reflexionar sobre lo que realmente representan los componentes. ¿Qué es una Vista, un Controlador, un Modelo de Vista o un Modelo? ¿Son definiciones literales, o más de un concepto abstracto?
En mi experiencia, ha sido más beneficioso considerar el Modelo como un conjunto de clases/objetos que se ocupan de la construcción y la persistencia de los datos. No es solo un simple objeto viejo con propiedades. Es una clase que realiza búsquedas de datos, guarda datos, una fábrica que construye objetos antiguos. Es una capa de fachada que proporciona una API clara en los datos. ¿Se debe hacer referencia a esta capa de fachada directamente desde la vista?
En mi opinión, no debería. En MVC, esa respuesta también es "no". El controlador obtiene datos del modelo. En ese sentido, MVC y MVVM logran el mismo objetivo. Donde las dos arquitecturas difieren es cómo los datos y la vista están vinculados.
Al igual que el Modelo, la Vista puede ser una colección de clases que, en coordinación entre sí, rinden una vista de presentación. Esto podría consistir en View Controller + View en el caso de plataformas móviles (View Controller en iOS, Activity en Android). En muchos casos, necesita una clase para cargar un documento de vista en la memoria y actualizar las propiedades de vista. Hay mucho trabajo por hacer aquí. En MVC, el controlador se convierte rápidamente en una clase de "fregadero de cocina", una especie de vertedero de todo lo relacionado con el contexto actual del usuario.
Cuando multiplica esto por docenas de posibles vistas dentro de su aplicación, termina con una gran cantidad de dependencias profundas entre su código de modelo de fondo y su código de vista frontal. Con clases de controlador grandes, estas dependencias no son inmediatamente evidentes.
aplanamiento sus dependencias
MVVM aplana las dependencias. Esto crea foco. ¿Qué es el enfoque? La capacidad de trabajar en una sola pieza de funcionalidad sin la distracción de todas las otras dependencias. Ahora puede comenzar a escribir pruebas unitarias en un código que anteriormente se consideraba no comprobable.
El modelo de vista actúa como una fachada entre la vista y el modelo. El modelo de vista atiende las necesidades de la vista: técnicamente, la vista debe ser propietaria del modelo de visualización. Si la vista requiere datos de múltiples fuentes, el modelo de vista encapsula la composición de fuentes de datos separadas en un solo objeto unificado y desnormalizado.Si la vista necesita volver a llamar al Modelo u otros destinos, View Model proporciona enlaces y enruta la llamada apropiada.
Considere cómo funciona un panel de conexiones de red. A primera vista, esto parece redundante: ¿por qué no simplemente cablear su ethernet desde el punto A al punto B. Pero con la experiencia, comprenderá que un panel de conexión le proporciona una pieza clave de abstracción que le permite alterar las rutas de Point B sin afectar el punto A. Esto es lo que está haciendo su modelo de vista.
Ahora que tiene una abstracción clara entre su Vista y Modelo, la consecuencia debería ser que su Vista/Controlador solo se ocupa de la presentación. Esto significa que no debe tratarse con la localización o el formateo: obtiene datos y presenta datos. Su modelo de vista es un lugar ideal para colocar este tipo de masaje de datos previo a la vista. Supongamos que necesita filtrar los datos según un criterio. Nuevamente, el Modelo de Vista es conocedor de los datos del Modelo (su Vista no) y es un gran lugar para poner este tipo de código.
Una vez que comience a organizar los requisitos de su aplicación de esta manera, su código de vista/controlador se vuelve más limpio, y cuando algo necesita cambiar, las implicaciones son más obvias, lo que lleva a menos errores.
Comprobabilidad
Una nota final sobre la capacidad de prueba: Al aplanar a cabo las dependencias, que hace que sea más fácil de inyectar dependencias simulacros en sus pruebas. Hace las pruebas más fáciles y más concisas. Su modelo de vista se convierte en algo con lo que puede definir casos de prueba claros.
Esto podría ayudar: http://stackoverflow.com/questions/667781/what-is-the-difference-between-mvc-and-mvvm – SeanJA