Uma introdução a Blazor para desenvolvedores de ASP.NET Web Forms

Dica

Esse conteúdo é um trecho do livro eletrônico, Blazor para Desenvolvedores do ASP NET Web Forms para o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

A estrutura do ASP.NET Web Forms tem sido um dos pilares do desenvolvimento Web do .NET desde que o .NET Framework foi lançado em 2002. Quando a Web ainda estava em sua infância, o ASP.NET Web Forms simplificou e deu mais produtividade à criação de aplicativos Web por meio da adoção de muitos dos padrões usados para o desenvolvimento da área de trabalho. No ASP.NET Web Forms, as páginas da Web podem ser compostas rapidamente a partir de controles de interface do usuário reutilizáveis. As interações do usuário são tratadas naturalmente como eventos. Há um ecossistema avançado de controles de interface do usuário no Web Forms fornecido pela Microsoft e por fornecedores de controle. Os controles facilitam os esforços de conexão com fontes de dados e a exibição de visualizações de dados avançadas. Para quem prioriza o visual, o designer do Web Forms fornece uma interface simples de arrastar e soltar para gerenciar controles.

Ao longo dos anos, a Microsoft introduziu novas estruturas Web baseadas em ASP.NET para abordar tendências de desenvolvimento na Web. Algumas dessas estruturas da Web incluem ASP.NET MVC, Páginas da Web do ASP.NET e, mais recentemente, ASP.NET Core. A cada nova estrutura, alguns previram o declínio iminente do ASP.NET Web Forms e o criticaram como uma estrutura Web desatualizada e ultrapassada. Apesar dessas previsões, muitos desenvolvedores Web em .NET continuam considerando o ASP.NET Web Forms uma maneira simples, estável e produtiva de fazer seu trabalho.

No momento da produção deste texto, quase meio milhão de desenvolvedores Web usam o ASP.NET Web Forms todos os meses. A estrutura do ASP.NET Web Forms é tão estável a ponto de documentos, amostras, livros e postagens de blog de uma década atrás permanecerem úteis e relevantes. Para muitos desenvolvedores Web do .NET, "ASP.NET" ainda é sinônimo de "ASP.NET Web Forms", como era quando o .NET foi criado. Os argumentos prós e contras o ASP.NET Web Forms em comparação com as outras novas estruturas Web do .NET podem continuar. O ASP.NET Web Forms continua sendo uma estrutura popular para criação de aplicativos Web.

Mesmo assim, as inovações no desenvolvimento de software não estão desacelerando. Todos os desenvolvedores de software precisam ficar a par de novas tecnologias e tendências. Vale a pena considerar duas tendências em particular:

1. A mudança para código aberto e multiplataforma
2. A mudança da lógica de aplicativo para o cliente

Um .NET de código aberto e multiplataforma

Quando o .NET e o ASP.NET Web Forms foram enviados pela primeira vez, o ecossistema da plataforma parecia muito diferente do que é hoje. Os mercados de desktop e servidor foram dominados pelo Windows. Plataformas alternativas como macOS e Linux ainda estavam lutando para ganhar tração. O ASP.NET Web Forms é fornecido com o .NET Framework como um componente somente do Windows, o que significa que os aplicativos ASP.NET Web Forms só podem ser executados em computadores com Windows Server. Muitos ambientes modernos agora usam tipos diferentes de plataformas para servidores e computadores de desenvolvimento, de modo que o suporte multiplataforma para muitos usuários é um requisito absoluto.

A maioria das estruturas da Web modernas agora também são de código aberto, o que apresenta diversos benefícios. Os usuários não dependem de um único proprietário do projeto para corrigir bugs e adicionar recursos. Os projetos de código aberto fornecem maior transparência sobre o progresso do desenvolvimento e as alterações futuras. Projetos de código aberto gozam de contribuições de toda uma comunidade e promovem um ecossistema de código aberto solidário. Apesar dos riscos do código aberto, muitos consumidores e colaboradores encontraram mitigações adequadas que lhes permitem desfrutar dos benefícios de um ecossistema de código aberto de forma segura e razoável. Entre os exemplos dessas mitigações estão contratos de licença de colaborador, licenças amigáveis, verificações de pedigree e fundamentos de suporte.

A comunidade do .NET abraçou o suporte multiplataforma e o código aberto. O .NET Core é uma implementação de código aberto e multiplataforma do .NET executada em uma infinidade de plataformas, incluindo Windows, macOS e várias distribuições do Linux. O Xamarin fornece o Mono, uma versão de código aberto do .NET. O Mono é executado no Android, iOS e em uma variedade de outros fatores de forma, incluindo relógios e smart TVs. Em 2020, a Microsoft lançou o .NET 5 que reconciliou o .NET Core e o Mono em "um único runtime e estrutura do .NET que pode ser usado em todos os lugares e que tem comportamentos uniformes de runtime e experiências de desenvolvedor".

O ASP.NET Web Forms se beneficiará da mudança para o suporte a código aberto e a multiplataforma? A resposta, infelizmente, é não, ou pelo menos não na mesma medida que o restante da plataforma. A equipe do .NET deixou claro que o ASP.NET Web Forms não será portabilizado para .NET Core ou .NET 8. Por quê?

Houve esforços nos primeiros dias do .NET Core para portabilizar o ASP.NET Web Forms. O número de alterações interruptivas necessárias foi considerado muito drástico. Há também uma aceitação aqui de que, mesmo para a Microsoft, há um limite no número de estruturas da Web que ela pode dar suporte simultaneamente. Talvez alguém na comunidade assuma a causa da criação de uma versão de código aberto e multiplataforma do ASP.NET Web Forms. O código-fonte do ASP.NET Web Forms foi disponibilizado publicamente no formulário de referência. Mas, por enquanto, parece que o ASP.NET Web Forms permanecerá apenas para Windows e sem um modelo de contribuição de software livre. Se o suporte entre plataformas ou código aberto tornar-se importante para seus cenários, você precisará procurar algo novo.

Isso significa que o ASP.NET Web Forms estará morto e não deve mais ser usado? É claro que não! Enquanto o .NET Framework for fornecido como parte do Windows, o ASP.NET Web Forms será uma estrutura com suporte. Para muitos desenvolvedores em Web Forms, a falta de suporte multiplataforma e de código aberto não é um problema. Se você não tiver um requisito de suporte multiplataforma, de código aberto ou de qualquer um dos novos recursos do .NET Core ou do .NET 8, ainda valerá a pena ficar com o ASP.NET Web Forms no Windows. O ASP.NET Web Forms continuará sendo uma maneira produtiva de escrever aplicativos Web por muitos anos.

Mas há outra tendência que vale a pena considerar, e é a mudança para o cliente.

Desenvolvimento Web do lado do cliente

Todas as estruturas Web baseadas em NET, incluindo o ASP.NET Web Forms, têm historicamente uma coisa em comum: elas são renderizadas pelo servidor. Em aplicativos Web renderizados pelo servidor, o navegador faz uma solicitação ao servidor, que executa algum código (código .NET em aplicativos ASP.NET) para produzir uma resposta. Essa resposta é enviada de volta ao navegador para manipulação. Nesse modelo, o navegador é usado como um mecanismo de renderização fino. O trabalho árduo de produzir a interface do usuário, executar a lógica de negócios e gerenciar o estado ocorre no servidor.

No entanto, os navegadores se tornaram plataformas versáteis. Eles implementam um número cada vez maior de padrões da Web abertos que concedem acesso aos recursos do computador do usuário. Por que não aproveitar a potência de computação, o armazenamento, a memória e outros recursos do dispositivo cliente? Interações de interface do usuário, em particular, podem se beneficiar de uma sensação mais rica e interativa quando tratadas pelo menos parcial ou completamente do lado do cliente. A lógica e os dados que devem ser tratados no servidor ainda podem ser tratados no lado do servidor. É possível usar chamadas à API Web ou até mesmo protocolos em tempo real, como WebSockets. Esses benefícios estarão disponíveis gratuitamente para os desenvolvedores Web se eles estiverem dispostos a escrever em JavaScript. Estruturas de interface do usuário do lado do cliente, como Angular, React e Vue, simplificam o desenvolvimento da Web do lado do cliente e cresceram em popularidade. Desenvolvedores de ASP.NET Web Forms também podem se beneficiar do cliente e até mesmo ter algum suporte pronto para uso com estruturas JavaScript integradas, como ASP.NET AJAX.

Mas criar uma ponte entre duas plataformas e ecossistemas diferentes (.NET e JavaScript) tem um custo. É necessário ter experiência em dois mundos paralelos com diferentes linguagens, estruturas e ferramentas. O código e a lógica não podem ser facilmente compartilhados entre o cliente e o servidor, resultando em duplicação e sobrecarga de engenharia. Também pode ser difícil acompanhar o ecossistema JavaScript, que tem um histórico de evolução em velocidade vertiginosa. As preferências da estrutura de front-end e de ferramenta de build mudam rapidamente. O setor testemunhou a progressão de Grunt para Gulp, depois para Webpack e assim por diante. A mesma agitação ocorreu com estruturas de front-end como jQuery, Knockout, Angular, React e Vue. Mas graças ao monopólio do navegador do JavaScript, não havia muita opção. Quer dizer, até que a comunidade Web se reuniu e fez um milagre acontecer!

WebAssembly atende a uma necessidade

Em 2015, os principais fornecedores de navegador uniram forças em um Grupo comunitário W3C para criar um novo padrão da Web aberto chamado WebAssembly. WebAssembly é um código de byte para a Web. Se você puder compilar seu código para WebAssembly, ele poderá ser executado em qualquer navegador em qualquer plataforma em velocidade quase nativa. Esforços iniciais focados em C/C++. O resultado foi uma demonstração dramática da execução de mecanismos gráficos 3D nativos diretamente no navegador sem plug-ins. Desde então, WebAssembly foi padronizado e implementado por todos os principais navegadores.

O trabalho de execução do .NET em WebAssembly foi anunciado no final de 2017 e lançado em 2020, incluindo suporte no .NET 5 e além. A capacidade de executar o código .NET diretamente no navegador permite o desenvolvimento da Web de pilha completa com o .NET.

Blazor: desenvolvimento Web de pilha completa com .NET

Por si só, a capacidade de executar o código .NET em um navegador não fornece uma experiência completa para criar aplicativos Web do lado do cliente. É aí que Blazor entra em cena. Blazor é uma estrutura de interface do usuário da Web do lado do cliente baseada em C# em vez de JavaScript. Blazor pode ser executado diretamente no navegador por meio de WebAssembly. Nenhum plug-in de navegador é necessário. Como alternativa, os aplicativos Blazor podem executar no lado do servidor em .NET e lidar com todas as interações do usuário em uma conexão em tempo real com o navegador.

Blazor tem um ótimo suporte a ferramentas no Visual Studio e no Visual Studio Code. A estrutura também inclui um modelo completo de componentes da interface do usuário e tem instalações internas para:

• Formulários e validação
• Injeção de dependência
• Roteamento do lado do cliente
• Layouts
• Depuração no navegador
• Interoperabilidade do JavaScript

Blazor tem muito em comum com ASP.NET Web Forms. As duas estruturas oferecem modelos de programação de interface do usuário baseados em componentes, orientados por eventos e com estado. A principal diferença de arquitetura é que o ASP.NET Web Forms é executado somente no servidor. Blazor pode ser executado no cliente, no navegador. Mas se você tiver experiência com ASP.NET Web Forms, verá que conhece muitas coisas em Blazor. Blazor é uma solução natural para desenvolvedores em ASP.NET Web Forms que procuram uma maneira de aproveitar o desenvolvimento do lado do cliente e o futuro multiplataforma de código aberto do .NET.

Este livro fornece uma introdução ao Blazor criada especificamente para desenvolvedores de ASP.NET Web Forms. Cada conceito de Blazor é apresentado no contexto de recursos e práticas análogas ao ASP.NET Web Forms. Ao final deste livro, você terá uma compreensão de:

• Como compilar aplicativos Blazor.
• Como o Blazor funciona.
• Como o Blazor se relaciona com o .NET.
• Estratégias razoáveis para migrar aplicativos ASP.NET Web Forms existentes para Blazor, quando apropriado.

Introdução ao Blazor

Introdução facilitada ao Blazor. Acesse https://blazor.net e siga os links para instalar o SDK do .NET e os modelos de projeto do Blazor apropriados. Você também encontrará instruções para configurar as ferramentas de Blazor no Visual Studio ou no Visual Studio Code.

AnteriorAvançar