Actualmente estoy tratando de entender MVVM para WPF: no me refiero a entender el concepto, sino a los detalles básicos de hacer cualquier cosa que esté más lejos de lo habitual que CRUD tonto.

Lo que he notado es que muchos de los marcos, y la mayoría / todas las publicaciones de blog son de 'edades'.

¿Es esto porque ahora es viejo y los bloggers se han mudado a la Siguiente Gran Cosa, o simplemente porque han dicho todo lo que hay que decir?

En otras palabras, ¿hay algo que me falta aquí?

MVVM no está desactualizado, pero para empezar fue exagerado. Nunca me gustó y me mantuvo en WinForms por mucho tiempo; al no poder ver el bosque por los árboles, tiré al bebé con el agua del baño. Ahora tengo WPF, y tengo la idea de no querer mezclar código con marcado, pero prefiero el estilo de Android de pegar el marcado en un lugar y desreferenciarlo con moldes en mi código (que también puedes hacer en WPF, incluso aunque nunca se puso de moda hacerlo por cualquier razón).

De esa manera, obtienes un control más preciso y no tienes que preocuparte por todo el manejo "modificado" en todas partes. Creo que esto es realmente más comprobable porque las pruebas no siempre lo detectarán si se pierde un evento "modificado".

Pierdes un poco de "declaración", lo que parece ser una tendencia en estos días (por ejemplo, si dos widgets se asignan al mismo valor, en MVVM puedes hacer eso, mientras que con el código imperativo tienes que configurar ambos individualmente) . Pero incluso con MVVM, eso solo funciona en el caso de baja categoría. Si algún widget tiene que mostrar el registro de otro widget, entonces tiene que escribir otro controlador y otro evento "onchanged" y, por lo tanto, tendrá que extender la definición de "declarative" para decir que es así.

Actualización 2015

WPF MVVM fue (r) evolutivo para su época. Como fue WPF. Pero ambos tenían sus verrugas. Plain WPF tenía demasiado incorporado (además estaba construido en XML), y era un poco difícil de manejar. (Realmente, si WPF hubiera adoptado un enfoque más de "biblioteca" en lugar de un enfoque de "marco", podría haberse convertido en algo realmente genial y todo el universo tecnológico podría ser completamente diferente ahora). La idea de MVVM fue genial, pero tratar de encajar un MVVM en WPF fue algo hacky ya que 1) C # realmente no podía expresarlo sin una gran cantidad de repeticiones, y 2) las reliquias de WinForms como ventanas emergentes modales aún prevalecían ideológicamente pero no podían ser fácilmente representado en MVVM. Por lo tanto, todo apestaba.

Dicho esto, sigue siendo la única opción realista en Windows cuando necesita transparencia o GPU para aplicaciones LOB.

Por supuesto, React ha dejado MVVM obsoleto. Me decepcionó que VS2015 no tuviera un contador nativo para eso. Por ahora todavía estamos atrapados usando WPF sin procesar (lo cual está bien, pero se siente viejo (realmente se siente tan viejo como winforms ahora), y no tiene una tonelada de funcionalidad incorporada (se siente como un proyecto genial pero abandonado) o con MVVM, que en este punto se siente como una sobrecarga para nada, ya que incluso MVVM bueno (angular 1) ha sido expuesto por sus deficiencias.

Evitaría WPF MVVM. Es una capa extra, y ya nadie se preocupa por eso.

Todo dicho y hecho, hay un límite de lo que puede hacer con un marco MVVM.

Están "listos" ya que WPF no se ha movido desde que Microsoft lo lanzó. Si hubiera actualizaciones de la tecnología, las bibliotecas también tendrían que actualizarse. Esto no ha sucedido.