¿WinForms está muerto o agonizando?
No. No se desarrolla significativamente más (es decir, no hay nuevos principales adiciones), pero es totalmente compatible en .NET 4, por ejemplo.
¿Es WPF una buena tecnología para aprender?
Sí.
¿Es el futuro, solo una fase o una tecnología que puede ir de la mano junto con WinForms?
Se pretende que el tiempo se trasladaría a WPF, pero también se entiende que existen grandes bases de código existentes escritos en WinForms, y no hay caso de negocio para volver a escribir en WPF. Por lo tanto, WinForms sigue siendo compatible.
Además, cualquier experiencia será buena para escuchar, especialmente de personas que han usado ambas cosas extensamente. ¿Cómo encontraste la implementación de una característica similar en ambos frameworks?
En términos generales, WPF es mucho más expresivo. Si nos fijamos en los marcos como un conjunto de ladrillos Lego que se pueden juntar de varias maneras, los ladrillos WinForms son mucho más grandes, cada uno hace mucho, y por lo tanto hay menos formas de unirlos. Muy a menudo, cuando necesita algo, pero no exactamente, como lo hace un ladrillo existente, tiene que escribir el suyo desde cero. En WPF, los ladrillos son significativamente más pequeños y se pueden combinar de muchas maneras interesantes e incluso sorprendentes.
Para un ejemplo concreto, considere cómo WPF Button es un contenedor que puede albergar contenido arbitrario, no solo imágenes + texto como en WinForms, sino cualquier otro control o conjunto de controles de WPF.
WPF también es mucho más fácil de escribir diseños dinámicos en comparación con WinForms. Este último también tiene diseños, pero el problema es que son un PITA real para trabajar con el diseñador visual, y escribir la inicialización del componente WinForms por código es muy tedioso. Con WPF, simplemente escribe el marcado XAML a mano, y los diseños (y los árboles de control en general) se representan de forma muy natural en XML.
Partiendo parcialmente de lo anterior, me parece que WPF es más fácil de localizar. Por un lado, es porque realmente necesita diseños dinámicos para localizabilidad (ya que no conoce de antemano la longitud de las cadenas en todas las configuraciones regionales). La solución de WinForms para esto es considerar no solo las etiquetas de texto, sino también la posición y el tamaño de control, como "propiedad localizable", por lo que se supone que el traductor reorganizará los controles en el formulario si encuentra que las cadenas no encajan. En WPF, los diseños dinámicos son el enfoque predeterminado, por lo que el localizador solo trata con cadenas.
El marco de enlace de WPF es bastante potente (incluso si es detallado, gracias a la falta de conversores en línea), y promueve en gran medida el MVP y, en general, la separación de modelo/vista. Esto es posible de lograr con WinForms en 2.0+, y trato de hacer eso allí también, pero es más tedioso, especialmente con respecto a la manipulación nula, y en ocasiones puede ser rather buggy.
Un punto de dolor particular es la forma en que el diseñador de WinForms interactúa con el control de origen. Hay dos problemas similares aquí. En primer lugar, el diseñador serializa el formulario editado como código, y en ocasiones cambios muy pequeños en el diseño pueden hacer que el diseñador genere un código completamente diferente (esto se nota especialmente si edita barras de herramientas) porque mezcla las líneas de código, es decir, en realidad valor de propiedad individual en una línea, pero también reordenó todo. Esto lleva a mucho ruido en la historia (es casi imposible decir qué fue exactamente cambiado cuando se observan los diffs), pero lo más importante es que la fusión de dichos archivos es un gran dolor de cabeza. Esto generalmente ocurre cuando dos personas trabajan con el mismo formulario al mismo tiempo, y luego uno comete sus cambios, y el otro intenta comprometerse, descubre que el archivo fue cambiado mientras tanto, intenta fusionarse, ve los diffs, y salta fuera de la ventana más cercana.
Un problema muy similar ocurre cuando se utilizan formularios localizables de WinForms, que empuja algunas propiedades a un archivo de recursos. Una vez más, al diseñador le gusta reordenar los valores de las propiedades en el archivo de recursos para cualquier cambio trivial, con los mismos problemas que se describieron anteriormente.
Ahora en cuanto a las deficiencias en WPF. Uno de los más importantes es que es bastante más complicado y puede que no le resulte familiar a alguien con experiencia solo en WinForms, VCL, VB u otros marcos "tradicionales" similares. Otro problema es que la documentación, en mi opinión, no es perfecta; por lo general ofrece una visión decente, pero rara vez cubre casos de esquina, algunos de los cuales pueden ser bastante importantes. Este es también el caso de WinForms, pero hay menos combinaciones posibles allí, por lo que también hay menos casos de esquina.
También está la cuestión de los componentes de terceros. WinForms había existido por mucho tiempo, y hay muchos disponibles, y muchos de ellos son muy maduros. WPF es comparativamente joven y todavía sufre dolores de crecimiento, al igual que la mayoría de las soluciones de terceros.
Una de mis preocupaciones favoritas en WPF es la forma en que antialiases el texto, que se percibe como de calidad mucho peor en comparación con ClearType de Windows por la mayoría de las personas, especialmente en tamaños de letra pequeños; vea this bug report para más información. Esto se soluciona en WPF 4, pero aún no se ha lanzado, e incluso cuando lo sea, es probable que desee seguir con el comprobado 3.5 SP1 durante un tiempo; y la solución no se transfiere.
¡Gracias! Esta es la respuesta perfecta, exactamente el tipo de información que estaba buscando. Me gustó tu analogía de lego-brick. Intenté ignorar WPF, pero los comentarios aquí me han convencido de que es hora de comenzar a aprender. – DanDan
Como nota al margen, una buena señal de madurez de una determinada tecnología de MS es si MS utiliza esa tecnología. Al escribir estas líneas, hay un producto principal de MS que usa WPF exclusivamente: Expression Blend, y uno de los próximos productos principales que usa mucho WPF, y lo usa solo para cualquier UI nueva, dejando WinForms y Win32 nativo para algunos bits heredados. - VS2010. Entre otras cosas, significa que cualquier deficiencia de WPF que afecte negativamente esos productos recibirá mucha atención. Sé que hubo bastantes soluciones WPF para .NET 4 debido al uso de VS2010 :) –
VS2010 fue codificado en WPF, y se muestra por cierto que se ve en comparación con 2008, pero la última vez que lo probé fue con errores y tenía colores feos :) –