Uma introdução ao Blazor para os desenvolvedores do 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 ASP.NET Web Forms tem sido um elemento essencial do desenvolvimento web do .NET desde que o .NET Framework foi lançado pela primeira vez em 2002. Quando a Web ainda estava em grande parte em sua infância, o ASP.NET Web Forms tornou a criação de aplicativos Web simples e produtiva, adotando muitos dos padrões usados para o desenvolvimento desktop. No ASP.NET Web Forms, as páginas da Web podem ser compostas rapidamente 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 do Web Forms fornecidos pela Microsoft e fornecedores de controle. Os controles facilitam os esforços de conexão com fontes de dados e exibição de visualizações de dados avançadas. Para aqueles que preferem recursos visuais, o editor de Web Forms fornece uma interface fácil de usar, baseada em arrastar e soltar, para gerenciar controle de componentes gráficos.

Ao longo dos anos, a Microsoft introduziu novos frameworks web baseados em ASP.NET para atender às tendências de desenvolvimento web. Algumas dessas estruturas da Web incluem ASP.NET MVC, ASP.NET Páginas da Web e, mais recentemente, ASP.NET Core. Com cada novo framework, alguns previram o declínio iminente do ASP.NET Web Forms e criticaram como um framework web desatualizado e antiquado. Apesar dessas previsões, muitos desenvolvedores web do .NET continuam a achar ASP.NET Web Forms uma maneira simples, estável e produtiva de realizar seu trabalho.

No momento da gravação, quase meio milhão de desenvolvedores Web usam ASP.NET Web Forms todos os meses. A estrutura ASP.NET Web Forms é estável a ponto de documentos, exemplos, livros e postagens no 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 concebido pela primeira vez. Argumentos sobre os prós e contras do ASP.NET Web Forms em comparação com as outras novas estruturas web do .NET podem continuar. ASP.NET Web Forms continua sendo uma estrutura popular para criar aplicativos Web.

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

1. A mudança para software livre e multiplataforma
2. A mudança da lógica do aplicativo para o cliente

Um .NET de software livre 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 área de trabalho e servidor foram dominados pelo Windows. Plataformas alternativas como macOS e Linux ainda estavam lutando para ganhar tração. ASP.NET Web Forms é fornecido com o .NET Framework como um componente somente do Windows, o que significa que ASP.NET aplicativos Web Forms só podem ser executados em computadores Windows Server. Muitos ambientes modernos agora usam diferentes tipos 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 software livre, que tem uma série de benefícios. Os usuários não estão limitados a um único responsável pelo projeto para corrigir bugs e adicionar recursos. Projetos de software livre fornecem maior transparência sobre o progresso do desenvolvimento e as alterações futuras. Projetos de software livre gozam de contribuições de toda uma comunidade e promovem um ecossistema de software livre de apoio. Apesar dos riscos de software livre, muitos consumidores e colaboradores encontraram mitigações adequadas que lhes permitem desfrutar dos benefícios de um ecossistema de software livre 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 adotou o suporte multiplataforma e o software livre. O .NET Core é uma implementação de software livre e multiplataforma do .NET que é executada em uma infinidade de plataformas, incluindo Windows, macOS e várias distribuições do Linux. Mono é uma versão open-source do .NET que é executada no Android, iOS e em uma variedade de outros dispositivos, incluindo relógios e TVs inteligentes. 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 de runtime uniformes e experiências de desenvolvedor".

O ASP.NET Web Forms se beneficiará da mudança para o suporte de software livre e 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 ASP.NET Web Forms não serão portados para .NET Core ou .NET 8. Por que isso?

Houve esforços nos primeiros dias do .NET Core para portar ASP.NET Web Forms. O número de alterações interruptivas necessárias foi considerado muito drástico. Há também uma admissão aqui de que, mesmo para a Microsoft, há um limite para o número de estruturas da Web que ela pode dar suporte simultaneamente. Talvez alguém da comunidade assuma a causa da criação de uma versão de software livre 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 ASP.NET Web Forms permanecerão somente no Windows e sem um modelo de contribuição de software livre. Se o suporte entre plataformas ou software livre se tornar importante para seus cenários, você precisará procurar algo novo.

Isso significa que ASP.NET Web Forms está morto e não deve mais ser usado? Claro que não! Desde que o .NET Framework seja fornecido como parte do Windows, ASP.NET Web Forms será uma estrutura suportada. Para muitos desenvolvedores do Web Forms, a falta de suporte multiplataforma e de software livre não é um problema. Se você não tiver um requisito para suporte multiplataforma, software livre ou qualquer um dos outros novos recursos no .NET Core ou no .NET 8, ficar com ASP.NET Web Forms no Windows será bom. ASP.NET Web Forms continuarão a ser uma maneira produtiva de escrever aplicativos Web por muitos anos.

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

Desenvolvimento da Web do lado do cliente

Todos os frameworks web baseados em .NET, incluindo o ASP.NET Web Forms, historicamente têm uma coisa em comum: são renderizadas por 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 ser manipulada. 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 tornaram-se 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 experiência mais rica e interativa ao serem geridas 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. Chamadas à API Web ou até mesmo protocolos em tempo real, como WebSockets, podem ser usados. Esses benefícios estarão disponíveis para desenvolvedores Web gratuitamente se eles estiverem dispostos a escrever JavaScript. As 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 aumentaram 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 a ponte de duas plataformas e ecossistemas diferentes (.NET e JavaScript) tem um custo. A experiência é necessária 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 sobrecarga de duplicação e engenharia. Também pode ser difícil acompanhar o ecossistema JavaScript, que tem um histórico de evoluir a uma velocidade vertiginosa. As preferências da estrutura de front-end e da ferramenta de build mudam rapidamente. A indústria observou a progressão de Grunt para Gulp para Webpack, e assim por diante. A mesma agitação ocorreu com estruturas de front-end como jQuery, Knockout, Angular, React e Vue. Mas dado o monopólio do navegador do JavaScript, não havia escolha no assunto. Ou seja, até que a comunidade web se reuniu e causou um milagre !

WebAssembly atende a uma necessidade

Em 2015, os principais fornecedores de navegador uniram forças em um Grupo de Comunidade W3C para criar um novo padrão 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, a uma 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. WebAssembly desde então, foi padronizado e implementado por todos os navegadores principais.

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 de ponta a ponta para criar aplicativos Web do lado do cliente. É aí Blazor que entra. 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 do 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 ótimo suporte para ferramentas no Visual Studio e no Visual Studio Code. A estrutura também inclui um modelo completo de componente de interface de usuário e tem facilidades embutidas para:

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

Blazor tem muito em comum com ASP.NET Web Forms. Ambas as estruturas oferecem modelos de programação de interface do usuário baseados em componentes, controlados por eventos e com estado. A principal diferença de arquitetura é que ASP.NET Web Forms é executado somente no servidor. Blazor pode ser executado no cliente no navegador. Mas se você vem de uma experiência em ASP.NET Web Forms, há muita coisa em Blazor que parecerá familiar. Blazor é uma solução natural para desenvolvedores do ASP.NET Web Forms que procuram uma maneira de aproveitar o desenvolvimento do lado do cliente e o futuro multiplataforma de software livre do .NET.

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

• Como criar Blazor aplicativos.
• Como Blazor funciona.
• Como Blazor se relaciona com o .NET.
• Estratégias razoáveis para migrar aplicativos web forms ASP.NET existentes para Blazor quando apropriado.

Comece com Blazor

Começar a usar Blazor é fácil. https://blazor.net Acesse e siga os links para instalar o SDK do .NET apropriado e Blazor os modelos de projeto. Você também encontrará instruções para configurar as Blazor ferramentas no Visual Studio ou no Visual Studio Code.

AnteriorPróximo