MVVM estandarización

Question

Alguien en Silverlight posted que MVVM actualmente carece de estandarización para que cada uno tiene su propio sabor ..

Es por eso que yo y un par de tipos de WPF Discípulos están discutiendo activamente la que los elementos de MVVM que todos estaban de acuerdo. Entiendo totalmente que hemos implementado el patrón de diferentes maneras y hemos mezclado varios patrones o creado nuestro propio patrón en función de las necesidades de nuestro proyecto o para facilitarle la vida a los desarrolladores. Pero olvídese de esas dificultades o la necesidad especial de su proyecto. . Discutamos sobre las reglas estándar del patrón MVVM que todos estuvieron de acuerdo. Publiqué some of my thoughts here también.

¿Por qué MVVM?

• Testabiltiy (modelo de vista es más fácil de probar la unidad de código subyacente o evento código de tracción)
• Claro separación entre el diseñador UX y desarrollador
• Aumenta la “capacidad de mezclado” de la vista
• Modelo Nunca necesita ser cambiado para soportar cambios a la vista
• ViewModel raramente necesita ser cambiado para soportar cambios a la vista
• No hay código duplicado para actualizar las vistas

hacen y no en la vista

• no debe contener ninguna lógica que desea probar: Como Glenn dice que MVVM no es código de ejercicio contando, podemos escribir el código en el código -detrás. Pero nunca debes escribir ninguna lógica que quieras probar. Por ejemplo: si el usuario selecciona un país, entonces desea visualizar la lista de estados o ciudades en su vista. Este es el requisito comercial, por lo que debe tener una prueba unitaria para probar esta lógica. Entonces, no debes escribirlo en código subyacente.
• puede ser un control o una plantilla de datos
• Mantenga la vista lo más simple posible. : Todavía podemos usar Data Trigger o Value Converter o Visual State o Blend Behivor en XAML con cuidado.
• uso de la propiedad adjunto si algo no es enlazable:

hacen y no en ViewModel

• conector entre Ver y Modelo
• Mantener estado de vista, el valor de conversión (Puede cree la estructura de datos que desea visualizar en ViewModel en lugar de utilizar ValueConverter. Por ejemplo: debe mostrar el Nombre en lugar del Nombre y Apellido. Su Modelo puede tener Nombre y Apellido pero puede crear la propiedad Nombre en ViewModel.)
• n fuerte o débil (a través de la interfaz) de referencia de Vista
• Hacer VM como comprobable como sea posible (por ejemplo, no hay ninguna llamada a la clase Singleton)
• Sin Control relativo cosas en VM (Porque si va a cambiar la vista a continuación, también deberá cambiar la máquina virtual.)

Modelo

• puede ser modelo de datos, DTO, POCO, de proxy generada automáticamente de la clase de dominio y la interfaz de usuario del modelo basado en la forma en que desea tener la separación entre el Servicio de dominio y la capa de presentación
• No se hace referencia a ViewModel

¿tiene usted alguna sugerencia o comentario para que?

Tenemos un desacuerdo en nuestro grupo. Algunos dijeron que está bien tener la interfaz de View en ViewModel. Pero algunos dijeron que si View Model tiene la interfaz de View, entonces será el patrón MVP.

Uno de nuestros expertos MVVM decir sobre MVVM Vs MVP

Ver => modelo de vista

• MVVM la vista está ligado directamente al modelo de vista y habla con la máquina virtual a través de enlace de datos
• En MVP, la vista está ligada a un modelo que cuelga del Supervisor Controlador o no está enlazado (vista pasiva).

modelo de vista => Ver

MVVM

1. INPC/propiedad de unión
2. Eventos
3. Mensajes (marco Evento Agregador/mensajero/RX)
4. través de un intermediario como un servicio
5. A través de una interfaz
6. A través de delegados (Ver pasa delegados a la máquina virtual que puede utilizar para devolver la llamada. Por ejemplo, VM podría exponer un método SetActions que delegue las llamadas a la Vista pasando por él.

MVP

En el caso MVP el estándar es de las conversaciones del presentador de nuevo a la vista ya sea a través de una interfaz, de enlace de datos, o a través de propiedades en el caso de vista pasiva. Con la vista pasiva, las propiedades no utilizan el enlace de datos, en cambio, los captadores y definidores de propiedades de vista se usan para establecer directamente el valor de control.

¿Qué opina de esa idea?

¿Cree que está bien que ViewModel tenga la interfaz de View?

Si quieres añadir más de lo que es agradable añadir ... :)

La idea acerca de esta entrada es conseguir la misma comprensión de patrón MVVM en la Comunidad.

Answer 1

Me gusta lo que has escrito.Una de las cosas que realmente me molesta es que mucha gente parece tener su máquina virtual acoplada muy estrechamente a su vista. Si estás haciendo esto, entonces también podrías estar haciendo el antiguo XAML + todo lo que se golpeó en el código detrás cosa.

El patrón que uso es una ligera variante en el MVVM (pero es más o menos el mismo). Personalmente, me gusta que mi ViewModel sea otorgado a la Vista como una interfaz, mantiene la separación muy limpia. Esto tiene un gran beneficio al hacer prototipos, los elementos visuales se pueden conectar o desconectar de la Vista con poco o ningún impacto en ViewModel.

Answer 2

Creo que la comunicación entre View ViewModel a través de enlace de datos es lo que hace que MVVM sea su propio patrón en comparación con otra separación de preocupaciones. No es tanto si es BUENO o MALO para que la vm sepa sobre la vista a través de la interfaz, sino que en el contexto de la comunicación del patrón que se está utilizando no es MVVM.

Parte de la dificultad para obtener y mantener los estándares radica en las deficiencias y la complejidad de WPF y Silverlight, lamentablemente. Sin embargo, cuando hay varios estándares válidos, me pongo mi sombrero de Martin Fowler y agrego una sección "cuándo usarlo".

¿Sus normas cubren preocupaciones transversales como la localización?

Fwiw me gusta el contenido de lo que ha escrito y me alegro informados aquí ...

Saludos,
Berryl