Inicialização do aplicativo

Dica

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

Baixar PDF

Os aplicativos que são gravados para ASP.NET normalmente têm um global.asax.cs arquivo que define o Application_Start evento que controla quais serviços são configurados e disponibilizados para renderização HTML e processamento do .NET. Este capítulo analisa como as coisas são ligeiramente diferentes com ASP.NET Core e Blazor Server.

Application_Start e Web Forms

O método padrão de formulários da web Application_Start evoluiu ao longo dos anos para lidar com várias tarefas de configuração. Um novo projeto de formulários Da Web com o modelo padrão no Visual Studio contém a seguinte lógica de configuração:

• RouteConfig – Roteamento de URL do aplicativo
• BundleConfig - Agrupamento e minificação de CSS e JavaScript

Cada um desses arquivos individuais reside na App_Start pasta e é executado apenas uma vez no início do nosso aplicativo. RouteConfig no modelo de projeto padrão, adiciona FriendlyUrlSettings para web forms para permitir que as URLs do aplicativo omitam a extensão de arquivo .ASPX. O modelo padrão também contém uma diretiva que fornece códigos de status de redirecionamento HTTP permanentes (HTTP 301) das páginas .ASPX para a URL amigável com o nome do arquivo que omite a extensão.

Com ASP.NET Core e Blazor, esses métodos são simplificados e consolidados na Startup classe ou são eliminados em favor de tecnologias web comuns.

Estrutura de inicialização do Servidor Blazor

Os aplicativos Blazor Server residem em uma versão ASP.NET Core 3.0 ou posterior. ASP.NET Principais aplicativos Web são configurados em Program.cs ou por meio de um par de métodos na Startup.cs classe. Um arquivo de Program.cs de exemplo é mostrado abaixo:

using BlazorApp1.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

Os serviços necessários do aplicativo são adicionados à coleção WebApplicationBuilder da instância Services. É assim que os vários serviços do framework ASP.NET Core são configurados com o contêiner de injeção de dependência interno do framework. Os vários métodos builder.Services.Add* adicionam serviços que permitem recursos, como autenticação, Razor Pages, roteamento de controlador de MVC, SignalR e interações do Blazor Server, entre muitos outros. Esse método não era necessário nos formulários da Web, pois a análise e o tratamento dos arquivos ASPX, ASCX, ASHX e ASMX foram definidos referenciando ASP.NET no arquivo de configuração web.config. Mais informações sobre a injeção de dependência no ASP.NET Core estão disponíveis na documentação online.

Após a criação de app por builder, as demais chamadas em app configuram seu pipeline HTTP. Com essas chamadas, declaramos de cima para baixo o Middleware que manipulará cada solicitação enviada ao nosso aplicativo. A maioria desses recursos na configuração padrão foram espalhados pelos arquivos de configuração de formulários da Web e agora estão em um só lugar para facilitar a referência.

A configuração da página de erro personalizada não é mais colocada em um arquivo web.config. Agora, está configurada para sempre ser mostrada quando o ambiente do aplicativo não tiver o rótulo Development. Além disso, os aplicativos ASP.NET Core agora estão configurados para atender páginas seguras com TLS por padrão com a chamada de UseHttpsRedirection método.

Em seguida, uma chamada inesperada do método de configuração é feita para UseStaticFiles. No ASP.NET Core, o suporte para solicitações de arquivos estáticos (como JavaScript, CSS e arquivos de imagem) deve ser habilitado explicitamente e apenas os arquivos na pasta wwwroot do aplicativo são endereçáveis publicamente por padrão.

A próxima linha é a primeira que replica uma das opções de configuração dos formulários da Web: UseRouting. Esse método adiciona o roteador ASP.NET Core ao pipeline e pode ser configurado aqui ou nos arquivos individuais para os quais ele pode considerar o roteamento. Mais informações sobre a configuração de roteamento podem ser encontradas na seção Roteamento.

As chamadas finais app.Map* nesta seção definem os pontos de extremidade que ASP.NET Core está escutando. Essas rotas são os locais acessíveis para a Web que você pode acessar no servidor Web e receber algum conteúdo manipulado pelo .NET e retornado a você. A primeira entrada, MapBlazorHub, configura um hub SignalR para uso, fornecendo uma conexão persistente e em tempo real com o servidor onde o estado e a renderização dos componentes Blazor são tratados. A chamada de método MapFallbackToPage indica o local acessível pela Web da página que inicia o aplicativo Blazor e também configura o aplicativo para gerenciar solicitações de linkagem direta do lado do cliente. Você verá esse recurso em ação se abrir um navegador e navegar diretamente para a rota manipulada pelo Blazor no seu aplicativo, como /counter no modelo de projeto padrão. A solicitação é manipulada pela página de fallback _Host.cshtml , que executa o roteador Blazor e renderiza a página do contador.

A última linha inicia o aplicativo, algo que não era necessário nos formulários da Web (já que ele dependia do IIS para ser executado).

Atualizando o processo BundleConfig

As tecnologias para agrupar ativos como folhas de estilo CSS e arquivos JavaScript foram alteradas significativamente, com outras tecnologias fornecendo ferramentas e técnicas em rápida evolução para gerenciar esses recursos. Para isso, recomendamos usar uma ferramenta de linha de comando do Node, como Grunt/Gulp/WebPack, para empacotar seus ativos estáticos.

As ferramentas de linha de comando Grunt, Gulp e WebPack e suas configurações associadas podem ser adicionadas ao seu aplicativo e ASP.NET Core ignorará silenciosamente esses arquivos durante o processo de build do aplicativo. Você pode adicionar uma chamada para executar as tarefas adicionando um Target ao arquivo de projeto com sintaxe semelhante à seguinte que dispararia um script gulp e o destino min dentro desse script:

<Target Name="MyPreCompileTarget" BeforeTargets="Build">
  <Exec Command="gulp min" />
</Target>

Mais detalhes sobre ambas as estratégias para gerenciar seus arquivos CSS e JavaScript estão disponíveis na documentação Agrupar e minificar ativos estáticos em ASP.NET Core.

AnteriorPróximo