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

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.

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á.

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.

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.

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

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.

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:

• http://drwpf.com/blog/
• http://www.wpftutorial.net/
• http://joshsmithonwpf.wordpress.com/

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.

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.

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 .

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.