WPF vs. WinForms: ¿la perspectiva de un programador de Delphi?

38

He leído la mayoría de los hilos principales en WPF vs. WinForms y me encuentro atrapado en la desafortunada ambivalencia en la que puede caer al decidir entre la tecnología anterior probada y verdadera (Winforms), y su sucesor (WPF).

Soy un veterano programador de Delphi de muchos años que finalmente está dando el salto a C #. Mis compañeros programadores de Delphi entenderán que estoy emocionado de saber que Anders Hejlsberg, de la fama de Delphi, fue el arquitecto detrás de C #. Tengo una fuerte adicción a los componentes personalizados de VCL de Delphi, especialmente a aquellos involucrados en la creación de asistentes de múltiples pasos y componentes que actúan como un contenedor para componentes secundarios.

Con esos antecedentes, espero que aquellos de ustedes que cambiaron de Delphi a C # puedan ayudarme con mi decisión de WinForms vs. WPF para escribir mis solicitudes iniciales. Tenga en cuenta que soy muy impaciente cuando codifico y cosas como el autocompletado completo y el soporte de depurador adecuado pueden hacer o deshacer un proyecto para mí, incluida la posibilidad de encontrar información fácilmente disponible sobre las funciones y llamadas de la API y, aún más, soluciones para errores .

Los hilos y comentarios de SO a principios de 2009 me preocupan mucho sobre WPF cuando se trata de posibles frustraciones que podrían estropear mi codificación de desarrollo de C # UI. Por otro lado, pasar una cantidad excesiva de tiempo aprendiendo una tecnología API que, incluso si no se abandona, que pronto será reemplazada (WinForms), es igualmente preocupante y encuentro el soporte de GPU en WPF tentador.

De ahí mi ambivalencia. Como todavía no he aprendido ninguna de las tecnologías, tengo una rara oportunidad de comenzar de nuevo y no tener que enfrentar la gran curva de "desaprendizaje" que he visto mencionar en varios hilos cuando un programador de WinForms se muda a WPF. Por otro lado, si usar WPF será demasiado frustrante o tendrá otras consecuencias negativas importantes para un desarrollador RAD impaciente como yo, entonces seguiré con WinForms hasta que WPF alcance el mismo nivel de soporte y facilidad de uso. Para darle un ejemplo concreto de mi psicología como programador, utilicé VB y posteriormente Delphi para evitar por completo el dolor muy real de la codificación con MFC, una biblioteca de interfaz de usuario de Windows que muchos desarrolladores sufrieron al desarrollar las primeras aplicaciones de Windows. Nunca me he arrepentido de mi suerte al evitar MFC.

También sería reconfortante saber si Anders Hejlsberg intervino en la arquitectura de WPF y / o WinForms, y si existen disparidades en la visión creativa y la facilidad de uso incorporadas en cualquiera de las bases de código. Finalmente, para los programadores de Delphi nuevamente, hágame saber cuánto "IDE schock" me espera cuando uso WPF en lugar de WinForms, especialmente cuando se trata de soporte de depurador. Cualquier comentario del mercado laboral actualizado para 2011 también sería apreciado.

Robert Oschler
fuente
2
¿No tiene WPF una mala reputación por su bajo rendimiento?
David Heffernan
9
@David: De hecho, tiene esa reputación, pero como de costumbre, la realidad no es tan mala como el rap. La GUI de Visual Studio 2010 se reescribió en WPF, y en la mayoría de las máquinas no parece haber una disminución notable de la velocidad en comparación con VS 2008. @Robert: Dicho esto, mi recomendación estaría muy a favor de WinForms, especialmente para un converso de Delphi. Pero dudo un poco en publicar eso como respuesta, para que no sea votado en el olvido. Todos parecen estar decididos a hacerlo porque es tecnología "vieja", como si eso realmente significara algo.
Cody Gray
@Cody. Entendido. Recibo información excelente con las respuestas y comentarios, pero espero obtener más información directa sobre WPF y su soporte de depuración frente a WinForms y algo de información sobre el mercado laboral. Las respuestas a mis consultas planteadas en esas áreas temáticas todavía son insuficientes.
Robert Oschler
1
@CodyGray: Debes estar bromeando. VS2010 es cien veces más lento que VS2008, y también lo es WPF. Su impresión probablemente se deba al sesgo habitual del programador: solo mira las máquinas de gama alta más recientes, que la mayoría de los usuarios normales no tienen.
Timwi

Respuestas:

21

Si tiene experiencia en Delphi, se sentirá decepcionado con WinForms. Intentará hacer cosas que fueron fáciles en el VCL, solo para descubrir que son dolorosamente difíciles o incluso imposibles. WPF será mucho menos confinado.

Por ejemplo, aquí hay algunas de las limitaciones de WinForms con las que nos hemos encontrado:

  • WinForms no tiene nada que se compare con TAction, por lo que si está acostumbrado a codificar con acciones, comparte el mismo texto e ícono entre un elemento de menú y un botón de barra de herramientas y un menú contextual, centralizando su lógica de habilitación y actualizando el estado habilitado en segundo plano con OnUpdate ... odiarás WinForms, donde tienes que hacer todo eso de la manera más difícil y propensa a errores.
  • El MainMenu antiguo de WinForms (.NET 1.0 vintage) no admite imágenes junto a los elementos del menú, y el nuevo (introducido en .NET 2.0) MenuStrip está plagado de errores que Microsoft se niega a corregir (porque las correcciones de errores pueden romper la compatibilidad con versiones anteriores).
  • Muchos controles, por ejemplo, el TreeView, están lamentablemente infravalorados en comparación con sus contrapartes VCL (dolorosamente lento, sin sorteo del propietario, faltan muchas opciones de personalización, etc.)
  • No hay nada parecido a la vibrante comunidad de desarrolladores de control de terceros a la que estás acostumbrado en Delphi. Existen bibliotecas de control de calidad, pero usted paga por ellas; las ofertas gratuitas como VirtualTreeView simplemente no están disponibles para WinForms.

WPF es un poco más básico en algunos aspectos que WinForms, pero es inmensamente más extensible.

  • ¿Quieres algo como TAction? WPF tiene ICommand, que es tan rico como estás acostumbrado (pero asegúrate de leer el artículo MVVM de Josh Smith ; normalmente tienes que habilitar / deshabilitar tus comandos manualmente cuando el estado cambia, pero su versión activa automáticamente tu código de habilitación en segundo plano como estás acostumbrado con OnUpdate).
  • ¿Quieres imágenes en los menús? Eso está integrado (y no es tan defectuoso como en WinForms).
  • WinForms deja de lado el dibujo del propietario en algunos controles importantes, pero si está utilizando WPF en su lugar, no necesita el dibujo del propietario; si desea que sus nodos TreeView tengan texto negro seguido de un número azul entre paréntesis, simplemente póngalo en su DataTemplate y funciona, no se necesita un código feo de dibujo del propietario.
  • ¿Quieres controles de terceros? En muchos casos, no los necesita, porque puede extender lo que hay allí de manera WinForms y, sí, los desarrolladores de VCL solo pueden soñar.

WPF tiene una curva de aprendizaje muy empinada, pero si elige un buen libro (por ejemplo, " WPF 4 Unleashed "), lo ayudará a superar lo peor, y estará encantado de trabajar con un marco que no te detendrá como WinForms lo hará.

Joe White
fuente
1
Gracias por el comentario directo de Delphi. ¿Algún comentario en el mercado laboral y alguna información sobre el soporte del depurador de VS 2010 para WPF, especialmente problemas de rastreo / inspección? Revisaré el libro al que te vinculaste.
Robert Oschler
1
No sé sobre el mercado laboral. En cuanto al depurador, espere frustración si el constructor de su ventana arroja una excepción, porque el depurador será reacio a darle un seguimiento de la pila, pero todo lo que tiene que hacer es cavar en dos niveles de InnerException en el diálogo de detalles de excepción del depurador. Y si sus enlaces no funcionan, ejecute bajo el depurador y mire en la ventana Salida para ver los errores de enlace. Aparte de eso, no estoy seguro de qué preocupaciones tienes. WPF depura OK en mi experiencia, y MVVM le permite a la unidad probar más de su lógica de UI de lo que puede en WinForms.
Joe White
66
Curva de aprendizaje muy empinada. No tienes mucho programa en WPF; haces preguntas sobre cómo convencer a WPF para que haga lo que quieras.
Ian Boyd el
En realidad, algunos de los mayores obstáculos son aprender a trabajar con un marco que separa las responsabilidades adecuadamente, en lugar de simplemente tener todo derivado ciegamente de TKitchenSink.
Joe White
1
¿Puedo tener formularios Delphi, pero mantener el lenguaje C #? ¿Por favor?
Robert Harvey
13

Por lo general, estoy muy sorprendido con las personas que dicen que no tuvieron una buena experiencia con WPF. Soy un desarrollador que cambió de C ++ / MFC a C # / WinForms a C # / WPF. La transición de WinForms a WPF no fue fácil porque aprender XAML no es muy fácil, pero una vez que lo tienes, es una tecnología increíble. Yo, por mi parte, no puedo volver a WinForms. WPF es simplemente increíble.

La otra cosa que me molesta es cómo las personas normalmente asocian WPF con solo UI. De hecho, es 100 veces mejor que WinForms en mi opinión por la facilidad de diseño de la interfaz de usuario, pero hay muchas otras razones por las que te encantará usar WPF:

  1. IU, por supuesto.
  2. Fijaciones Simplemente magia. La característica más poderosa después de la interfaz de usuario. Las aplicaciones LOB se benefician más de esto.
  3. Comandos
  4. Separación de intereses. Los diseñadores trabajan en diseño, programadores.
  5. Propiedades adjuntas. Puede ampliar la funcionalidad de los controles de terceros sin código fuente (aunque este punto bien puede ser parte del primer punto).
  6. Fácil transición a Silverlight (tanto web como WP7)

Es posible que no esté de acuerdo conmigo sobre el último punto como una razón para aprender WPF, pero si me pregunta, es uno de los más importantes. Aprende WPF, puede pasar fácilmente a Silverlight. Silverlight está creciendo a lo grande, y también es una tecnología increíble.

Y la razón más importante es que es el futuro. Puede fusionarse con Silverlight, pero las habilidades seguirán siendo las mismas.

Por lo tanto, le aconsejaré encarecidamente que siga el camino de WPF.

Yogesh
fuente
1
No estoy diciendo que no estoy de acuerdo, pero todas esas razones están relacionadas con la interfaz de usuario (aunque usted dice que la otra cosa que me molesta es cómo la gente normalmente asocia WPF con solo interfaz de usuario )
Ed S.
1
+1 porque estoy de acuerdo con todos tus puntos. Debo elegir si quería aprender WPF o Winforms, y elijo WPF y nunca me he arrepentido. @Ed: No veo ninguno de esos como estrictamente relacionado con la interfaz de usuario, excepto el primero.
Rachel
1
@ Rachel: ¿En serio? El enlace se usa para actualizar la IU cuando cambia el valor de una propiedad. La separación de preocupaciones en el n. ° 4 obviamente solo se aplica al desarrollar una interfaz de usuario. # 5 se trata de controles de terceros. Sin interfaz de usuario, sin controles. El # 6 nuevamente se trata de traducir a una interfaz de usuario Silverlight. ¿Me estoy perdiendo de algo?
Ed S.
3
Más o menos me he ido al revés: WPF -> WinForms -> C ++ / MFC. Sí, soy un rebelde; Yo nado río arriba. Simplemente no veo nada convincente sobre lo que WPF aporta a la interfaz de usuario. Un montón de software horrible, de aspecto no nativo, no es mi idea de "progreso". Más allá de eso, no estoy seguro de cómo los patrones de diseño que tantos (incluida esta respuesta) asocian con WPF son de alguna manera exclusivos de WPF. Puede usar patrones de diseño en cualquier lenguaje o marco de GUI. ¿Es la diferencia simplemente que si no te obligan , la gente no lo hará? La facilidad de transición a Silverlight es la única razón convincente aquí.
Cody Gray
55
Mi primera tarea con una aplicación WPF: soltar una barra de herramientas, hacer que sea 14 dlus de altura. No se puede hacer . Segunda tarea: establecer la fuente del formulario para que coincida con la fuente y el tamaño de la fuente del usuario. no se puede hacer Tercer paso: añadir elementos a una vista de lista sin trabarse no se puede hacer lo dejo.
Ian Boyd el
5

Claramente, WPF es el camino a seguir pensando en el futuro. Dominarlo es difícil, pero la plataforma está muy bien diseñada y es flexible.

Algunas líneas de consejos:

  • Comience fácilmente: no intente implementar su primer proyecto utilizando solo MVVM o animaciones sofisticadas. Comience simple con ventanas, botones y listas.
  • Aproveche el enlace de datos.
  • Compre el libro WPF Unleashed de Adam Nathan.
Eduardo Molteni
fuente
+1. Respuesta práctica Trate de no implementar su primer proyecto usando solo MVVM o animaciones elegantes
Karthik Sreenivasan
4

Primero debo tener en cuenta que soy principalmente un desarrollador de asp.net, aunque he usado winforms mucho antes. El cambio a WPF no es tan grande como lo está haciendo (imo) después de una semana más o menos (más de 40 horas), la mayoría fue una segunda naturaleza nuevamente.

De todos modos, creo que Anders Hejlsberg es uno de los arquitectos detrás de WPF, al menos según los editores de este libro->

Como uno de los arquitectos detrás de WPF, Chris Anderson explica hábilmente no solo el 'cómo' sino también el 'por qué'. Este libro es un recurso excelente para cualquier persona que desee comprender los principios de diseño y las mejores prácticas de WPF. "–Anders Hejlsberg, técnico, Microsoft Corporation

http://www.amazon.com/Essential-Windows-Presentation-Foundation-WPF/dp/0321374479

Fantasmas
fuente
11
"Como uno de los arquitectos detrás de WPF, Chris Anderson explica hábilmente ..." sugiere que Chris Anderson es uno de los arquitectos detrás de WPF. Anders Hejlsberg es solo un "compañero técnico" en Microsoft Corporation, según el texto citado, que por lo tanto no prueba su participación en WPF.
Andreas Rejbrand
¡Ah, eso podría ser cierto, pero sí demuestra que lo respeta!
2
O al menos que respeta a Chris.
Bruce McGee
1
O al menos que el departamento de relaciones públicas consiguió que alguien con reputación hiciera un comentario.
rapid_now
@Andreas; Buena broma: solo "compañero técnico". No queriendo disminuir a Chris Anderson: es un gran tipo que mantiene un perfil un poco bajo ( msdn.microsoft.com/en-us/ff395959 está allí, pero simplegeek.com no se ha actualizado durante mucho tiempo). Anders Hejlsberg está involucrado en muchas cosas de .NET (los becarios técnicos tienen un amplio alcance), después de todo, él es un tipo de marco (VCL, WCF, etc.), vea simple-talk.com/content/article.aspx?article=673 y microsoft .com / presspass / exec / techfellow / Hejlsberg / default.mspx ) y solo hay pocos becarios técnicos ...
Jeroen Wiert Pluimers
2

Winforms es casi idéntico al desarrollo de Delphi. Y, por supuesto, hay una razón para eso. Así como el modelo de objetos Delphi / Object Pascal influyó mucho en C #, el sistema de formularios influyó en Winforms.

WPF parece ser la dirección en la que se dirigen las cosas; se dice que la (¡magnífica!) interfaz de usuario VS2010 está basada en WPF, a diferencia de las generaciones anteriores que se crearon en Winforms.

Si quieres quedarte en tu zona de confort, ve con winforms. Si quieres ponerte al día con lo último y lo mejor, sumérgete en WPF.

3Dave
fuente
3
WinForms es lo que Delphi extiende, en realidad es muy frustrante en comparación con Delphi. Se parece más a VB-3 que a Delphi, y el nivel de frutsration de IME es similar.
2

No soy un programador de Delphi, pero sí, he trabajado tanto en WinForm (en gran medida) como en WPF (menos que moderado). Estoy de acuerdo con usted hasta cierto punto en el nivel de frustración para alguien que estaría haciendo un cambio de WinForm a WPF ya que estoy en esa situación, pero solo hasta que me haya acostumbrado. Aprenda y vea cuán maravilloso y flexible con WPF se compara con WinForm. Tiene una fuerte curva de aprendizaje, al menos para alguien que viene de antecedentes de Delphi, y no Winform. Para ti, definitivamente vale la pena avanzar hacia WPF en lugar de WinForm, y vale la pena el tiempo.

Es posible que desee buscar en los enlaces a continuación para comenzar:

Kumar
fuente
1

Había realizado algunos trabajos de Windows Forms (principalmente en Pocket PC), además de otros entornos que no eran .NET que usaban los mismos principios. Cuando me mudé a WPF hace unos tres años, durante los primeros meses lo estaba jurando. Eventualmente, simplemente "hizo clic" y no he mirado hacia atrás, de hecho, me entristecería si mi próximo proyecto me obligara a volver a Windows Forms.

La última vez que se actualizó Windows Forms fue en 2005 (VS 2005.) Todavía está allí, pero Microsoft ya no la ha mejorado. WPF es el nuevo chico en el bloque para aplicaciones de escritorio, por lo que si vas a pasar a la plataforma .NET usando herramientas de MS, entonces diría que es la apuesta segura. Algunas personas utilizan Silverlight como una solución de escritorio, pero cuando lo vi como una posibilidad, descubrí que tenía demasiadas limitaciones (lo que puede tener sentido en un contexto web, pero no tanto en el escritorio).

En pocas palabras: hay una curva de aprendizaje empinada, y todavía la estoy aprendiendo. Pero valió la pena. Es muy divertido.

MetalMikester
fuente
1

Si va a escribir nuevas aplicaciones desde cero, usar WinForms sería un error. Básicamente está muerto desde una perspectiva de inversión. Microsoft lo mantendrá durante mucho tiempo, pero no obtendrá nuevas características, o nuevo soporte, etc. WPF es la dirección clara para las aplicaciones de escritorio para el futuro en la plataforma MS.

Desde una perspectiva profesional, también es mucho mejor saber WPF vs. WinForms. Por las mismas razones anteriores. Además, tendrás una buena ventaja para aprender Silverlight. Hay un montón de superposición entre esas dos plataformas.

Y finalmente, WPF es simplemente más divertido. Y más poderoso.

La curva de aprendizaje es más pronunciada, eso te lo doy. Pero es más gratificante al final.

RationalGeek
fuente
0

Una consideración adicional que debe mencionarse es que no hay un plan para el soporte de WPF en mono . Me doy cuenta de que no manifestó ningún interés en el soporte (mono) multiplataforma, pero puede haber una oportunidad para esto en su futuro (si elige Winforms). Presumiblemente, vendrá soporte para WPF en mono (o similar).

editar: Como el enlace que proporcioné señaló, y el comentario de Gulshan destacó, Moonlight es un esfuerzo de código abierto liderado por el equipo mono para proporcionar soporte multiplataforma de Silverlight .

Argalatyr
fuente
Pero Moonlight está en desarrollo activo.
Gulshan
-1

Me emocioné cuando escuché sobre WPF, la idea sonó genial y todo lo que he visto ha sido hermoso. Sin embargo, cuando llegué a usarlo en Visual Studio 2008 (ciertamente, una versión beta), me pareció frustrante y peculiar trabajar con el diseñador / IDE.

Publiqué una pequeña información en mi blog en ese momento:
http://blog.dantup.com/2007/08/visual-studio-2008-beta-2-first.html
http://blog.dantup.com/2007 /08/wpf-designer-cider-part-2.html

No lo he probado en 2010, aunque he hablado con algunas personas que sí lo han hecho, y parece que todavía es un poco complicado / molesto de manejar.

Creo que su aplicación, sin duda, se vería / se sentiría mejor en WPF, pero también creo que le llevará más tiempo construirla y se golpeará la cabeza mucho en el camino.

Danny Tuppeny
fuente
"Creo que su aplicación sin duda se vería / sentiría mejor en WPF". No necesariamente: WPF no te salvará de escribir una interfaz de usuario de mierda. Tengo algunos ejemplos aquí (uno de los cuales es mío, aunque esa fue solo una aplicación rápida y desechable para probar algunas cosas). Si usted (y los que llaman la atención, también conocido como $$) están dispuestos a gastar el tiempo y esfuerzo, puedes hacer cosas increíbles en WPF.
MetalMikester
Punto justo. Lo que quise decir es que WPF te permite crear una aplicación más hermosa, ya que estás menos limitado por los widgets de Windows. ¡Por supuesto, esto podría ser algo bueno y malo!
Danny Tuppeny
3
Definitivamente algo malo. WPF ha introducido una era de interfaces completamente no nativas. Difícil de entender y aún más difícil de ver. Lo que una persona piensa que es hermosa es la peor pesadilla de otra persona. Dejar "skinning" en los controles integrados del sistema operativo es una forma fantástica de hacer felices a todos. Por otra parte, me niego a usar las últimas versiones de Office porque no soporto la interfaz. Entonces, ya sabes, sal de mi césped y esas cosas.
Cody Gray
1
Yo diría que esto es un poco subjetivo. Probablemente no quisiera que mi Word Pocessor rompa todas estas reglas, pero algunas piezas de software pueden salirse con la suya. P.ej. una de las mejores muestras de WPF que recuerdo haber visto fue la de Yahoo; para mí, eso es una gran mejora en una aplicación basada en widgets de Windows: blogs.msdn.com/cfs-filesystemfile.ashx/__key/…
Danny Tuppeny