Recientemente comencé a usar el patrón MVVM. He tenido varios proyectos donde lo usé y con cada uno nuevo, empiezo a ver que encajará bien en ese nuevo proyecto.¿Cuándo NO se debe usar MVVM?
Y ahora empiezo a preguntarme si hay alguna situación cuando es mejor NOT para usar MVVM. ¿O es un patrón tan agradable que puedes usar en cualquier lugar?
¿Podría describir varios escenarios donde MVVM no sería la mejor opción?
Puedo pensar en dos circunstancias bajo las cuales no usaría MVVM.
Una es si la aplicación es lo suficientemente simple como para no necesitar una separación entre el modelo de vista y el modelo. ¿Asusta demasiado mi clase si implemento INotifyPropertyChanged y RelayCommand o dos? De lo contrario, podría omitir el paso de crear una clase separada. O quizás solo quiera un modelo de vista para simular una interfaz de usuario funcional y preocuparse por la implementación de la funcionalidad real de fondo si el cliente muerde.
La otra es cuando necesito un rendimiento suficientemente alto, y hay suficientes objetos en la vista, que necesito escribir código que manipule objetos WPF directamente.En realidad no lo he comparado, pero estoy razonablemente seguro de que dibujar 1000 partículas en movimiento iterando a través de una matriz que las contiene y modificando su TranslateTransform directamente (si de hecho esa es la forma más rápida de posicionarlas) va a ser más rápido que modificar sus propiedades base y tener enlace hacerlo.
Para mí es mejor no usarlo cuando quiera hacer un pequeño proyecto o nunca planear hacerlo funcionar de varias maneras (WPF/Silverlight/WEB/Dll), entonces MVC es suficiente.
Solo no utilizo MVVM si es una herramienta que no se usa más que en un momento específico y nunca más.
En muchos proyectos "pequeños", he comenzado sin, y más adelante, he cambiado a MVVM. Hace que los proyectos IMO sean mucho más limpios y le da a todos mis proyectos una estructura similar. Esto me ayuda mucho a cambiar rápidamente algunas cosas en algún código antiguo si un cliente tiene una pequeña solicitud. No pierdo mucho tiempo para orientarme.
Otra ventaja es que es más fácil mantener limpias mis bibliotecas, porque puedo centrarme en una técnica y, por lo tanto, tengo más tiempo para mantener y ampliar.
Todo depende de lo que quieras hacer.
Como han dicho los chicos, si está creando una pequeña herramienta o un proyecto que no necesita pruebas exhaustivas, etc., MVVM sería excesivo.
Podría decirse que la principal ventaja de MVVM es que hace que la unidad de código se pueda probar, ya que se abstrae de Visual Layer. Para proyectos grandes que necesitan ser confiables y deben ser utilizados por los clientes, etc. (y no solo usted como usuario final), entonces MVVM es un buen patrón de diseño para usar.
supongo que en pocas palabras - si simplemente está creando un pequeño proyecto para perder el tiempo con MVVM entonces sería como tratar yo matar una hormiga con un bazooka :)
respuesta corta: No utilice MVVM si no está usando WPF/Silverlight/cualquier tecnología que conozca con un poderoso encuadernado automático.
Respuesta larga: Ningún otro patrón facilita las pruebas unitarias mejor que MVVM en WPF/Silverlight. Le sugiero que consulte otra de mis respuestas: Why should I use MVVM in Silverlight app?
Es posible que desee echar un vistazo a A vent about MVVM development en el foro de Silverlight, donde se discuten algunos de los beneficios y deficiencias de MVVM.
También he pensado en el segundo escenario, pero no estoy seguro de qué parte del rendimiento se pierde al usar MVVM. Sería bueno saber cuál es la penalización de rendimiento para usar MVVM y tener enlace de datos en lugar de manipulación de propiedad directa, ya que podría ser tan pequeño que ni siquiera es un problema. – Vitalij