Valor de MVVM en una aplicación de línea de negocio (y una serie de prácticas de desarrollo actuales)

Después de 2 años, todavía estoy luchando con MVVM como método práctico para producir software de trabajo. En algunos casos es genial. Hice una aplicación multiproceso que controlaba una pequeña línea de ensamblaje que habría sido una pesadilla sin conceptos MVVM. Una abstracción de la línea de montaje física era casi obvia.

Sin embargo, mi carrera gira principalmente en torno a la línea interna de aplicaciones comerciales: formalizar y optimizar las operaciones de un negocio. En tales aplicaciones, generalmente hay una inquietud comercial que gira en torno a CRUD y operaciones compuestas. En los LOB, mis modelos de vista terminan siendo una colección muy simple de funciones de envoltura de una línea de los métodos de clase empresarial y al final solo terminan complicando las tareas más simples como mostrar un cuadro de mensaje o abrir una ventana. ¿A nadie más le resulta extraño cuando la gente entra en largas descripciones de "inyección de dependencia" y "proveedores de mensajes" para una llamada Window.ShowDialog que ha existido durante décadas? ¿Cuántas otras preguntas hay sobre el desbordamiento de la pila pidiendo consejos para tareas que fueron extremadamente simples en winforms?

No me malinterpreten: obtengo MVVM y cómo podría ser invaluable para los grandes equipos que realizan el desarrollo horizontal de un paquete de software reducido y comercializado. La prueba de la unidad de los modelos de vista podría ahorrar millones al evitar un error RTM malo y los desarrolladores de IU dedicados podrían brindar una experiencia enriquecedora. Pero cuando el costo de redistribución es mínimo y todo lo que la empresa se preocupa por pagar es un simple software de trabajo, ¿por qué debería pasar tiempo en la unidad probando una simple "envoltura" cuando mi lógica de negocios ya está probada? ¿Cuánto tiempo realmente me va a permitir el negocio dedicar animaciones lindas y esquemas de colores? ¿Queda algo para que un desarrollador junior haga (rastrear un error en una funcionalidad de guardar solía mirar "Save_Click",

Es cierto que me gusta mucho el enlace de datos de WPF. Para aprovecharlo, configuro el contexto de datos en la ventana en sí, donde tiene acceso a la clase de negocios, así como a otras propiedades observables. Sí, rompo casi todas las "reglas" MVVM al hacerlo. Pero al menos tengo un código simple controlado por eventos que es fácil de leer Y aprovecho el nuevo enlace de datos y la validación. El problema está en los diseñadores, que no uso mucho, pero espero que ahora esté mejor integrado en 2012, el diseñador muestra los cientos de propiedades que tiene una ventana y sus clases base.

Para aquellos que pueden relacionarse, ¿pueden señalarme recursos, libros o incluso solo cambios de perspectiva que hicieron que esto fuera más fácil de tragar? Le daré otra oportunidad a MVVM, pero la última vez que me sentí bastante estúpido por preocuparme por la inyección de dependencia solo para mostrar un cuadro de mensaje de una VM no tenía intención de realizar pruebas unitarias. Incluso si hice una prueba unitaria, ¿realmente estamos obteniendo más calidad al intercambiar pruebas de tiempo de ejecución por errores de tiempo de compilación de esas temidas aplicaciones "estrechamente acopladas"?

Me doy cuenta de que una respuesta es quedarse en winforms. Pero como uno de los últimos partidarios de WebForms (tengo la misma crítica de la tendencia del desarrollo web), me sentí un poco como un dinosaurio como cuando descubrí que no quedan más WebForms en las pistas de certificación de Microsoft. Avanzar es la única opción, incluso si no me gusta.

Mi perspectiva es de años de experiencia trabajando con Winforms, la "forma antigua", con eventos y código subyacente. Entonces, puedo decirle con absoluta certeza que, una vez que supera las aplicaciones más simples, su código se convierte rápidamente en una gran bola de barro . Era inevitable, porque esa era la forma en que las aplicaciones se escribían en aquel entonces.

Webforms es igual, excepto que agrega la complicación adicional de ser una abstracción con estado sobre un sistema sin estado (la web). Como dijo Rob Conery:

WebForms es una mentira. Es una abstracción envuelta en un engaño cubierto de salsa de mentira presentada en un plato lleno de diversión y juegos de manos. Nada de lo que haga con Webforms tiene algo que ver con la web: deja que haga el trabajo por usted.

Esto, del tipo que escribió un mapeador relacional de objetos completamente funcional usando la dynamicpalabra clave en C # y solo cuatrocientas líneas de código. Cuando habla con autoridad sobre algo, lo escucho.

La aplicación en la que estoy trabajando actualmente es una aplicación Winforms, con varias pestañas en el formulario principal. Puedo cargar dinámicamente formularios en cada una de las pestañas. Si bien no seguí MVVM o MVP (puedes hacerlo, con bibliotecas como esta ), empujé agresivamente cada bit de código que pude a un ensamblaje separado, dejando solo ese código que es absolutamente necesario para ejecutar el formulario. Todavía hay varios cientos de líneas de código allí, sin contar la clase parcial que contiene las definiciones de control del formulario, las propiedades y las asignaciones de controlador de eventos, pero nunca debería tener que tocarlo nuevamente, a menos que necesite agregar algo nuevo al formulario.

Tengo un método estático en el que puedo entregar un formulario y una colección de pares Clave / Valor, y (usando Reflection) emparejará automáticamente las teclas con los campos del formulario y completará el formulario con los valores de la colección. También puedo hacer lo contrario, obteniendo una colección de pares Clave / Valor de los campos del formulario. Todo esto tiene alrededor de veinte líneas de código, pero se amortiza cada vez que lo uso, porque no tengo que escribir cuarenta declaraciones de asignación personalizadas para cuarenta controles en un formulario.

Puedo tomar esa lista de Clave / Valor y serializarla a XML, lo que me permite conservarla en un archivo. Tengo otras formas en las que puedo entregar un DTO convencional y asignar sus campos al formulario. Nada de esto sería práctico en el estilo de "gran bola de barro" de Winforms. Es casi trivial cuando se utiliza el desacoplamiento adecuado.

¿Algo de esto suena familiar? Debería; Es esencialmente la forma de vinculación de datos de un hombre pobre.

Es cierto que me gusta mucho el enlace de datos de WPF. Para aprovecharlo, configuro el contexto de datos en la ventana en sí, donde tiene acceso a la clase de negocios, así como a otras propiedades observables.

Bien por usted. No tiene que ser compatible con MVVM. Pero recuerde, patrones como MVVM fueron creados para ayudar a los desarrolladores a construir grandes sistemas. Si solo necesita mostrar un cuadro de diálogo, es posible que no necesite toda esa plomería.

Parte de la complejidad de sistemas como WPF es inherente a todas las bibliotecas de programadores que buscan resolver un problema específico de forma generalizada. Para hacer eso, debe tener en cuenta todas las formas prácticas en que un programador puede usar su biblioteca. Eso agrega complejidad, pero para aquellos que diseñan bien sus bibliotecas, también trae a la mesa una filosofía de hacer las cosas de manera uniforme y consistente.

Considere la biblioteca jQuery de John Resig: es la esencia misma de un diseño coherente y oculta muchos detalles extraños sobre el DOM y las variaciones en la forma en que los navegadores lo manejan. ¿Es más simple escribir algunas líneas de Javascript? Algunas veces. Pero el beneficio de escribir código jQuery en una API coherente y uniforme hace que sea más fácil para la próxima persona que viene entender lo que hizo y mantener ese código si es necesario.

Mi experiencia real con los modelos de "grandes aplicaciones" está en el uso de ASP.NET MVC. ASP.NET es para ASP.NET MVC como Winforms es para WPF. Cuando trabajaba en ASP.NET, siempre me costaba adaptarlo a mi voluntad. ASP.NET MVC se inclina hacia usted. Es un placer usarlo; Produce una estructura de sistema clara y organizada, y le brinda control total sobre su aplicación y marcado. Puede usar Javascript, jQuery y CSS libremente, y ASP.NET MVC se mantiene fuera de su camino.

Mi único obstáculo era acostumbrarme y conocerlo en sus propios términos.

Lecturas adicionales
que debes aprender MVC por Rob Conery