27 07 2016

Imagine que você, programador .NET, está começando um novo projeto desktop e surge a seguinte dúvida: qual plataforma de desenvolvimento eu devo utilizar? Windows Forms ou WPF?

Não se assuste. Apesar dessas duas plataformas já estarem bem disseminadas no mercado (afinal de contas, a primeira versão do Windows Forms saiu em 2002 e a primeira versão do WPF saiu em 2006), essa dúvida é muito mais comum do que você pode imaginar.

Algumas pessoas já escreveram sobre esse assunto no passado como, por exemplo, o Giovanni Bassi neste excelente artigo: WPF ou Windows Forms. Porém, mesmo assim, eu quero dar a minha perspectiva nesse assunto polêmico, baseado na minha experiência trabalhando com ambas as plataformas desde 2005.

Antes de discutirmos qual tecnologia é melhor em cada cenário, vamos dar uma olhada nas principais características de cada uma delas.

Características do Windows Forms

É mais velho: a primeira versão do Windows Forms foi lançada junto com o .NET Framework, em 2002. Podemos dizer que o Windows Forms já está “pronto” e estável há muito tempo, uma vez que não tivemos novas funcionalidades para essa plataforma desde aproximadamente o lançamento do .NET Framework 3.0.

A curva de aprendizado é tranquila: mesmo para programadores iniciantes, a curva de aprendizado do Windows Forms é extremamente tranquila. Por ser muito “visual“, a facilidade de arrastar os controles para dentro da tela e implementar funcionalidades por trás deles é muito grande.

Baixa barreira para alta produtividade: como a curva de aprendizado é muito tranquila, com pouco tempo você atinge uma produtividade alta no desenvolvimento dos seus projetos.

Suporte à herança visual: a herança visual no Windows Forms funciona até que bem. Se você tem vários formulários muito parecidos no seu projeto, é muito fácil criar um formulário “base” que servirá de “pai” para todos os outros formulários.

Bastante documentação, artigos e conteúdo técnico: por ser mais velho e mais disseminado, é muito mais fácil encontrar documentação e artigos técnicos sobre o Windows Forms. Se você está querendo fazer alguma coisa um pouco diferente do padrão no Windows Forms, muito provavelmente alguém já fez no passado e acabou documentando em algum lugar. Se você souber procurar, você vai encontrar.

Vasta biblioteca de controles de terceiros: existe uma quantidade absurda de componentes de terceiros para o Windows Forms. As principais opções são DevExpress, Telerik, Infragistics e ComponentOne. Apesar do preço ser um pouco salgado, a gama de componentes disponibilizada por essas bibliotecas vale cada centavo que você paga.

Apresenta problemas quando mudamos o DPI: uma das dificuldades quando programamos com o Windows Forms é o problema com resoluções/DPIs diferentes. Com a evolução das placas gráficas e monitores, isso está se tornando um problema muito comum. Existem algumas maneiras de resolver esse problema (eu até já escrevi um artigo sobre isso), mas, não é tão fácil como no WPF.

Dificulta a utilização de uma arquitetura mais robusta: como mencionei anteriormente, o Windows Forms é muito “visual” e baseado em eventos. Apesar de isso trazer uma facilidade no desenvolvimento, por outro lado, acaba trazendo uma dificuldade se quisermos utilizar uma arquitetura mais robusta, onde separamos todo o código de negócio da camada de apresentação. É possível utilizar arquiteturas como o MVVM no Windows Forms (inclusive, nós utilizamos em um projeto bem grande na empresa onde eu trabalho atualmente), mas, não é tão simples como no WPF.

Está em “modo manutenção”: a Microsoft não tem trazido novas funcionalidades para o Windows Forms desde o .NET Framework 3.0. Ele está em “modo manutenção“, o que quer dizer que somente bugs serão corrigidos. No .NET Framework 4.5 a Microsoft corrigiu alguns problemas de DPI dos controles nativos, mas, nada de funcionalidades novas. Quando novas features são adicionadas ao sistema operacional, o Windows Forms muito provavelmente não trará suporte a elas e a única opção é recorrer a gambiarras se quisermos utilizá-las.

A performance é melhor: algo que eu esqueci completamente quando escrevi este artigo é a questão da performance. Fui lembrado no Facebook pelo Rodrigo Vedovato que o Windows Forms ganha de longe do WPF quando o assunto é performance:

O Márcio Fábio Althmann também me lembrou desse detalhe da performance do WPF nos comentários aqui deste artigo (a propósito, se você ainda não conhece, eu recomendo que você dê uma olhada no blog dele):

Características do WPF

É mais novo, mas, mesmo assim, já é “velho”: a primeira versão do WPF saiu junto com o .NET Framework 3.0, em 2006. Apesar de ser mais novo que o Windows Forms, se levarmos em conta que estamos em 2016, ele já tem 10 anos!

Curva de aprendizado maior (se utilizado do jeito “certo”): a dificuldade no aprendizado do WPF se você quiser utilizá-lo corretamente (por exemplo, com uma arquitetura robusta como o MVVM) é bem maior. Para utilizar o WPF na sua capacidade total, você precisa aprender conceitos de programação que não são tão triviais assim.

Também está, de certa forma, em “modo manutenção”: apesar de ser mais novo, costuma-se dizer que o WPF também está “pronto“. Ou seja, muito dificilmente a Microsoft trará novas funcionalidades ou novos componentes nas próximas versões do .NET Framework.

Menos conteúdo disponível na internet: não é tão fácil encontrar conteúdo sobre WPF na internet, principalmente em português. O conteúdo disponibilizado em inglês até que é compatível com os materiais sobre Windows Forms, mas, em português ele fica devendo.

Controles de terceiros têm qualidade inferior: se você comparar a quantidade de features de componentes de terceiros entre WPF e Windows Forms, você verá que a qualidade dos componentes da mesma empresa é inferior no WPF. Por exemplo, se você comparar qualquer controle da DevExpress entre o Windows Forms e WPF, verá que os componentes do WPF ainda não conseguiram chegar 100% nas funcionalidades existentes para o Windows Forms.

XAML e sistema de binding extraordinário: apesar de parecer um tanto quanto complexo de início, o XAML é uma linguagem muito poderosa. Ela também pode ser utilizada no desenvolvimento de aplicativos móveis com a Xamarin, então, se você aprender o XAML do WPF, será mais fácil trabalhar com o XAML no desenvolvimento Xamarin. Sem falar no sistema de binding do WPF que é, de longe, a melhor funcionalidade dessa plataforma.

Capacidades gráficas bem melhores: o WPF não trabalha com a unidade de pixels (como o Windows Forms), mas sim, algo chamado “device independent units“. Essa diferença faz com que os aplicativos WPF consigam “escalar” sem problemas em diferentes resoluções e DPIs. Além disso, o WPF traz nativamente o suporte a transformações geométricas, efeitos 3D, manipulação de arquivos de mídia, entre outros.

Facilita a criação de um código melhor arquitetado: a separação brusca entre o código de design (XAML) e o código de negócio (C# ou VB.NET), além do sistema de binding mencionado anteriormente, facilita a criação de um código bem arquitetado. A utilização de arquiteturas como o MVVM cai como uma luva no desenvolvimento de aplicações WPF. Essa separação de responsabilidades possibilita que uma pessoa do time trabalhe somente no design das janelas enquanto outra pessoa trabalhe na lógica de negócios.

Quando utilizar Windows Forms?

Agora que já vimos as principais características do Windows Forms e do WPF, vamos ver a minha opinião sobre quando utilizar uma plataforma e quando utilizar a outra plataforma. Porém, antes de começar, vamos a um pequeno “disclaimer“:

As informações que apresentarei a partir desse ponto são baseadas na minha opinião trabalhando com desenvolvimento de aplicações em ambas as plataformas desde 2005. Ou seja, isso não quer dizer que elas são 100% corretas. Como toda opinião, cada um pode ter a sua e podemos, sem problema algum, discordar em alguns pontos. Pegue essas informações e utilize-as da melhor forma, sempre adaptando para o cenário dos seus aplicativos.

Aplicações de complexidade básica/intermediária até intermediária/avançada que devem rodar somente em Windows: se a sua aplicação não tem uma complexidade extremamente alta (pode até ser um aplicativo de negócios bem grande, mas, nada muito extremo como um ERP completo) e se você tem certeza que o aplicativo deverá rodar somente no Windows, vá de Windows Forms. Desenvolver com WPF nesse caso resultaria em uma aplicação que tem a mesma “cara“, só que com um código potencialmente mais complexo.

Aplicativos utilitários: pequenos aplicativos utilitários são mais facilmente desenvolvidos com Windows Forms.

Equipe com vasta experiência em Windows Forms e pouca/nenhuma experiência em WPF: se a sua equipe já tem uma vasta experiência com Windows Forms e pouca ou nenhuma experiência com WPF, não perca tempo durante o projeto para que a equipe aprenda WPF. Na minha opinião, o decorrer de um projeto não é hora de ficar aprendendo tecnologia do zero. Se você tem a intenção de utilizar WPF em um projeto no futuro, treine a sua equipe com antecedência, porque os conceitos não são aprendidos da noite para o dia.

Quando performance é importante: como mencionado anteriormente, a performance do WPF melhorou muito desde a primeira versão, mas, ainda está longe de ser o ideal. Dessa forma, se performance for um fator crítico para a sua aplicação, vá de Windows Forms.

Quando utilizar WPF?

Aplicações que tenham a chance de ter que rodar em várias plataformas: se você está desenvolvendo um aplicativo que deverá rodar em múltiplas plataformas, vá de WPF (mas utilize ele do “jeito certo“!). Isso te forçará a separar corretamente os códigos de negócio e design, facilitando o compartilhamento de código entre as diferentes plataformas. Além disso, se você pretende desenvolver aplicativos móveis com as ferramentas da Xamarin, muito provavelmente você conseguirá compartilhar uma boa parte das ViewModels entre as plataformas (sem falar do conhecimento de XAML que será útil se você escolher trabalhar com ele nas ferramentas da Xamarin).

Aplicações gigantescas ou de complexidade extrema: se a sua aplicação é gigantesca ou tem uma complexidade extremamente grande, a utilização correta do WPF fará com que você separe bem o código e tenha um projeto mais estruturado. A manutenção desses projetos ficará menos complexa caso você utilize o WPF com a arquitetura MVVM.

Aplicações com interfaces ricas: a sua aplicação precisa ter interfaces ricas, com transformações geométricas, 3D ou manipulação de mídia? Então não tem nem o que pensar. O WPF traz essas possibilidades nativamente, além de conseguir utilizar todo o poder da sua placa gráfica (coisa que não acontece com o Windows Forms).

Atenção! Evite isso:

Utilizar o Windows Forms ou WPF sem bibliotecas de terceiros: tanto os controles nativos do Windows Forms como do WPF são muito básicos e não são bons o suficiente para desenvolver um aplicativo comercial de qualidade. É importante investir um pouco de grana na compra de uma suíte de componentes. Dessa forma você acabará economizando tempo, uma vez que você não terá que ficar “reinventando a roda” toda vez que precisar de uma funcionalidade inexistente nos controles nativos.

Edit: em Outubro de 2017 o leitor Fausto Luís comentou que existem componentes muito bons que são gratuitos. Ele comentou especificamente sobre os controles da SyncFusion, que são gratuitos para desenvolvedores individuais e pequenas empresas. Ele tem toda a razão. Inclusive eu mencionei os controles da SyncFusion neste outro artigo que eu escrevi sobre suítes de componentes para .NET. Obrigado pelo toque, Fausto!

Escolher o WPF “só por escolher”: não escolha o WPF só porque ele é mais novo ou mais “elegante“. Os conceitos por traz do WPF são bem mais complexos que o Windows Forms e, como mencionei anteriormente, a curva de aprendizado é maior. Analise com cuidado o seu projeto para ver se o WPF realmente é a melhor escolha ou se você só está escolhendo ele porque “ouviu falar” que ele é melhor.

Programar aplicações WPF como você está acostumado a programar Windows Forms: se você escolher o WPF para a sua aplicação, não trabalhe com ele como se você estivesse programando Windows Forms! Não comece a arrastar controles e utilizar os seus eventos como você está potencialmente acostumado com o Windows Forms. Utilize uma arquitetura robusta (como o MVVM), tire proveito dos bindings, comandos, templates e tudo mais que o WPF traz de bom para você. Se você trabalhar com o WPF da mesma forma que está acostumado com o Windows Forms, o seu projeto ficará parecendo um Frankenstein e, o pior de tudo, a aparência da aplicação ficará igualzinha a uma aplicação Windows Forms. Ou seja, você terá uma aplicação idêntica com um código mais complexo. Não é uma boa ideia.

Programar aplicações Windows Forms sem separar o código de negócios da camada de apresentação: infelizmente, esse é um erro que ainda acontece muito frequentemente. O programador não separa a lógica de negócios e implementa tudo por trás do código do formulário. Se você ainda comete esse erro, pare agora mesmo! Sério. Esse é o pior erro que você pode cometer. Se você continuar persistindo nesse erro, quando a sua aplicação começar a ficar muito grande, ninguém vai conseguir dar manutenção nela (nem mesmo você)!

Ignorar o WPF ou falar mal dele sem conhecer: muita gente que já tem bastante experiência com Windows Forms e começa a estudar WPF acaba desistindo no meio (por causa da complexidade) e passa a falar mal do WPF. Isso é um tremendo erro. Para conseguir identificar qual é a melhor plataforma para cada tipo de aplicativo, você precisa conhecer muito bem as duas plataformas. Dessa forma, não ignore o WPF. Aprenda, treine, ponha em prática em um aplicativo de teste. Só assim você conseguirá tirar proveito de ambas as plataformas, independentemente de qual você escolher para cada projeto.

Concluindo

Tanto o Windows Forms quanto o WPF são plataformas de desenvolvimento de aplicações desktop que já estão “prontas“, ou seja, ambas estão estáveis e completas. Existe uma grande sobreposição de funcionalidades que estão presentes nas duas plataformas. Por isso, é importante conhecer ambas as plataformas para conseguir decidir qual delas utilizar em cada tipo de projeto.

Neste artigo você conheceu as principais características das duas plataformas, bem como a minha opinião sobre quando utilizar o Windows Forms e quando utilizar o WPF. E você? Concorda comigo ou tem uma opinião diferente? Deixe as suas observações na caixa de comentários abaixo.

Por fim, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado e ficará sabendo também em primeira mão sobre o artigo da próxima semana, além de receber dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário logo abaixo.

Até a próxima!

André Lima

Image by Pixabay used under Creative Commons
https://pixabay.com/en/chess-chessboard-game-strategy-424549/
https://pixabay.com/en/businessmen-silhouettes-meeting-1039905/
https://pixabay.com/en/board-school-mathematics-slate-1044088/
https://pixabay.com/en/japan-structure-monument-1419499/

Utilizando o Crystal Reports com MVVM no WPF Atualizando um relatório do Report Viewer de tempos em tempos