Skip to content

A nova classe startup.cs, onde a configuração começa

Hoje vou falar sobre a nova classe Startup.cs no novo ASP.NET Core e a entende-la melhor. Eu falo nova por que como o ASP.NET Core sofreu mudanças internas, a forma de inicializar o sistema também muda.

A nova classe Startup.cs no ASP.NET Core mudou e agora está muito mais limpa, dividida e como consequência mais clara. Essa pelo menos é a minha opinião. A primeira coisa que temos que entender é para que serve essa classe? Como ela é executada sendo que nada foi configurada para iniciar? Respondendo, esta classe serve para ser o ponto de partida do projeto, por default, a classe com nome Startup é inicializada de forma automática pelo ASP.NET. Nela é iniciada todas as configurações necessários para o projeto e agora vou mostrar a entender melhor essas configurações.

Três métodos são vistos na classe Startup.cs quando criado através do template do VS:

• Método Startup onde é responsável por carregar os valores da configuração
• Método ConfigureServices onde é responsável por adicionar os serviços no container do injetor de dependência.
• Método Configure onde é responsável por adicionar os middlewares e serviços no HTTP pipeline.

Se você ainda não está familiarizado sobre Middleware, você pode acessar um outro artigo meu que fala sobre o assunto.

Agora vem a melhor hora, vamos ver código!

O primeiro código é o método Startup.

Como todos sabem, agora não temos mais o clássico arquivo chamado “web.config”. A verdade é que toda configuração em XML foi extinta nessa nova versão do ASP.NET e no seu lugar estamos usando o formato JSON. Isso já é uma tendência de outras plataformas e a Microsoft resolveu aderir. Se não temos o “web.config”, agora temos o “appsettings.json” e ele se parece como isso:

Estas configurações que serão carregadas no construtor da classe Startup. Mas para carregar precisamos da interface IConfigurationRoot. O código é simples, é inicializado um builder que carrega as configurações do JSON e as variáveis de ambiente, por que para cada ambiente você poderá ter configurações diferentes. Isso é uma nova feature que vem no novo ASP.NET. E na última linha temos a propriedade da classe Configuration sendo setada, isso será importante para os próximos métodos.

O segundo código é do método ConfigureServices.

Outra mudança legal que tivemos no novo ASP.NET é a entrada de um DI nativo, mas você está livre para usar um outro de sua preferência. Neste método estamos informando quais serviços iremos adicionar ao DI para que possamos usar facilmente em todo o nosso aplicativo.

Neste especifico método, conforme pode ser visto, foi adicionado os serviços EF, Identity, MVC e duas classes especificas. Em relação ao EF, note que estamos informando a utilização do SQL Server e o Data Base Context onde é informado uma string de conexão do banco através da propriedade Configuration que foi inicializada no construtor.

Caso você tenha especificas classes do projeto que queria adicionar ao DI do aplicativo, você também utilizará o IServiceCollection. Para isso devemos utilizar um dos métodos abaixo conforme a documentação na Microsoft:

• Instance: A specific instance is given all the time. You are responsible for its initial creation.
• Transient: A new instance is created every time.
• Singleton: A single instance is created and it acts like a singleton.
• Scoped: A single instance is created inside the current scope. It is equivalent to Singleton in the current scope.

Notem que no método ConfigureServices para as especificas interfaces, IEmailSender e ISmsSender, foi utilizado o método AddTransient. A partir de agora, você poderá utilizar essas interfaces apenas inserindo no construtor das controllers que o DI se encarrega de injetar por você. Coisa linda!

Configure é o último método para ser analisado.

Neste método controlamos o ASP.NET pipeline. Vamos adicionar todos os middlewares necessários para o projeto. Fique atento, não adicione um middleware que não seja necessário ao projeto, pois isso acarreta em perda de performance pois é inserido no HTTP pipeline.

Para adicionar um middleware basta usar o parâmetro do tipo IApplicationBuilder e adicionar os necessários ao projeto. Caso nada seja configurado neste método, nem o MVC irá rodar corretamente pois você não informou ao aplicativo o que usar. Abaixo eu explico a responsabilidade dos middlewares ativados:

• UseBrowserLink: Cria um canal de comunicação entre o ambiente de desenvolvimento e um ou mais browsers.
• UseDeveloperExceptionPage: Mostra o detalhe da exception gerada pela aplicação.
• UseExceptionHandler: Manipula a exception gerada em uma especifica página
• UseIISPlatformHander: Indica o usa do servidor web IIS
• UseStaticFiles: Habilita a utilização de arquivos estáticos como CSS, JS e outros.
• UseMvc: Habilita o uso do framework MVC.

Além do parâmetro IApplicationBuilder, temos os parâmetros IHostingEnvironment e ILoggerFactory, onde o primeiro armazena informações sobre o atual ambiente hospedado. No código acima estamos utilizando essa variável para validar se estamos em ambiente de desenvolvimento e em caso positivo é adicionado middlewares especificas para esse ambiente. Já o segundo parâmetro permite configurar o log do sistema onde isso é feito na primeira linha do método.

Conclusão

Não é difícil entender como se comporta a nova classe Startup.cs no ASP.NET Core, mas é essencial aplicar esses fundamentos para um correto funcionamento da aplicação e por isso se atente em quais serviços e middlewares serão adicionados para que você tenha uma aplicação leve e rápida.

Fontes

https://blogs.msdn.microsoft.com/webdev/2014/06/17/dependency-injection-in-asp-net-vnext/
https://github.com/aspnet/Configuration/issues/277
https://www.exceptionnotfound.net/the-startup-file-in-asp-net-core-1-0-what-does-it-do/

Published in.Net Core

Be First to Comment

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *