Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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.
Embora ASP.NET Web Forms e Blazor tenham muitos conceitos semelhantes, há diferenças em como eles funcionam. Este capítulo examina o funcionamento interno e as arquiteturas de ASP.NET Web Forms e Blazor.
ASP.NET Web Forms
A estrutura do ASP.NET Web Forms baseia-se em uma arquitetura centrada na página. Cada solicitação HTTP para um local no aplicativo é uma página separada com a qual ASP.NET responde. À medida que as páginas são solicitadas, o conteúdo do navegador é substituído pelos resultados da página solicitada.
As páginas consistem nos seguintes componentes:
- Marcação HTML
- Código C# ou Visual Basic
- Uma classe code-behind que contém recursos lógicos e de manipulação de eventos
- Controles
Os controles são unidades reutilizáveis da interface do usuário da Web que podem ser colocadas e interagidas programaticamente em uma página. As páginas são compostas por arquivos que terminam com .aspx contendo marcação, controles e algum código. As classes code-behind estão em arquivos com o mesmo nome base e uma extensão .aspx.cs ou .aspx.vb , dependendo da linguagem de programação usada. Curiosamente, o servidor Web interpreta o conteúdo dos arquivos .aspx e os compila sempre que eles são alterados. Essa recompilação ocorre mesmo se o servidor Web já estiver em execução.
Os controles podem ser criados com marcação e entregues como controles de usuário. Um controle de usuário deriva da UserControl
classe e tem uma estrutura semelhante à Página. A marcação para controles de usuário é armazenada em um arquivo .ascx . Uma classe code-behind que acompanha reside em um arquivo .ascx.cs ou .ascx.vb. Os controles também podem ser construídos completamente com código, herdando da classe base WebControl
ou da classe base CompositeControl
.
As páginas também têm um extenso ciclo de vida de eventos. Cada página gera eventos para os eventos de inicialização, carregamento, pré-geração e descarregamento que ocorrem à medida que o runtime ASP.NET executa o código da página para cada solicitação.
Controles em uma página normalmente de post-back para a mesma página que apresentou o controle e que carregam junto com eles uma carga de um campo de formulário oculto chamado ViewState
. O ViewState
campo contém informações sobre o estado dos controles no momento em que eles foram renderizados e apresentados na página, permitindo que o ASP.NET runtime compare e identifique as alterações no conteúdo enviado ao servidor.
Blazor
Blazor é um framework de interface do usuário da Web do lado do cliente, semelhante aos frameworks de JavaScript para front-end, como Angular ou React. Blazor manipula as interações do usuário e renderiza as atualizações de interface do usuário necessárias. Blazor não é baseado em um modelo de solicitação-resposta. As interações do usuário são tratadas como eventos que não estão no contexto de nenhuma solicitação HTTP específica.
Blazor os aplicativos consistem em um ou mais componentes raiz renderizados em uma página HTML.
Como o usuário especifica onde os componentes devem ser renderizados e como os componentes são conectados para interações do usuário é específico do modelo de hospedagem .
Blazor os componentes são classes .NET que representam uma parte reutilizável da interface do usuário. Cada componente mantém seu próprio estado e especifica sua própria lógica de renderização, que pode incluir a renderização de outros componentes. Os componentes especificam manipuladores de eventos para interações específicas do usuário para atualizar o estado do componente.
Depois que um componente manipula um evento, Blazor renderiza o componente e controla o que foi alterado na saída renderizada. Os componentes não são renderizados diretamente no DOM (Modelo de Objeto de Documento). Em vez disso, eles são renderizados para uma representação na memória do DOM chamada a RenderTree
para que Blazor possa acompanhar as alterações.
Blazor compara a saída renderizada recentemente com a saída anterior para calcular uma diferença na UI que então aplica com eficiência ao DOM.
Os componentes também podem indicar manualmente que devem ser renderizados se o estado for alterado fora de um evento normal da interface do usuário.
Blazor usa um SynchronizationContext
para impor um único thread lógico de execução. Os métodos de ciclo de vida de um componente e quaisquer retornos de chamada de evento gerados pelo Blazor são executados neste SynchronizationContext
.