WPF vs. WinForms - a perspectiva de um programador Delphi?

Eu li a maioria dos tópicos principais sobre WPF vs. WinForms e me vejo preso na ambivalência infeliz em que você pode cair ao decidir entre a tecnologia anterior testada e verdadeira (Winforms) e seu sucessor (WPF).

Eu sou um programador veterano de Delphi há muitos anos que finalmente está saltando para o C #. Meus colegas programadores de Delphi por aí entenderão que estou empolgado em saber que Anders Hejlsberg, famoso por Delphi, foi o arquiteto por trás do C #. Tenho uma forte dependência dos componentes personalizados da Delphi VCL, especialmente aqueles envolvidos na criação de assistentes e componentes de várias etapas que atuam como um contêiner para componentes filhos.

Com esse pano de fundo, espero que aqueles que mudaram de Delphi para C # possam me ajudar com minha decisão WinForms vs. WPF para escrever meus aplicativos iniciais. Observe que estou muito impaciente quando a codificação e coisas como suporte completo ao depurador automático e completo podem fazer ou interromper um projeto para mim, incluindo a capacidade de encontrar informações prontamente disponíveis sobre os recursos e chamadas da API e, mais ainda, soluções alternativas para bugs .

Os tópicos e comentários do SO no início de 2009 me preocupam muito com o WPF quando se trata de possíveis frustrações que podem prejudicar minha codificação de desenvolvimento da interface do usuário do C #. Por outro lado, gastar uma quantidade excessiva de tempo aprendendo uma tecnologia de API que, mesmo que não seja abandonada, será substituída em breve (WinForms), é igualmente preocupante e acho o suporte da GPU no WPF tentador.

Daí minha ambivalência. Como ainda não aprendi nenhuma das técnicas, tenho uma rara oportunidade de começar de novo e não tenho que enfrentar a grande curva de "desaprendizagem" que vi as pessoas mencionarem em vários tópicos quando um programador do WinForms faz a mudança para o WPF. Por outro lado, se o uso do WPF for muito frustrante ou terá outras importantes consequências negativas para um desenvolvedor RAD impaciente como eu, continuarei usando o WinForms até que o WPF atinja o mesmo nível de suporte e facilidade de uso. Para dar um exemplo concreto da minha psicologia como programador, usei o VB e, posteriormente, o Delphi para evitar completamente a dor real de codificar com o MFC, uma biblioteca de interface do usuário do Windows que muitos desenvolvedores sofreram enquanto desenvolviam aplicativos antigos do Windows. Nunca me arrependi da minha sorte de evitar o MFC.

Também seria reconfortante saber se Anders Hejlsberg tinha uma mão na arquitetura do WPF e / ou WinForms, e se existem disparidades na visão criativa e na facilidade de uso incorporadas em qualquer base de código. Finalmente, para os programadores Delphi novamente, deixe-me saber quanto "IDE schock" eu uso ao usar o WPF em oposição ao WinForms, especialmente quando se trata de suporte a depurador. Quaisquer comentários do mercado de trabalho atualizados para 2011 também serão apreciados.

Se você tem experiência com Delphi, ficará desapontado com o WinForms. Você tentará fazer coisas fáceis na VCL, apenas para descobrir que são dolorosamente difíceis ou mesmo impossíveis. O WPF será muito menos restritivo.

Por exemplo, aqui estão apenas algumas das limitações do WinForms que encontramos:

• O WinForms não tem nada que se compare ao TAction; portanto, se você está acostumado a codificar com ações, compartilha o mesmo texto e ícone entre um item de menu e um botão da barra de ferramentas e um menu com o botão direito do mouse, centralizando sua lógica de ativação e atualizando o estado ativado em segundo plano com o OnUpdate ... você odiará o WinForms, onde terá que fazer tudo isso da maneira mais difícil e propensa a erros.
• O MainMenu antigo do WinForms (.NET 1.0 vintage) não oferece suporte a imagens ao lado dos itens de menu e o novo MenuStrip (introduzido no .NET 2.0) está repleto de bugs que a Microsoft se recusa a corrigir (porque as correções podem quebrar a compatibilidade com versões anteriores).
• Muitos controles, por exemplo, o TreeView, são lamentavelmente insuficientes em comparação com seus equivalentes VCL (dolorosamente lento, sem necessidade de proprietário, muitas opções de personalização faltando, etc.)
• Não há nada parecido com a vibrante comunidade de desenvolvedores de controle de terceiros com os quais você está acostumado no Delphi. Existem bibliotecas de controle de qualidade por aí, mas você paga por elas - ofertas gratuitas como o VirtualTreeView simplesmente não estão disponíveis para o WinForms.

O WPF é um pouco mais básico em alguns aspectos do que o WinForms, mas é imensamente mais extensível.

• Você quer algo como ação? O WPF possui o ICommand, que é tão rico quanto você está acostumado (mas não deixe de ler o artigo MVVM de Josh Smith - normalmente você precisa ativar / desativar seus comandos manualmente quando o estado mudar, mas a versão dele aciona automaticamente o código de ativação) em segundo plano, como você está acostumado com o OnUpdate).
• Você quer imagens nos menus? Isso é incorporado (e nem de longe é tão problemático quanto no WinForms).
• O WinForms deixa de lado o desenho do proprietário em alguns controles importantes, mas se você estiver usando o WPF, não precisará do desenho do proprietário - se quiser que os nós do TreeView tenham texto em preto seguido de um número azul entre parênteses, basta coloque-o no seu DataTemplate e funcione, não é necessário nenhum código feio para o proprietário.
• Você quer controles de terceiros? Em muitos casos, você não precisa deles, porque você pode estender o que há de maneiras do WinForms e, sim, os desenvolvedores de VCL podem apenas sonhar.

O WPF tem uma curva de aprendizado muito íngreme, mas se você escolher um bom livro (por exemplo, " WPF 4 Unleashed "), isso ajudará você a superar o pior - e ficará feliz em trabalhar com uma estrutura que não o impedirá como o WinForms.

Normalmente, fico muito surpreso com as pessoas dizendo que não tiveram uma boa experiência com o WPF. Eu sou um desenvolvedor que mudou de C ++ / MFC para C # / WinForms para C # / WPF. A transição do WinForms para o WPF não foi fácil, porque aprender XAML não é muito fácil, mas depois que você se apossar dele, é uma tecnologia incrível. Eu, por exemplo, não posso voltar ao WinForms. WPF é simplesmente incrível.

A outra coisa que me incomoda é como as pessoas normalmente associam o WPF apenas à interface do usuário. É realmente 100 vezes melhor que o WinForms, na minha opinião, para facilitar o design da interface do usuário, mas há muitos outros motivos pelos quais você adorará usar o WPF:

1. UI, é claro.
2. Ligações. Simples magia. O recurso mais poderoso após a interface do usuário. Os aplicativos LOB se beneficiam mais disso.
3. Comandos.
4. Separação de preocupações. Designers trabalham em design, programadores programadores.
5. Propriedades anexadas. Você pode estender a funcionalidade de controles de terceiros sem o código-fonte (embora esse ponto possa fazer parte do primeiro).
6. Transição fácil para o Silverlight (Web e WP7)

Você pode não concordar comigo sobre o último ponto como um motivo para aprender o WPF, mas se você me perguntar, é um dos maiores. Você aprende WPF, pode facilmente fazer a transição para o Silverlight. O Silverlight está crescendo muito e também é uma tecnologia incrível.

E a maior razão é que é o futuro. Pode ser mesclado com o Silverlight, mas as habilidades permanecerão as mesmas.

Então, eu aconselho você a seguir o caminho do WPF.

Claramente, o WPF é o caminho a seguir no futuro. Dominar é difícil, mas a plataforma é muito bem arquitetada e flexível.

Algumas linhas de conselho:

• Comece fácil: não tente implementar seu primeiro projeto usando apenas MVVM ou animações sofisticadas. Comece simples com janelas, botões e listas.
• Aproveite o DataBinding.
• Compre o livro WPF Unleashed de Adam Nathan.

Devo primeiro notar que sou principalmente um desenvolvedor asp.net, embora já tenha usado bastante o winforms. A mudança para o WPF não é tão grande quanto você faz (imo) depois de uma semana ou mais (mais de 40 horas), a maioria era uma segunda natureza novamente.

De qualquer forma, acredito que Anders Hejlsberg é um dos arquitetos por trás do WPF, pelo menos de acordo com os editores deste livro->

“ Como um dos arquitetos por trás do WPF, Chris Anderson explica habilmente não apenas o 'como', mas também o 'porquê'. Este livro é um excelente recurso para quem deseja entender os princípios de design e as melhores práticas do WPF. ”- Hejlsberg, técnico, Microsoft Corporation

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

O Winforms é quase idêntico ao desenvolvimento do Delphi. E, claro, há uma razão para isso. Assim como o modelo de objeto Delphi / Object Pascal influenciou fortemente o C #, o sistema de formulários influenciou o Winforms.

WPF parece ser a direção que as coisas estão seguindo; foi dito que a interface do usuário do VS2010 (maravilhosa!) é baseada em WPF, ao contrário das gerações anteriores criadas no Winforms.

Se você quiser ficar na sua zona de conforto, use formas de win. Se você quiser se atualizar com as últimas e melhores, mergulhe no WPF.

Eu não sou um programador Delphi, mas sim, eu trabalhei no WinForm (fortemente) e no WPF (menos que moderado). Eu concordo com você, até certo ponto, no nível de frustração de alguém que mudaria do WinForm para o WPF, pois eu mesmo estou nessa situação, mas apenas até me acostumar. Aprenda e veja como é maravilhoso e flexível o WPF se compara ao WinForm. Tem uma curva de aprendizado pesada, pelo menos para alguém que vem do fundo Delphi, e não do Winform. Para você, definitivamente vale a pena avançar para o WPF em vez do WinForm, e vale a pena.

Você pode querer olhar nos links abaixo para começar:

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

Eu havia feito alguns trabalhos do Windows Forms (principalmente em Pocket PCs), além de outros ambientes não-.NET que usavam os mesmos princípios. Quando me mudei para o WPF, cerca de três anos atrás, durante os primeiros meses eu estava xingando. Eventualmente, apenas "clicou" e eu não olhei para trás - na verdade, ficaria chateado se meu próximo projeto exigisse que eu voltasse para o Windows Forms.

A última vez que o Windows Forms foi atualizado foi em 2005 (VS 2005.) Ele ainda está lá, mas não está mais sendo aprimorado pela Microsoft. O WPF é o novo garoto-propaganda dos aplicativos de desktop; portanto, se você for para a plataforma .NET usando as ferramentas do MS, diria que é a aposta segura. Algumas pessoas consideram o Silverlight como uma solução de desktop, mas quando eu vi isso como uma possibilidade, descobri que ele tinha muitas limitações (o que pode fazer sentido em um contexto da Web, mas não tanto no desktop).

Conclusão: há uma curva de aprendizado acentuada e ainda estou aprendendo. Mas tudo valeu a pena. É muito divertido.

Se você deseja escrever novos aplicativos do zero, usar o WinForms seria um erro. É basicamente morto de uma perspectiva de investimento. A Microsoft manterá o controle por um longo tempo, mas você não obterá novos recursos, novos apoios etc. O WPF é a direção clara para aplicativos de desktop para o futuro na plataforma MS.

Do ponto de vista da carreira, é muito melhor conhecer WPF vs. WinForms. Pelas mesmas razões acima. Além disso, você terá uma boa vantagem sobre o aprendizado do Silverlight. Há muita sobreposição entre essas duas plataformas.

E, finalmente, o WPF é simplesmente mais divertido. E mais poderoso.

A curva de aprendizado é mais acentuada. Mas é mais gratificante no final.

Uma consideração adicional que deve ser mencionada é que não há plano para o suporte ao WPF em mono . Sei que você não manifestou interesse em suporte (mono) para várias plataformas, mas pode haver uma oportunidade para isso no seu futuro (se você optar pelo WinForms). Presumivelmente, o suporte ao WPF em mono (ou similar) será fornecido.

editar: Como o link que eu forneci apontou, e o comentário de Gulshan destacou, o Moonlight é um esforço de código aberto liderado pela equipe mono para fornecer suporte ao Silverlight em várias plataformas .

Fiquei empolgado quando soube do WPF, a ideia parecia ótima e tudo o que vi foi lindo. No entanto, quando cheguei a usá-lo no Visual Studio 2008 (reconhecidamente, um beta), achei frustrante e peculiar trabalhar com o designer / IDE.

Postei algumas informações no meu blog na época:
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

Eu não tentei em 2010, apesar de ter falado com algumas pessoas, e parece que ainda é um pouco complicado / chato de entender.

Eu acho que seu aplicativo sem dúvida ficaria melhor no WPF, mas também acho que você levará mais tempo para construir e você vai bater a cabeça muito ao longo do caminho.