Desenvolvimento

29 nov, 2018

Windows Forms, WPF: ainda vale a pena?

100 visualizações
Publicidade

E ai, pessoal! Tudo certo?

Hoje vamos abordar um assunto um pouco polêmico.

Ainda vale a pena utilizar Windows Forms ou WPF para desenvolvimento de aplicações?

A Web já atende tudo que precisamos e podemos fazer apenas aplicações Web? Ou ainda existe espaço para aplicações Desktop?

Neste artigo, vamos ver alguns pontos positivos destas duas tecnologias e quando e onde podemos utilizá-las.

Aplicações Web

Antes de começar a analisar os dois elementos mencionados, faremos uma reflexão olhando para como o mundo do desenvolvimento de software está caminhando hoje.

Antigamente (poucos anos atrás), para acessar o banco, conversar com os amigos, seja através de texto ou áudio/vídeo, tínhamos que fazer o download de uma aplicação e instalar no computador. Mesmo smartphones tinham aplicações para download e instalação.

Em 2014, como mostra a Pesquisa Nacional Por Amostra de Domicílios (Pnad), divulgada pelo Instituto Brasileiro de Geografia e Estatística (IBGE), a quantidade de smartphones ultrapassou a de computadores para acesso à internet. Presentes em 76,6% das casas, os computadores caíram para a segunda colocação.

Estas informações, assim como o gráfico abaixo, foram obtidas em:

Gráfico com fonte de dados fornecida pelo IBGE, em 2014.

Depois disso, tivemos um “boom” na produção de aplicações móveis. Desde o desenvolvimento de aplicações diretamente nas plataformas, utilizando o SDK do Android ou o XCode em dispositivos Apple e a evolução no desenvolvimento com ferramentas que foram surgindo como PhoneGap, Cordova, Ionic, possibilitando o uso de HTML, CSS e JS para desenvolvimento de aplicações móveis, mas de forma não nativa, já que geravam uma aplicação com um browser embutido que carregada as páginas geradas e, com o tempo, aplicações nativas através de ferramentas como Xamarin, React Native e outras.

Um grande exemplo hoje de que a Web se tornou um padrão para novas aplicações, é o uso de notebooks menores e menos potentes, ou mesmo que não geram instalação ou execução de aplicações customizadas, como o Chromebook, que basicamente executa aplicações como outras comuns, mas rodando dentro do browser.

Agora, para aplicações em dispositivos móveis, mas não exclusivamente, temos as famosas Progressive Web Applications, que nada mais são do que aplicações Web com acesso a recursos locais do dispositivo, como câmera, microfone, status de rede, bateria, acelerômetro, GPS, e hoje já temos versões em teste do Chrome provendo acesso ao Bluetooth.

Essas aplicações se comportam como aplicações nativas, sem a necessidade de instalá-las, mas provendo uma funcionalidade essencial: poder realizar o download delas, e caso tenham sido arquitetadas para tal, executar as mesmas em modo offline.

Isso é praticamente uma tendência para o futuro, onde além da Google, que já oferece um suporte completo em dispositivos Android, temos a Microsoft investindo forte e a Apple dando seus primeiros passos com suporte a PWAs no Safari e iOS.

Passamos a maior parte do nosso tempo em redes sociais – todas aplicações Web. Se precisamos de uma informação, recorremos ao Google, Bing, e outros buscadores, sempre na Web.

Mas voltando ao foco do artigo, aplicações desktop, em nosso caso abordando mais especificamente Windows Forms e WPF, ainda se encaixam? Tudo depende!

A resposta para a pergunta acima é: depende.

Antes de discutirmos o que vale ou não utilizar Windows Forms, WPF ou qualquer outra tecnologia para desenvolvimento Desktop, precisamos antes saber quais são as vantagens e desvantagens de se utilizar estas tecnologias. Vou adotar aqui os pontos sobre Windows Forms e WPF como foco, ok?

Windows Forms

Lembro de quando trabalhei pela primeira vez com desenvolvimento em Windows Forms utilizando C# no .NET 1.0 – fase de “gerar telas” de forma rápida com o arrastar e soltar.

Existem diversos fatores positivos nele, mas também seus desafios e problemas. Vamos ver quais são:

Pontos positivos

  • Fácil de aprender: mesmo para quem está começando a programar, a curva de aprendizado do Windows Forms é tranquila. Poder arrastar os controles para o form e implementar funcionalidades é muito simples e fácil;
  • Tempo x Alta produtividade: como sua curva de aprendizado é simples, em pouco tempo sua produtividade de desenvolvimento aumenta. É possível fazer grandes projetos em pouco tempo – lógico que tomando o devido cuidado para que velocidade não sobreponha arquitetura e qualidade de código;
  • Documentação, componentes e ajuda: Windows Forms não é algo novo. Temos documentação completa e madura sobre o assunto, além de uma quantidade de material gigantesca na comunidade. Facilmente você encontra dúvidas, tutoriais e pessoas que já tenham feito o que você precisa com uma simples pesquisa. O mesmo vale para componentes – temos vários, para todos os gostos. Alguns são pagos, e bem pagos, por sinal, mas dependendo da sua necessidade, pode valer o preço;
  • Desempenho: normalmente, aplicações Windows Forms são extremamente performáticas, mas isso depende muito. Já vi aplicações WPF mais performáticas que uma equivalente em Windows Forms, assim como o contrário. Tudo depende da quantidade de elementos em tela, Bindings (no caso do WPF), quantidade de telas do sistema, uso de processamento assíncrono, forma de programar, entre outros diversos fatores;

Pontos negativos

  • Resolução: com a evolução dos monitores (ainda lembro de quando tinha um monitor de tubo, 17″, com resolução acima de 1024×768 e era sensacional), diversas resoluções têm aparecido no mercado. Windows Forms ainda gera uma certa dor de cabeça para desenvolver aplicações “responsivas”, enquanto o WPF provê componentes de layout que facilitam muito o trabalho, comparado ao Windows Forms;
  • Eventos por todos os lados: ao desenvolver em Windows Forms, principalmente quando ainda não temos uma maturidade, senioridade sobre o assunto, pode gerar uma grande bagunça, principalmente em projetos com muitas funcionalidades. Como seu modelo se baseia em eventos, fica complicado implementar uma arquitetura bem organizada. Uma boa prática é utilizar serviços, classes de negócio ou como preferir definir e chamar métodos destas dentro dos eventos, deixando-os o mais limpo possível. Algo semelhante ao que fazemos em Controllers, que devem possuir a lógica de rotas e outros assuntos relacionados a http, mas neste caso um evento seria responsável apenas por coletar as informações de componentes da tela, informar ao método chamado e renderizar nos componentes de tela as informações de resposta;
  • Ainda tem atualizações? Onde?: Windows Forms não recebem atualizações em sua estrutura desde o .NET 3.0/3.5, sendo que já tenho projetos rodando em .NET 4.7.1). Temos uma previsão de algo com o .NET Core 3.0, mas ainda são discussões de Roadmap;

WPF – Windows Presentation Foundation

O Windows Presentation Foundation (ou WPF) é um subsistema gráfico crido no .NET Framework 3.0, inicialmente chamado de WinFX, que usa uma linguagem de marcação, conhecida como XAML para desenvolvimento de interfaces ricas e com layout responsivo, comparado ao Windows Forms.

O Silverlight foi um subsistema WPF baseado na web, que permite aplicações no estilo Flash e aplicações móveis com o mesmo modelo de programação .NET, mas que foi descontinuado com a evolução de aplicações web utilizando frameworks JS modernos, assim como o próprio Flash.

Hoje, além do WPF, o Xamarin Forms utiliza a marcação XAML para desenvolvimento de interfaces para aplicações móveis que se adaptam aos controles nativos das plataformas Android ou iOS ao gerar a publicação de uma aplicação móvel.

Pontos positivos

  • Diversas aplicações: assim como o Windows Forms, não tem recebido novas atualizações de grande impacto, mas ainda tem uma utilização maior e maior probabilidade de receber novas atualizações da Microsoft, inclusive acredito nisso com a evolução do .NET Core a partir da versão 3.0. Um exemplo disso é o Xamarin Forms, que utiliza a marcação XAML para construção de interfaces móveis.
  • Resolução: ao contrário do Windows Forms, o WPF não trabalha com pixels e posicionamento fixo por padrão, apesar de ser possível fixar o posicionamento de elementos. Sua forma de ajustar componentes na tela e contêineres de layout facilitam e muito a adaptação com diferentes resoluções;
  • Arquitetura: no começo parece difícil de entender, mas depois que entender a arquitetura Mode-View-ViewModel (MVVM) e como aplicar ela no WPF com Data Binding, fica muito simples desenvolver aplicações com boa performance, poucos eventos de elementos da tela e facilidade de manutenção. Graças a separação de responsabilidades, vários membros da equipe podem trabalhar na interface e no código ao mesmo tempo no projeto;
  • Não existem limitações para interface: como a interface do WPF é feita com marcação XAML, sua interface pode ser feita de N formas diferentes, com infinitas possibilidades. É praticamente possível fazer qualquer coisa, além de reaproveitar estilos e fontes em diversas telas, algo que, para quem já trabalhou com CSS em aplicações Web, acaba sendo de fácil aprendizado. Podemos fazer facilmente animações (alguém lembrando de fade e marquee? Sim, entreguei a idade agora, rs).

Pontos negativos

  • Documentação: temos uma quantidade relativamente grande e de boa qualidade para WPF, mas perto do Windows Forms, pouco, se compararmos, principalmente em português. Componentes, então, temos poucos focados em WPF. Isso tem mudado nos últimos anos, desde a criação do Xamarin Forms, além de ser fácil criar bibliotecas próprias de componentes com XAML.
  • Curva de Aprendizado: É difícil? Não. Mas, para utilizar o WPF corretamente, gerando interfaces performáticas, é necessário aprender alguns conceitos mais avançados de programação. Arquitetura MVVM, entre outras funcionalidades não tão básicas. Caso contrário, teremos interfaces com performance simplesmente inaceitável para os usuários, não justificando a maquiagem (afinal, para eles, o que mais muda, se não soubermos utilizar o WPF adequadamente, é aparência, apenas).

Então quando usar e o que usar?

Aplicações Web, na maioria dos casos, atendem perfeitamente os requisitos de negócio de uma empresa, mas temos alguns casos em que a Web não atende totalmente, gerando uma dor de cabeça e custos extras para poder adaptar.

São N casos, mas vou citar alguns exemplos que devem deixar bem claro a maneira de pensar ao avaliar o que usar e quando usar.

Aplicação de atendimento para Call centers

Sempre acabo citando alguma coisa sobre call centers, pois em boa parte da minha carreira, trabalhei neste segmento.

Algumas aplicações web simplesmente funcionaram maravilhosamente bem por muito tempo em diversas operações e clientes, até que tivemos uma maior integração com discadores e centrais de telefonia.

Uma das situações em que decidimos utilizar Windows Forms ou WPF para a aplicação dos atendentes foi quando tivemos integração com a central de telefonia, recebendo eventos dos mais diversos tipos, como quando uma nova chamada era recebida no ramal do atendente, quando este colocava ou tirava o cliente da opção “mudo”, quando um cliente desligava a ligação.

Todos estes eventos eram tratados de forma própria na aplicação, gerando comportamentos diferentes e até mesmo métricas de monitoração.

Em um SAC, o atendente não podia simplesmente desligar o cliente, não havia esta opção na aplicação (por configuração) e caso o mesmo apertasse o botão desligar diretamente no ramal ou puxasse o cabo, um evento era enviado para a aplicação sinalizando isso.

Esse tipo de integração normalmente era feito através de DLLs de provedores das centrais ou mesmo comunicação via sockets (sim, TCP/IP com mensagens texto) e muitos dos eventos às vezes chegavam quase ao mesmo tempo, com diferença de milissegundos. Tratar e refletir o comportamento de todos em uma interface Web, de forma rápida, era praticamente impossível.

Aplicações Offline

Hoje temos diversas técnicas para aplicações Web poderem operar de forma Offline, como o uso de Progressive Web Applications, cache, etc. Mas até pouco tempo atrás, nossa única opção era desenvolver aplicações desktop que fossem capazes de tratar falhas de acesso a um banco de dados ou web-service e armazenar localmente estes dados, para que quando a comunicação fosse re-estabelecida, pudessem sincronizar e lidar com os conflitos, possuindo inclusive, nelas, a lógica para isto.

Processamento “distribuído”

Muitas empresas ainda optam pelo modelo On-Premisses para seus servidores, e escalar aplicações web com grande quantidade de processamento (quando somamos uma grande quantidade de clientes) acaba sendo difícil. Com aplicações Windows Forms, podemos fazer com que parte desse processamento, desta lógica de negócios, seja realizada diretamente nos clientes, evitando até mesmo um tráfego maior na rede.

Aplicações embebedas

Podemos ter aplicações que, além de dependerem muitas vezes de uma conexão pobre, precisando trafegar apenas o necessário, são distribuídas junto com o hardware, onde precisamos gerar e garantir atualizações de forma simples e rápida, sem nos preocuparmos com problemas de cache de arquivos de um browser, por exemplo.

Um caixa eletrônico, por exemplo, possui uma aplicação local em execução que trafega pela rede, inclusive de forma criptografada apenas o necessário, muitas vezes via protocolos mais antigos como RMI (Java) e outros.

Segurança

Muitas aplicações mais modernas, dependentes de frameworks JS, acabam expondo um pouco de lógica no cliente, que pode ser facilmente visualizada no browser. Lógico que nunca devemos expor dados ou lógica de negócio sensíveis no cliente, mas isso muitas vezes pode expor APIs e outros tratamentos de modo que usuários mais iniciantes consigam identificar e interceptar estas informações diretamente e gerar chamadas diretas.

Aplicações Windows Forms, ainda mais quando ofuscadas, dificultam o acesso a este tipo de dados. Não impedem totalmente. Afinal, é possível gerar uma engenharia reversa, mesmo que incompleta devido a ofuscamento, ou até mesmo utilizar um sniffer na rede para interceptar pacotes, mas dificultam ainda mais em aplicações corporativas de uso interno, como mencionei no item sobre call centers.

Concluindo

Meu objetivo neste artigo não é dizer “Utilizem apenas aplicações Web”, “Utilizem apenas aplicações desktop”, ou até mesmo que é uma decisão fácil.

Devemos sempre buscar a melhor solução, atendendo a necessidade de negócio, usabilidade e performance para nossos usuários, fugindo da ideia de que existe apenas uma verdade absoluta quanto ao futuro do desenvolvimento de software.

Existe espaço para tudo e todos. Cada problema tem uma ou mais soluções diferentes – basta analisarmos com atenção e buscarmos o objetivo principal de um software: resolver um problema do usuário de forma mais simples, rápida e segura possível.

E neste final de semana, ainda teremos a terceira parte da série sobre Blazor, já com o back-end completo, focando agora na construção de nosso front-end em C#. Não percam!

Um abraço a todos e até a próxima.