Uma introdução para Blazor desenvolvedores de Web Forms ASP.NET
Gorjeta
Este conteúdo é um excerto do eBook, Blazor para ASP NET Web Forms Developers for Azure, disponível no .NET Docs ou como um PDF transferível gratuito que pode ser lido offline.
A estrutura ASP.NET Web Forms tem sido um elemento básico do desenvolvimento da Web .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, ASP.NET Web Forms tornaram a criação de aplicativos Web simples e produtiva, adotando muitos dos padrões que eram usados para desenvolvimento de desktop. Em 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 rico ecossistema de controles de interface do usuário de 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 os visualmente inclinados, o designer de Web Forms fornece uma interface simples de arrastar e soltar para gerenciar controles.
Ao longo dos anos, a Microsoft introduziu novos aplicativos ASP. Frameworks web baseados em NET para abordar as tendências de desenvolvimento web. Algumas dessas estruturas da Web incluem ASP.NET MVC, ASP.NET Web Pages e, mais recentemente, ASP.NET Core. Com cada nova estrutura, alguns previram o declínio iminente de ASP.NET Web Forms e criticaram-na como uma estrutura web ultrapassada e ultrapassada. Apesar dessas previsões, muitos desenvolvedores da Web .NET continuam a encontrar ASP.NET Web Forms uma maneira simples, estável e produtiva de realizar seu trabalho.
No momento em que este artigo foi escrito, quase meio milhão de desenvolvedores da 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 de blog de uma década atrás permanecerem úteis e relevantes. Para muitos desenvolvedores da Web .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 de ASP.NET Web Forms em comparação com os outros novos frameworks da Web .NET podem ser agressivos. ASP.NET Web Forms continua sendo uma estrutura popular para a criação de 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:
- A mudança para código aberto e multiplataforma
- A mudança da lógica do aplicativo para o cliente
Um .NET de código aberto e plataforma cruzada
Quando o .NET e o ASP.NET Web Forms foram lançados 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. 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 máquinas de desenvolvimento, de modo que o suporte multiplataforma para muitos usuários é um requisito absoluto.
A maioria dos frameworks web modernos agora também são de código aberto, o que tem uma série de benefícios. Os usuários não são contemplados por um único proprietário de projeto para corrigir bugs e adicionar recursos. Os projetos de código aberto proporcionam maior transparência sobre o progresso do desenvolvimento e as mudanças futuras. Os projetos de código aberto desfrutam de contribuições de toda uma comunidade e promovem um ecossistema de código aberto de apoio. Apesar dos riscos do código aberto, muitos consumidores e contribuidores encontraram mitigações adequadas que lhes permitem desfrutar dos benefícios de um ecossistema de código aberto de forma segura e razoável. Exemplos de tais mitigações incluem contratos de licença de contribuidor, licenças amigáveis, varreduras de linhagem e fundações de suporte.
A comunidade .NET adotou o suporte multiplataforma e o código aberto. O .NET Core é uma implementação de código aberto e multiplataforma do .NET que é executado em uma infinidade de plataformas, incluindo Windows, macOS e várias distribuições Linux. O Xamarin fornece o Mono, uma versão de código aberto do .NET. O Mono é executado em Android, iOS e 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 tempo de execução e estrutura do .NET que pode ser usado em qualquer lugar e que tem comportamentos de tempo de execução uniformes e experiências de desenvolvedor".
Os Web Forms ASP.NET beneficiarão da mudança para o suporte de código aberto e multiplataforma? A resposta, infelizmente, é não, ou pelo menos não na mesma medida que o resto da plataforma. A equipe do .NET deixou claro que ASP.NET Web Forms não serão portados para o .NET Core ou .NET 8. Porquê?
Houve esforços nos primeiros dias do .NET Core para portar ASP.NET Web Forms. O número de alterações necessárias foi considerado demasiado 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 suportar simultaneamente. Talvez alguém na comunidade assuma a causa de criar uma versão de código aberto e multiplataforma de ASP.NET Web Forms. O código-fonte para ASP.NET Web Forms foi disponibilizado publicamente em forma de referência. Mas, por enquanto, parece ASP.NET Web Forms permanecerão apenas para Windows e sem um modelo de contribuição de código aberto. Se o suporte multiplataforma ou de código aberto se tornar importante para seus cenários, então você precisará procurar algo novo.
Isso significa ASP.NET Web Forms está inativo e não deve mais ser usado? Claro que não! Contanto que o .NET Framework seja fornecido como parte do Windows, ASP.NET Web Forms será uma estrutura suportada. Para muitos desenvolvedores de Web Forms, a falta de suporte multiplataforma e de código aberto é um não-problema. Se você não tiver um requisito de suporte entre plataformas, código aberto ou qualquer um dos outros novos recursos no .NET Core ou .NET 8, então manter ASP.NET Web Forms no Windows é 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, que é a mudança para o cliente.
Desenvolvimento web do lado do cliente
Todos os . As estruturas da Web baseadas em NET, incluindo ASP.NET Web Forms, historicamente têm uma coisa em comum: são renderizadas em servidor. Em aplicativos Web renderizados por 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 tratada. Neste modelo, o navegador é usado como um mecanismo de renderização fina. 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 web abertos que concedem acesso aos recursos da máquina do usuário. Por que não aproveitar o poder de computação, armazenamento, memória e outros recursos do dispositivo cliente? As interações da interface do usuário, em particular, podem se beneficiar de uma sensação mais rica e interativa quando tratadas pelo menos parcialmente ou completamente do lado do cliente. A lógica e os dados que devem ser manipulados no servidor ainda podem ser manipulados no lado do servidor. Chamadas de API da Web ou até mesmo protocolos em tempo real, como WebSockets, podem ser usados. Esses benefícios estã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 têm crescido em popularidade. ASP.NET desenvolvedores de Web Forms também podem se beneficiar da alavancagem do cliente e até mesmo ter algum suporte pronto para uso com estruturas JavaScript integradas, como ASP.NET AJAX.
Mas unir duas plataformas e ecossistemas diferentes (.NET e JavaScript) tem um custo. A experiência é necessária em dois mundos paralelos com linguagens, estruturas e ferramentas diferentes. O código e a lógica não podem ser facilmente compartilhados entre cliente e 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 a uma velocidade vertiginosa. As preferências da estrutura de front-end e da ferramenta de criação mudam rapidamente. A indústria observou a progressão de Grunt para Gulp para Webpack, e assim por diante. A mesma rotatividade inquieta ocorreu com frameworks front-end como jQuery, Knockout, Angular, React e Vue. Mas, dado o monopólio do navegador JavaScript, havia pouca escolha no assunto. Ou seja, até que a comunidade web se juntou e fez um milagre acontecer!
WebAssembly satisfaz uma necessidade
Em 2015, os principais fornecedores de navegadores uniram forças em um W3C Community Group para criar um novo padrão aberto da Web chamado WebAssembly. WebAssembly é um código de byte para a Web. Se você puder compilar seu código para WebAssemblyo , ele poderá ser executado em qualquer navegador em qualquer plataforma a uma velocidade quase nativa. Os esforços iniciais concentraram-se em C/C++. O resultado foi uma demonstração dramática da execução de motores gráficos 3D nativos diretamente no navegador sem plugins. WebAssembly desde então, foi padronizado e implementado por todos os principais navegadores.
O trabalho na execução do .NET on WebAssembly foi anunciado no final de 2017 e lançado em 2020, incluindo suporte no .NET 5 e além. A capacidade de executar código .NET diretamente no navegador permite o desenvolvimento web full-stack com .NET.
Blazor: desenvolvimento web full-stack com .NET
Por si só, a capacidade de executar código .NET em um navegador não fornece uma experiência de ponta a ponta para a criação de 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 através WebAssemblydo . Nenhum plug-in do navegador é necessário. Como alternativa, Blazor os aplicativos podem ser executados no lado do servidor no .NET e lidar com todas as interações do usuário em uma conexão em tempo real com o navegador.
Blazor tem grande suporte a ferramentas no Visual Studio e Visual Studio Code. A estrutura também inclui um modelo de componente de interface do usuário completo e tem recursos internos para:
- Formulários e validação
- Injeção de dependência
- Roteamento do lado do cliente
- Esquemas
- 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 com monitoração de estado, orientados a eventos e baseados em componentes. 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 um fundo de Web Forms ASP.NET, há muito em Blazor que se sentirá familiar. Blazor é uma solução natural para desenvolvedores de Web Forms ASP.NET que procuram uma maneira de tirar proveito do desenvolvimento do lado do cliente e do futuro de código aberto e multiplataforma do .NET.
Este livro fornece uma introdução ao Blazor que é servido especificamente para ASP.NET desenvolvedores de Web Forms. Cada Blazor conceito é apresentado no contexto de recursos e práticas análogas ASP.NET Web Forms. Ao final deste livro, você terá uma compreensão de:
- Como criar Blazor aplicações.
- Como Blazor funciona.
- Como Blazor se relaciona com o .NET.
- Estratégias razoáveis para migrar aplicativos ASP.NET Web Forms existentes para Blazor onde apropriado.
Introdução a Blazor
Começar é Blazor fácil. Vá e https://blazor.net siga os links para instalar o SDK do .NET e Blazor os modelos de projeto apropriados. Você também encontrará instruções para configurar as Blazor ferramentas no Visual Studio ou Visual Studio Code.
