Um tempo atrás eu indiquei quando usar ASP.Net Webforms ou MVC. Agora vamos a outra dupla igualmente polêmica: WF (Windows Forms) ou WPF (Windows Presentation Foundation).

Eu não gosto de recomendações sem contexto. Mas se fosse para dar uma recomendação sem contexto, seria essa:

Use WPF.

Mas a idéia não é essa.

Vamos entender primeiro a história de cada tecnologia.

Windows Forms: nasceu junto com o .Net, em 2002. Era a maneira de fato de criar aplicações desktop para o Windows, e ainda é a mais usada. A idéia, ao que tudo indica, era dar uma interface que fosse familiar ao desenvolvedor de VB 6, mas adaptada para o .Net. Já nasceu com vários controles úteis, mas os controles só bateram os que o VB 6 tinha na versão 2.0, lançada em 2005.

WPF: nasceu em 2007, com o .Net 3.0 (ou seja, sobre o CLR 2.0). O Visual Studio 2008 ainda não havia sido lançado, e um pacote de atualização para o Visual Studio 2005 foi lançado, o que permitia desenvolver WPF nesta IDE. O pacote era, para dizer o mínimo, incompleto. No VS 2008 ela apareceu com a versão 3.5, na prática sua segunda versão. Nesta versão o suporte da IDE já é muito melhor, mas somente com o Expression Blend é possível ter uma IDE gráfica completa para edição. Em 2009 a adoção do WPF começa a se intensificar.

Quando usar WPF então? Vejam aqui os cenários em que entendo que vale a pena usar WPF:

• Se você quer trabalhar com o framework que vai receber mais evoluções, WPF é o ideal. WPF é agora a maneira recomendada pela Microsoft para desenvolver aplicações desktop, e não Windows Forms. Não espere grandes evoluções no WF daqui por diante, apenas pequenas melhorias.
• Se você gostaria de uma separação clara entre o trabalho de design e de engenharia, o modelo declarativo de construção da interface gráfica com XAML permite isso.
• O suporte das ferramentas de design da família Expression é total, habilitando aplicações mais agradáveis e a criação de grandes efeitos, como transparências, animações, etc.
• O MVVM, padrão filho do presentation model, é a maneira mais apresentada sobre como fazer uma aplicação WPF. O padrão prima pela separação entre visão e controle da aplicação, e oferece uma maneira desacoplada e testável de desenvolver. Espere aplicações mais bem desenvolvidas com WPF do que com Windows Forms. Ainda que isso não signifique que todas vão usar MVVM, ou ser bem desenvolvidas, isso sem dúvida é um ponto a favor, já que em WF não há um padrão recomendado ou sequer demonstrado em 99% das demos por aí.
• WPF é praticamente um superset do Silverlight. O XAML é muito parecido. Se você avalia eventualmente migrar de uma aplicação desktop para Silverlight, via WPF será infinitamente mais fácil do que via WF.
• WPF permite fazer aplicações mais bonitas. O exemplo clássico é um degrade de cores. Tente fazer um degrade no WF e verá que não é trivial, já no WPF é só configurar uma propriedade. Ou tente fazer um botão redondo no WF, e verá como é complexo. No WPF isso é simples, feito com poucas linhas de XML. Transparência é outro exemplo. E logo de início você percebe que o grid padrão do WPF é muito mais bonito que o grid padrão do WF.
• Se é necessário integrar media no projeto, como vídeo, áudio, ou 3d, WPF é a melhor opção, já que isso já vem integrado.
• Caso a aplicação tenha necessidade de utilizar temas ou skins, WPF oferece um extenso suporte à esse tipo de customizações. As opções são praticamente ilimitadas.
• O suporte a databind do WPF é muito superior ao oferecido no WF.
• Quer colocar um botão dentro de um grid, com um vídeo dentro do botão? Trivial, essa composição está na base do WPF.

E quando iniciar um projeto com Windows Forms?

• O principal motivo é uma reunião de alguns fatores: time não conhece WPF, não há tempo para estudá-la, e não há interesse da empresa nesse investimento. Nesse cenário é melhor seguir com WF. Ainda assim, a grande pergunta é: porque a empresa não quer investir, será que ela já avaliou os benefícios do WPF? Geralmente não é o caso.
• A performance do WF é um pouco melhor do que a do WPF. O WPF exige mais do hardware. Essa é uma questão complexa, que a Microsoft está tendo que enfrentar, agora que está desenvolvendo o Visual Studio com WPF. Espere grandes melhorias nesse sentido no .Net Framework 4. Mas se o produto for esperado antes do lançamento do WPF 4, e performance for um problema, WF é melhor.
• O projeto é uma reconstrução de um projeto anterior, ou há uma suite de controles e/ou formulários já pronta que a empresa quer reaproveitar. Nesses cenários, pode ser que o ganho proporcionado pelo reaproveitamento de código já construído supere os ganhos do WPF.
• A quantidade de controles de terceiros construídos para WF ainda é maior do que os focados em WPF, você tem mais opções. Mas esse jogo está virando, rapidamente.
• Se você precisa de suporte total do designer do Visual Studio, e não vai comprar ou não tem acesso ao Expression Blend, WF é melhor. Esse suporte só vira no Visual Studio 2010, ou seja, de 3 a 6 meses de hoje.
• A empresa precisa montar uma equipe rapidamente para um projeto e não tem um orçamento muito generoso. Há mais profissionais no mercado que trabalham com WF do que profissionais que conhecem WPF. E como raridade determina salário, quem conhece WPF tende a ganhar mais. (Mas da perspectiva do profissional, você quer ganhar menos ou mais?)

Há alguns mitos com relação ao uso de WPF que eu gostaria de discutir também:

• Mito: Se a aplicação é simples e eu não vou ter um designer trabalhando no projeto, tanto faz usar WPF ou WF, e eu já conheço WF.
  Fato: WPF não é só sobre design gráfico. Toda a separação proporcionada entre visão com XAML e código, o suporte rico a databind, a evolução do framework, são motivos válidos para usar WPF até mesmo em aplicações simples, sem grandes apelos visuais.
• Mito: WPF é difícil de aprender.
  Fato: WPF é difícil de aprender. Não tem o que dizer, a curva de aprendizado é grande para quem nasceu com Windows Forms ou VB6. Mas isso não é verdade se o seu background não é esse, ou seja, é uma questão de paradigma. Em qualquer dos casos, se prepare para bastante estudo.
• Mito: desenvolvimento em WPF é mais lento que em WF.
  Fato: só é mais lento quando você não está familiarizado com WPF. Coloque um bom desenvolvedor WPF ao lado de um bom desenvolvedor WF, e peça o mesmo resultado, verá que não há diferença.
• WPF ainda é uma tecnologia muito nova.
  Fato: WPF está na segunda versão, com a terceira sendo lançada em alguns meses. Não é mais uma tecnologia recente, e já há muita gente utilizando. A versão 1 realmente teve pouca adoção, mas isso não é mais motivo para não adotar hoje em dia. Ainda assim, acredito que a versão realmente madura, ou seja, a usada como referência, será a próxima, principalmente pelo suporte do Visual Studio e pelas melhorias de performance.

É sempre bom lembrar que integrar é possível, tanto WPF no WF, quando o contrário. Você pode iniciar a migração de WF para WPF aos poucos.

A idéia de discutir isso surgiu no twitter. Perguntei por lá porque você iniciaria um projeto em Windows Forms e não em WPF. Algumas das respostas, para vocês terem uma visão além da minha:

Ozory Em quanto tempo vou dominar o WPF como domino o Windows Forms? O cliente não vai esperar…
CaioProiete O mais comum: Porque o projeto tem data certa (e irrevogável) para entrar em produção e a equipe não tem experiência com WPF
Dennes Nem toda empresa tem experiência para lidar com essa relação complexa de design
Dennes Até mesmo na web a relação dos profissionais design x código é complicada, em windows então nem se fala.
vquaiato Por que temos preguiça de aprender uma tecnologia “nova”…
Denis_Petri Se não existe necessidade do sistema ter animações é muito mais rapido desenvolver em windows forms do que wpf.
hugoestevam Talvez a questão de desempenho, já testei GRIDs de empresas de comp. diferentes e sempre o WinForms é mais rápido que o WPF.
Denis_Petri Fazer um bind no grid do wpf é um saco, coisa que no winforms é moleza, mas concordo com @vquiato, a preguiça é tb um motivo
fgrehm conheco gente que simplesmente tem medo de mudar 😛
allistonCarlos winforms ao invés de WPF? Só se eu fosse masoquista!
Denis_Petri Cada caso é um caso, analise do que será usado é fundamental para o projeto… pq usar uma bazuca para matar uma formiga?
diogodamiani Porque, por mais que os desenv. queiram, tem empresas que não aceitam largar o passado e aderir às tecnologias do futuro.
rodrigokono 1-Performance (conhecer o ambiente do cliente) 2-Designer- (Terá alguém para fazer a parte cool?!) 3- Conhecimento de WPF.
andrecarlucci Webforms não faz sentido mais. Da mesma forma, se você fosse iniciar uma webapplication, deveria usar silverlight 🙂
facunte O principal motivo é tempo x capacitação da equipe. WPF não é tão simples qto parece. Mas estão avançando.
antoniodourado talvez para softwares que necessitem rodar em máquinas de menores potencias?! O WPF é relativamente mais pesado ou nd a ver?
edumenoncello somos dois, digo o mesmo p/ web forms, por mim, só MVC e Silverlight
Ozory Se tornar a vida do Dev + fácil, for robusto e rápido tá valendo.
fgrehm ah, e tem gente que tb tem medo do asp.net MVC 😛
fgrehm na verdade nao sei bem se eh medo, ta mais pra acomodação…
eliezerbp A configuração das máquinas onde a aplicação irá rodar (desempenho, acima de tudo). Eu também sou um péssimo designer!
pauloquicoli Sim, WPF na cabeça, mas, pra não usá-lo, só se for por motivo de hardware…
gumalheiros Se a aplicação for clean (Sem firula de Design), funcional como ERPs e sem restrição de máquina, já compensa WPF.

O que você acha? Continue a discussão nos comentários abaixo.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.