vista patrones patron mvc modelo explicado arquitectura silverlight design-patterns mvvm

patrones - ¿Debo usar el patrón Model-View-ViewModel(MVVM) en los proyectos de Silverlight?



patrones mvc mvvm (12)

Un desafío con los controles de Silverlight es que cuando las propiedades están ligadas al código, ya no se pueden editar en Blend. Por ejemplo, si tiene un ListView que se llena desde un feed de datos, no hay elementos visibles cuando edita el control en Blend.

He oído que el patrón MVVM, originado por la comunidad de desarrollo de WPF, también puede ayudar a mantener los controles de Silverlight "blendable". Todavía me estoy volviendo loco, pero aquí hay algunas explicaciones:

Una posible desventaja es que el patrón requiere clases adicionales, aunque no necesariamente más código (como se muestra en el segundo enlace anterior). ¿Pensamientos?

Con el lanzamiento de Prism v2 en febrero de 2009 por parte de P & P, ahora hay un mejor soporte para MVVM disponible para Silverlight y WPF. Vea microsoft.com/compositewpf para más detalles.

Creo que muchos de nosotros estamos esperando que los pioneros avancen y creen aplicaciones de muestra realmente buenas usando MVVM en Silverlight (y WPF para el caso). Hay una serie de áreas complicadas, como la falta de ICommand en Silverlight , o la dificultad de interactuar con animaciones que comienzan y se detienen solo mediante el enlace de datos.

Sin embargo, definitivamente es un patrón para mirar hacia el futuro, y vale la pena probarlo si no te importa "hacer trampa" ocasionalmente en los lugares donde no puedes resolverlo.

Definitivamente creo que deberías usar el patrón MVVM para las aplicaciones de Silverlight, y uno de los beneficios del patrón es que realmente puedes hacer que tu aplicación sea realmente combinable mediante algunas técnicas simples. A menudo me refiero a "blendability" como "diseño de designabilidad", que utiliza ciertas técnicas para asegurarse de que su aplicación se vea bien en Blend.

Una de las técnicas, como señala Torbjørn, es utilizar un marco de inyección de dependencias y suministrar diferentes implementaciones de sus servicios externos en función de si el código se está ejecutando en Blend o en el navegador. Así que configuro mi contenedor para usar un proveedor de datos ficticio cuando el código se está ejecutando en Blend, y de esa manera obtiene soporte de tiempo de diseño para sus cuadros de lista, cuadrículas de datos, etc.

El desafío suele ser cómo configurar el DataContext de forma declarativa, por lo que a menudo termino usando una clase de localizador de servicios como una "interfaz" para el contenedor IoC. De esta forma, puedo vincular el contexto de datos a una propiedad en el localizador de servicios.

Otra técnica es crear algún tipo de control ObjectDataSource (no visual) que tenga dos propiedades: Design Time DataContext y RunTime Data Context. El control realiza el trabajo de detectar dónde se está ejecutando y luego establece Parent DataContext en el objeto correcto.

Hay una muy buena introducción al video de Techdays 2010 sobre el patrón MVVM, explicada claramente:

Para aplicaciones más complicadas que requieren un mayor grado de pruebas automatizadas definitivamente tiene sentido, y el cambio de DependencyProperties a enlace de DataContext es mucho más ordenado que su homólogo de ASP.NET.

El mayor desafío que he encontrado con Silverlight es probar la interfaz de usuario real (creo que hay un marco comercial), y el enorme enredo de llamadas a eventos en el que te metes cuando utilizas los servicios WCF (o el WebClient para ese asunto) con Silverlight.

He estado utilizando MVVM últimamente en un par de diferentes proyectos de Silverlight y ha estado funcionando realmente bien, definitivamente lo recomendaría. La publicación de Jonas es un gran lugar para comenzar, recientemente blogged en blogged sobre mis experiencias en MVVM y creé una solución realmente simple para demostrar los principales puntos de contacto.

He intentado algunas opciones y me estoy preparando para MVVM como la mejor opción para mí. La capacidad de mezcla es un punto importante, y también considero que el aspecto VM es intuitivo para manipular comportamientos dinámicos y efectos de procedimientos y animaciones (como el Silverlight.FX de Nikhil). En un momento intenté evitar Blend por completo a través de interfaces fluidas, pero encuentro el acoplamiento entre la IU y el comportamiento demasiado doloroso a largo plazo. Quiero diseñar mi interfaz de usuario en Blend y luego agregar efectos y otros comportamientos en el código, este es el mejor patrón que puedo seguir hasta ahora.

Siempre he pensado que MVVM y PresntationModel http://martinfowler.com/eaaDev/PresentationModel.html son esencialmente lo mismo. PresentationModel es mucho más fácil de decir. Lo he usado con éxito en java swing, windows forms, WPF y silverlight. Si piensa en términos de separación de preocupaciones, un Modelo de Presentación tiene mucho sentido. Usted tiene una clase cuya única preocupación es proporcionar un modelo de presentación amigable. Realmente no importa qué tecnología se use para mostrarlo en la pantalla. Podría cambiar algunos detalles de implementación, pero dividir las preocupaciones por separado es una buena idea, sin importar cómo muestre la información. Debido a esa separación, puede escribir fácilmente pruebas en su modelo de presentación independientemente de la tecnología de visualización. Entonces eso es una ventaja.

Estoy de acuerdo con Jonas . MVVM parece ser el modelo que mejor funciona para mí (aunque John Papa cree que MVP tiene más sentido). Tengo un artículo de MSDN sobre esto que saldrá en marzo que espero responda a la llamada de un buen ejemplo.

Por cierto, me gustaría ver algo de cohesión en el departamento de MVVM Framework. No hay una buena solución para un marco a seguir todavía. Me gusta Jonas (creo que Jonas es el FX Framework) pero como no es compatible con WPF, podría no ser la opción correcta para algunos.

También estoy de acuerdo con Jonas con respecto a MVVM con Silverlight. Creo que MVP también es una buena opción, pero recientemente tuve tiempo de probar MVP y MVVM con Silverlight y estoy mucho más satisfecho con los resultados de MVVM. (Sí, cambié de parecer mientras más usaba MVVM). La VM abstrae la vinculación del Modelo desde la Vista (obviamente) en MVVM lo que permite más escenarios vinculantes (al menos formas más limpias de hacerlo) que con MVP. Sin embargo, ese es solo un aspecto.

Publicaré algunos ejemplos de MVP y MVVM con Silverlight en mi sitio.