Transición de formularios Windows Forms a WPF

113

Durante mucho tiempo, he estado atascado con el desarrollo de Windows Forms (comencé con VB6 y ha continuado hasta C # .NET 4.5), y he llegado al límite de lo que Windows Forms puede hacer, ambos usando .NET puro y efectos especiales con Native Code.

He intentado aprender WPF y XAML, pero me quedo atascado en el nuevo diseñador de WPF. Realmente parece muy difícil de usar en comparación con el diseñador de Windows Forms.

Quiero saber si existen alternativas al diseñador WPF de .NET que sean más adecuadas para los desarrolladores de Windows Forms.

c# wpf windows winforms windows-forms-designer Matthew Layton
fuente
7
Por lo general, ni siquiera uso el diseñador, salvo para comprobar si el diseño general es el que esperaba; al final, escribo todo a mano en XAML y / o uso Blend cuando es necesario, aunque no soy diseñador, por lo que casi nunca sucede.
Patryk Ćwiek
Puede usar Expression blend, pero no creo que sea realmente más fácil, es más para diseñadores que para desarrolladores, en mi opinión. Normalmente apago la vista previa y trabajo con xml.
BlackICE
5
No es difícil de usar, simplemente no está acostumbrado. El mayor obstáculo a superar es el cambio de paradigma entre las dos tecnologías. Consiga un buen libro sobre XAML, una vez que se acostumbre a XAML, ni siquiera volverá a usar el diseñador; escriba XAML directamente.
slugster
3
@slugster, me pregunté sobre eso. Lo mismo sucedió con HTML ... Solía ​​construir la interfaz de usuario con Dreamweaver, y ahora codifico HTML a mano
Matthew Layton

Respuestas:

175

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

En resumen, la mayor diferencia entre Winforms y WPF es que en WPF su capa de datos (la 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 su aplicación consta de los objetos que crea, y usa Plantillas y otros objetos de IU para decirle a WPF cómo dibujar los componentes de su aplicación.

Eso es lo opuesto a WinForms, donde construye su aplicación a partir de objetos de interfaz de usuario y luego les proporciona los datos necesarios.

Debido a esto, el diseñador en realidad no se usa tanto ya que los componentes de su aplicación están diseñados en código, y el diseñador solo es necesario para dibujar una interfaz fácil de usar que refleje sus clases de datos (generalmente Modelsy ViewModels)

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

Entonces, para responder 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 usar WPF de la manera en que debe usarse. Usar WPF como si fuera WinForms significa que se pierde mucho de lo que lo hace tan bueno :)

Raquel
fuente
14
Totalmente de acuerdo con @Rachel. La conclusión más importante al conocer WPF es comprender que la interfaz de usuario no son datos y actuar en consecuencia.
Federico Berasategui
2
@Rachel: solo para jugar al abogado del diablo: comenzar con la interfaz de usuario (qué botones, cuadros de texto, etc. aparecen en la ventana) ayuda a enfocar la aplicación en lo que quieres hacer. El resto son solo detalles de implementación de cómo desea hacerlo.
Asaf
3
@HighCore eche un vistazo a stackoverflow.com/questions/982978/mvvm-for-winforms y tendrá que reconocer que Winforms es solo un componente de vista / interfaz de usuario en el que los objetos comerciales pueden vincularse a los controles de usuario. Bien: WPF es más adecuado para MVVM pero, sin embargo, Winforms también puede funcionar en un patrón de diseño de este tipo. Y, como dice Rachel, "Eso es lo contrario de WinForms, donde construye su aplicación a partir de objetos de IU y luego les proporciona los datos necesarios". Aunque es tan falso. Siempre pienso en una forma de al menos Datos y Vista. Datos y Winforms / WPF / HTML lo que sea.
Bernoulli IT
2
Admite el enlace de datos al menos en el nivel de entrada / modificación de datos. Y sospecho que ese 99,9999999% de los desarrolladores también se equivocarán en WPF. Pero terminemos esta discusión. WPF es absolutamente más poderoso / adecuado para MVVM y una separación de preocupaciones, pero creo que tú y Rachel también empujan a Winforms en una esquina negativa. Especialmente cuando sigues usando las palabras que usas ...
Bernoulli IT
3
@YoupTube Tiene razón, Winforms admite el enlace de datos, y es posible crear sus propios enlaces personalizados para los casos en los que el sistema de enlace predeterminado tampoco funcionará. Sin embargo, escribí esta respuesta y los artículos de mi blog pensando en los principiantes y, por lo general, los principiantes piensan en términos de componentes de interfaz de usuario, no de objetos de datos. Además, el enlace en WinForms no siempre existió en el estado actual, por lo que muchos desarrolladores que crecieron con WinForms, o que están acostumbrados a otras tecnologías que no usan enlaces, a menudo no identificarán esta diferencia clave al cambiar a una arquitectura ligada. :)
Rachel
9

Bueno, aunque algunas personas no están de acuerdo, también recomendaría no usar el diseñador VS. Al menos no para crear una interfaz. Si desea tener una primera impresión de su implementación sin iniciar la aplicación, es un buen visor al menos siempre que no se utilicen cosas sofisticadas como Stylesy Templates. Pero, en mi humilde opinión, su resultado de arrastrar y soltar solo debe usarse como prototipo y, por lo tanto, debe descartarse una vez que ya no sea necesario.

Aquí hay algunas razones que son importantes para no usarlo.

  1. El diseñador de VS está trabajando con márgenes fijos y alineaciones (lo que generalmente no es necesario, si está usando los controles de diseño), significa que debe tocar muchos controles, si se cambian los requisitos. Si está familiarizado con XAML y la mecánica de WPF, puede crear aplicaciones que se pueden modificar con un pequeño esfuerzo, con respecto a la apariencia.

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

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

Volviendo a tu pregunta, en mi humilde opinión, y creo que mucha gente está de acuerdo, consíguete un buen libro, por ejemplo, WPF Unleashed y más tarde, si quieres saber más sobre los detalles, WPF Pro . Hay muchas características que son diferentes a Winforms. No los conocerá utilizando ningún diseñador. Creo que ese es el mejor enfoque.

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

DHN
fuente
9

Sé que esta es una pregunta antigua, pero para beneficio de cualquier otra persona que mire esto, creo que debería corregir 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 'El sentimiento proviene de no usarlo correctamente. Este tutorial es bastante bueno para comenzar y responde a algunas de las críticas en las otras publicaciones.

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

Este video cubre un terreno similar.

Sigo prefiriendo el diseñador VS2010 en general: VS2013 parece tener un poco de errores al arrastrar y soltar en TabItems **, (que mi proyecto actual usa mucho), pero la vista Esquema del documento VS2013 también le permite mover las cosas en esa vista. , lo que puede ser una verdadera ventaja.

Realmente, sin embargo, 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 ellas; si te alejas del diseñador, te estás perdiendo algo que puede ayudarte mucho.

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

PeterG
fuente
7

En primer lugar, en WPF (XAML) en Visual Studio deisgner, siempre debe usar el código xaml para construir su interfaz de usuario y no arrastre y suelte su control. Necesitas mantener tu código limpio. Puede usar Expression Blend para ayudarlo, 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ía aprender a hacer su xaml a mano en lugar de buscar alternativas.

mlemay
fuente
1
Arrastrar y soltar no hace ningún daño, aunque si prefiere escribir, también está bien. Escribir manualmente nunca es la clave para WPF.
David
3
Cuando arrastras y sueltas en WPF, veo que a menudo tienes mucho margen de -1200 y cosas así que no tienen ningún sentido ... Siempre lo he hecho a mano, seguro que es mejor
mlemay
1
Esto está fuera de tema. Asegúrese de que su problema sea común para todos, no solo para usted. Además, no puede decir que arrastrar y soltar sea malo, si tiene algunos problemas. Depender del diseñador todavía es necesario y, a veces, se favorece, puede ver que esto es cierto, si sabe cómo la expresión es bienvenida tanto por el diseñador como por los desarrolladores.
David
1
sí, si usa la combinación de expresiones, está bien, puede hacerlo, pero estaba hablando en Visual Studio ...
mlemay
12
Creo que aconsejar a alguien que viene de Forms y está iniciando WPF para que no use el diseñador es una muy mala idea. La forma más rápida de comprender XAML es arrastrar y soltar y luego observar el código.
Ucodia
7

He pasado por este proceso como tú. Luego estuve enseñando a todos en mi empresa WPF. Hay un par de lecciones importantes que he aprendido y todos los que conozco que trabajan con WPF.

  1. Si está trabajando con controles de IU en el código subyacente, ... entonces lo está haciendo mal. No hay absolutamente ninguna necesidad de que se ocupe de los controles de la interfaz de usuario en el código subyacente.
  2. No necesita el desarrollador visual para hacer clic en él. Es mucho más productivo al tratar solo con XAML. Utilice Copiar / Pegar. No confíe en sus capacidades de escritura. Ahorrará muchos dolores de cabeza.
  3. Piense en XAML simplemente como una ventana que mira los datos. En el código que está detrás de usted, está cambiando los datos. En XAML, 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á por las nubes. Ellos asumirán el papel de la gran cantidad de controladores de eventos de control que se esconden o cambian de tamaño, o lo que sea sobre la interfaz de usuario,

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

user853710
fuente