2010-03-15 16 views
7

Estoy trabajando en una aplicación WPF, y la estoy estructurando usando el patrón MVVM. Inicialmente, tuve la idea de que los ViewModels deberían ser reutilizables, pero ahora ya no estoy tan seguro.¿Qué tan reutilizables deberían ser las clases de ViewModel?

  • ¿Debo ser capaz de reutilizar mis ViewModels si necesito una funcionalidad similar para una aplicación WinForms?
  • Silverlight no es compatible con todas las cosas que hace WPF, ¿debería poder volver a utilizar para las aplicaciones de Silverlight?
  • ¿Qué pasa si quiero hacer una GUI de Linux para mi aplicación? Entonces necesito ViewModel para construir en Mono. ¿Es esto algo por lo que debería esforzarme?
  • Y así sucesivamente ..

Así; ¿Debería uno escribir clases de ViewModel con una Vista específica en mente, o pensar en la reutilización?

+0

Esta es una pregunta anterior, pero [la respuesta de MSDN] (https://msdn.microsoft.com/en-us/library/hh563947 (v = vs.110) .aspx) es muy clara (y contraria) a todas las respuestas publicadas a continuación): el ViewModel está específicamente diseñado para ser compartido por muchas vistas en varios sistemas operativos. Hacer lo contrario conduciría inevitablemente a un código redundante. – kmote

Respuesta

12

Para responder a su pregunta, piense solo principio Responsabilidad:

"Una clase debe tener uno, y sólo uno , razón para cambiar."

Yo diría que, dentro de lo razonable, normalmente no desea volver a utilizar un ViewModel para múltiples vistas. La razón principal por la que abogaría por esto es porque eso le daría a su ViewModel más de un motivo para cambiar. En otras palabras, tendría que cambiar si una u otra vista cambia, y en mi opinión, esas son dos razones para cambiar. ¿Dónde se detiene? Lo mantendría simple en este caso, y vincularía un ViewModel a la Vista.

Otra cosa en que pensar con MVVM con WPF es la creación de plantillas de datos. Es mucho más fácil de lograr si cada ViewModel abastece a una y solo una vista.

+0

Estoy totalmente de acuerdo. ¡Y ese es un excelente argumento! – stiank81

3

Simplemente, en general, aplique el principio YAGNI: probablemente no vaya a necesitarlo. A menos que pueda ver que estas cosas suceden potencialmente, mantendría el enfoque más simple para que su software funcione según los requisitos que tiene actualmente.

+0

¡Buen punto! :-) – stiank81

2

En mi opinión, el objetivo principal de MVVM es eliminar el código que no se puede probar fácilmente mediante pruebas unitarias. Debido a que un modelo de vista puede ser probado por unidades, pero una vista no puede, esto se logra al hacer que la vista sea lo más tonta posible. Idealmente, como se puede hacer con XAML, la vista es completamente declarativa y solo se une a datos en un modelo de vista. De ahí el mantra "sin código detrás".

La posibilidad de volver a utilizar el modelo de vista en diferentes tecnologías de interfaz de usuario no es realmente un objetivo de MVVM. Si lo intenta, es probable que tenga la tentación de volver a ver el código específico de la tecnología UI en la vista para mantener el modelo de vista reutilizable. Esto iría en contra del objetivo principal de la capacidad de prueba.

Si realmente necesita soportar diferentes tecnologías de interfaz de usuario, aún podría restar importancia a la lógica común de los modelos de vista en una capa de "presentación" compartida. No haría eso hasta que esté seguro de que es necesario.

0

Esta es una pregunta anterior, por lo que dudo en agregar otra respuesta. Pero todas las respuestas publicadas hasta ahora han perdido el punto.The answer from MSDN es muy clara: El modelo de vista tiene la intención muy específica para ser compartido por muchos puntos de vista a través de diversos sistemas operativos, como se demuestra en esta figura:

enter image description here

Hacer lo contrario conduciría inevitablemente a código redundante.

Cuestiones relacionadas