La transición de Windows Forms a WPF

Durante mucho tiempo, me he quedado atrapado en el desarrollo de Windows Forms (comencé con VB6, y continué hasta C # .NET 4.5), y he llegado al límite de lo que Windows Forms puede hacer, ambos usando pure .NET y efectos especiales con Native Code.

Sé que WPF es el futuro (por ahora), y Windows Forms se está desacelerando convirtiéndose en una tecnología obsoleta.

He tratado de aprender WPF y XAML, pero me quedo atrapado en el nuevo diseñador de WPF … Realmente parece muy difícil de usar en comparación con el diseñador de Windows Forms … por supuesto … esto es solo una curva de aprendizaje, y en algún momento planeo seguir un curso para aprender WPF correctamente.

Mientras tanto, quiero saber si hay alguna alternativa al diseñador WPF de .NET, que sea más adecuada para los desarrolladores de Windows Forms.

Me gusta escribir artículos sobre principiantes para WPF en el blog, y hay algunos en particular que pueden ayudarte:

  • Comprender el cambio en la mentalidad al cambiar de WinForms a WPF
  • ¿De qué es este “DataContext” del que hablas?
  • Un ejemplo MVVM simple

En resumen, la mayor diferencia entre Winforms y WPF es que en WPF su capa de datos ( DataContext ) es su aplicación, mientras que en Winforms su capa de interfaz de usuario es su aplicación.

Para verlo de otra manera, con WPF tu aplicación consiste en los objetos que creas, y usas Plantillas y otros objetos UI para decirle a WPF cómo dibujar los componentes de tu aplicación.

Eso es lo opuesto a WinForms donde construyes tu aplicación a partir de objetos UI y luego les proporcionas los datos necesarios.

Debido a esto, el diseñador no se usa mucho ya que los componentes de la aplicación están diseñados en código, y el diseñador solo necesita dibujar una interfaz fácil de usar que refleje sus clases de datos (típicamente Models y Models ViewModels )

Y, personalmente, prefiero escribir todo mi XAML a mano, ya que es más rápido y no hace tanto desorden como el diseñador de WPF arrastrar / soltar, aunque sí uso el Diseñador en ocasiones para previsualizar lo que mi interfaz de usuario se verá me gusta.

Entonces, para su respuesta a su pregunta sobre si hay otros diseñadores de WPF adecuados para los desarrolladores de WinForms, sugeriría que en lugar de buscar otro diseñador, busque aprender a utilizar WPF de la manera en que debe ser utilizado. Usar WPF como WinForms significa que te pierdes mucho de lo que lo hace tan genial 🙂

Sé que esta es una vieja pregunta, pero para el beneficio de cualquier otra persona que mire esto, creo que debería restablecer un poco el equilibrio. Al leer algunas de las otras respuestas, tengo la sensación de que algunos de los ‘no usan el diseñador’ ‘sentimiento proviene de no usarlo correctamente. Este tutorial es bastante bueno para comenzar y responde algunas de las críticas en las otras publicaciones.

Por ejemplo, puede cambiar desde el diseño basado en márgenes similar a Winforms que es el predeterminado cuando suelta un control, a un estilo más WPF-ish haciendo clic derecho y seleccionando ‘Restablecer diseño’.

Este video cubre un terreno similar.

Todavía prefiero el diseñador de VS2010 en equilibrio: VS2013 parece tener problemas al arrastrar y soltar en TabItems **, (que mi proyecto actual usa mucho), pero la vista de esquema de documento VS2013 también permite mover cosas en esa vista. , que puede ser una ventaja real.

Realmente, para aprovechar al máximo WPF y xaml, debe ser razonablemente fluido tanto en la vista del diseñador como en la vista xaml y cambiar entre ellos; Si te alejas del diseñador, te estás perdiendo algo que puede ayudarte mucho.

** Editar: aunque parece haber mejorado en la Actualización 3 para VS 2013, y en las vistas previas de VS14, a la fecha todavía tengo un comportamiento extraño a veces.

Bueno, aunque algunas personas no estén de acuerdo, también recomendaría no usar el diseñador de VS. Al menos no para crear una interfaz. Si desea obtener una primera impresión de su implementación sin iniciar la aplicación, es un buen visor al menos mientras no se utilicen elementos sofisticados como Styles y Templates . Pero, en mi humilde opinión, su resultado de arrastrar y soltar solo se debe utilizar como prototipo y, por lo tanto, se descartará después de que ya no se necesite.

Aquí hay algunos motivos que son importantes para mí para no usarlo.

  1. El diseñador de VS está trabajando con márgenes y alineaciones de arreglos (que generalmente no es necesario, si usa los controles de diseño), lo que significa que debe tocar muchos controles, si se modifican los requisitos. Si está metido en XAML y en la mecánica de WPF, puede crear aplicaciones que se puedan modificar con un pequeño esfuerzo en cuanto a la apariencia.

  2. Dado que el diseñador está generando xaml, la composición no es óptima y la IU puede tener un mal rendimiento. No lo medí, es solo un sentimiento.

Una alternativa mucho mejor es MS Blend , aunque el comienzo es todo lo demás pero fácil. Su resultado de arrastrar y soltar es mucho mejor que el resultado del diseñador de VS.
Pero es una herramienta bastante poderosa, que te ayuda a utilizar elementos bastante poderosos para crear una interfaz de usuario de vanguardia. Recomiendo visitar al menos un taller corto para tener una idea de sus oportunidades.

Volviendo a su pregunta, en mi humilde opinión, y creo que muchas personas están de acuerdo, consígase un buen libro, por ejemplo, WPF Unleashed y, más adelante, si quiere saber más sobre los detalles, WPF Pro . Hay muchas funciones diferentes a Winforms . No los conocerá usando ningún diseñador. Creo que ese es el mejor enfoque.

Tenga en cuenta también que existen muchos marcos y bibliotecas (por ejemplo, MVVM light , WPFToolkit ) que ya están resolviendo algunos problemas comunes. Entonces no es necesario reinventar la rueda.

En primer lugar, en WPF (XAML) en Visual Studio deisgner, siempre debes usar el código xaml para construir tu UI y no arrastrar y soltar tu control. Debes mantener tu código limpio. Puedes usar Expression Blend para ayudarte, está más orientado a gráficos con arrastrar y soltar, pero no es gratis.

No es una gran curva de aprendizaje, pero creo que deberías aprender a hacer tu xaml a mano en lugar de buscar una alternativa.

He pasado por este proceso como lo hiciste. Luego enseñé a todos en mi empresa WPF. Hay un par de lecciones importantes que aprendí y todas las personas que conozco que trabajan con WPF.

  1. Si está trabajando con controles UI en el código subyacente, …. Entonces lo está haciendo mal. No es necesario que se ocupe de los controles de UI en el código subyacente.
  2. No necesita el desarrollador visual para hacer clic en él. Eres mucho más productivo al solo tratar con XAML. Use Copiar / Pegar. No confíe en sus capacidades de tipeo. Ahorrará muchos dolores de cabeza.
  3. Piense en el XAML como una ventana que se centra en los datos. En el código detrás de ti estás cambiando los datos. En XAML, usted está definiendo cómo la interfaz de usuario interpretará los datos.
  4. Los convertidores son increíbles Tan pronto como obtenga una cantidad clave de Convertidores, su productividad se disparará en Sky. Ellos asumirán el rol de la gran cantidad de controladores de eventos que ocultan o cambian de tamaño, o lo que sea sobre UI,

Hace que el desarrollo de la interfaz de usuario sea divertido. Especialmente una vez que descubres cómo le gusta jugar con los procesos Asyc. Realmente quita muchos de los dolores de cabeza causados ​​por Winforms.