Asp.Net 5 (Parte 3) - Novo Pipeline para aplicações WEB

Dando continuidade a série ASP.NET 5, hoje vamos tratar com um pouco mais de detalhes das novidades que foram implementadas no novo Pipeline. O mundo de desenvolvimento web está em euforia esperando a liberação do release de produção que o time do ASP.NET está correndo para concluir. Essas melhorias vem sendo acompanhadas e divulgadas pela comunidade constantemente e hoje o nosso foco aqui é apresentar algumas mudanças de pensamento e a anatomia do novo pipeline, como: Services, Middleware, Servers, WebRoot e Configuration, além de apresentarmos com um pouco mais de detalhes a classe Startup.cs.

Muitos devem se perguntar: O projeto na empresa onde eu trabalho está funcionando 101% em Asp.Net MVC. Porque eu deveria mudar o que está funcionando? Ou, estou começando um projeto web do zero na empresa onde eu trabalho. Porque eu deveria desenvolver esse projeto de tal forma que ele já nascesse Cross-Plataform? Quais os ganhos e benefícios o projeto e minha equipe teria optando pela versão do ASP.NET 5? Qual a curva de aprendizado? Para responder a essas perguntas, vamos dar inicio ao nosso artigo.

Porque utilizar o ASP.NET 5 para Web Apps?

Em decorrência do aumento da necessidade de se desenvolver mais e mais aplicações web ricas e de alta performance, o ASP.NET 5 foi redesenhado contemplando todo o mindset das novas tendências das chamdas Modern Web Apps (Aplicações Web Modernas), buscando unificar sempre a idéia de Web UI com os recursos de Web API, favorecendo os vários frameworks MV* que temos hoje, por exemplo: AngularJS, KnockoutJS, EmberJS, BackboneJS.

Seguir o mindset de aplicações web modernas não foi o único foco que o time ASP.NET da Microsoft buscou. Outra característica foi incluida nesse framework de desenvolvimento web – que já era fantástico, agora ficou sensacional. Hoje o ASP.NET já nasce totalmente preparado para ser executado em um ambiente de Cloud, como o Windows Microsoft Azure, pois foi incluido o recurso: Environment Based Configuration. Essa característica possibilida o ASP.NET 5 ser utilizando em ambientes de microservice, com o Docker, isso graças ao novo pipeline de execução do asp.net, o qual deixou a execução mais leve e modular, onde o projeto implementa apenas o que precisa ser utilizado, tudo isso foi também facilitado pela integração do mecanismo de injeção de dependência (Dependency Injection), sobre o qual antes era necessário utilizarmos algum dos muitos framework de DI, tais como: Unity, Ninject, Castle Windsor, SimpleInjector, AutoFac, etc. Agora o mecanismo vem nativo na plataforma do ASP.NET 5.

Abaixo seguem alguns pontos que demonstram as principais melhorias que aconteceram com a recriação da engine:

  • Http pipeline mais leve e modular
  • Possibilidade de hospedagem tanto no IIS quanto utilizando Self-Hosting
  • Capacidade de execução da mesma aplicação, com versões de target framework diferentes, devido a implementação do .NET CORE
  • Gerenciamento de dependências server-side totalmente integrado com o NuGet
  • Um único Pipeline Stack para Web UI e Web APIs. (System.Web nunca mais !!!)
  • As novas web apps já nascem prontas para rodar em um ambiente hibrido de nuvem, por meio da reformulação do sistema de configuração.
  • Agora temos nativamente um mecanismo de Injeção de Dependência
  • Novas ferramentas do mundo open-source que foram integradas ao Visual Studio, facilitando a implementação de Modern Web Apps e gestão dos pacotes Client-Side
  • Execução e implementação em cenário cross-plataform: Windows, Linux e Mac
  • 100% Open-Source, com código publicado no Github

Redesign na anatomia de aplicações ASP.NET 5

Com o redesign da arquitetura do ASP.NET 5, toda a estrutura de um projeto de aplicação web mudou. Essas mudanças vão desde o arquivo de projeto (antigo .csproj) até todo o seu mecanismo de configuração e habilitação de recursos Web UI e Web API. Isso implica que, todo e qualquer projeto ASP.NET 5 já nasce como sendo um projeto do tipo DNX. Para começarmos ao que interessa, vamos começar primeiramente por onde quase tudo começa: Startup.cs.

A classe Startup.cs é uma das principais classes de inicialização e configuração do novo Pipeline. Ela contem 2 métodos extremamente importante, conforme segue o código abaixo:

public class Startup  
{
    public Startup(IHostingEnvironment env) { }
    public void ConfigureServices(IServiceCollection services) { }
    public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory) { }
}

O método ConfigureServices define quais serviços serão configurados e utilizados pela aplicação, no momento que o sistema web executar pela primeira vez. O método Configure é executado na sequência do pipeline, ou seja, logo após o término da execução do método anterior (ConfigureServices). A responsabilidade do método *Configure *é de tamanha relevância, pois o Http Request Pipeline assumirá todo o seu comportamento, mediante as configurações que foram implementadas neste método.

Services

O que representa um serviço para você? Um serviço é um componente que pode ser reutilizado por toda a aplicação. A reutilização de um serviço é realizada através da Injeção de Dependência, a qual no ASP.NET 5 temos uma simples implementação de Inversão de Controle que é nativa da plataforma. O mecanismo de DI implementado no ASP.NET 5 trabalha por padrão com injeção de dependência através dos Consturctors das classes. No caso de você precisar utilizar alguns dos muitos framework de DI (Unity, SimpleInjector, Autofac, etc), você pode substituir do mecanismo nativo, por qualquer um de sua preferência.

A injeção de dependência do ASP.NET 5 trabalha com três características: Singleton, Scoped e Transiente, explicadas no quadro abaixo:

Tipo de Contexto

Singleton

A instância do objeto que será injetado, será criada uma e somente uma única vez dentro do Container, independe do contexto.

Scoped

A instância do objeto que será injetado, somente será criada no caso de, no mesmo contexto, ainda não existir a instância do objeto solicitado ao Container.

Transient

A instância do objeto que será injetado, é criada a cada requisição que chega no servidor e precisa ser criada pelo Container.

Middlewares

Middlewares são extensões que foram implmentadas pelo time ASP.NET da Microsoft para flexibilizar o pipeline da nova plataforma web e também deixa-la mais leve (lightweight).

Toda lógica do sistema de configuração do novo pipeline é feita e trabalha de forma assíncrona e atua diretamente sobre o HttpContext, enquanto existir chamdas de configurações para outros middlewares o pipeline vai executar e configura-las. Mas como são realizadas essas configurações? Você lembra do método Configure?

Toda configuração de quantos e quais Middlewares serão utilizados pelo pipeline de uma aplicação ASP.NET 5, será realizada através do método Configure, conforme exemplo abaixo:

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerfactory)  
{
    app.UseErrorPage(ErrorPageOptions.ShowAll);
    app.UseStaticFiles();
    // Adiciona o MVC ao Request Pipeline
    app.UseMvc(routes => { routes.MapRoute( name: "default", template: "
        {controller=Home}/{action=Index}/{id?}"); }); }

Como vocês podem observar no trecho de código acima, estamos configurando um pipeline de uma pequena aplicação ASP.NET 5, utilizando-se de alguns Middlewares: UseMvc, UseStaticFiles, UseErrorPage. Nunca foi tão fácil configurar um Request Pipeline!

Servers

A composição da estrutura de funcionamento de aplicações ASP.NET não conseguiam ouvir diretamente requisições HTTP, ao invés disso eram implementadas uma gama grande de interfaces para encarar as requisições por meio do servidor do IIS, onde todas elas eram compostas pelo HttpContext.

A implementação do ASP.NET 5 possibilita que a mesma aplicação seja executada tanto em um servidor IIS quanto em seu próprio processo (Self-Hosting). Com a adoção de ser cross-plataform, uma aplicação ASP.NET 5 pode agora rodar como self-hosting em ambientes Windows e Unix, mas para isso cada plataforma terá seu próprio servidor para rodar como self-hosting, conforme a tabela abaixo:

Tipos de Servidores Web

WebListenner

Suas funcionalidades são todas baseadas no arquivo do sistema operacional Http.sys. Pode ser utilizado localmente para executar projetos web, em ambientes windows.

Kestrel

Servidor web para plataformas Unix (linux, Mac) utilizado, também, para executar projetos web localmente.

Como exemplo de utilização de uma aplicação utilizando Self-Hosting segue abaixo a configuração que vocês podem encontrar ou alterar, através do arquivo project.json:

"commands": { "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls https://localhost:5000" }

O comando acima, tem dependência do pacote:

"dependencies": { ... // New: "Microsoft.AspNet.Server.WebListener": "6.0.0-beta1" }

Web root

A pasta de web root que estamos acostumados a trabalhar desde sempre no ASP.NET, sempre foi a pasta do projeto. No ASP.NET 5, foi inseria uma nova pasta chamada wwwroot, essa é a pasta webroot que é configurada através do arquivo project.json (será explicado mais adiante). Então, quando falarmos em webroot agora, saiba que não mais estamos falando em 100% dos casos da mesma pasta do projeto, sempre observe a tag webroot configurada no arquivo project.json para identificar onde está a pasta root do projeto web.

Configuration

Quem nunca precisou configurar algum parâmetro em suas aplicações web por meio da seção: <appSettings></appSettings> no arquivo web.config? Antes tinhamos que declarar um using para System.Configuration e teriamos que ter um arquivo web.config em nossas aplicações web. Para os já trabalharam com esse tipo de configuração, sabem do que estou falando; para os que nunca viram esse tipo de prática, vão aprender uma nova forma de trabalhar com parâmetros de configuração.

A nova plataforma do ASP.NET 5 visando flexibilidade, escalabilidade e poder trabalhar em ambientes cross-plataform, inseriu uma nova estrutura: IConfiguration. Ou seja, mais um serviço de componente, que nos possibilitará trabalharmos com parâmetros de configurações de uma maneira mais fácil e mais fluida, através do conceito Chave-Valor (Key-Value). Tudo isso, utilizando-se de tags de configurações dentro do arquivo config.json. (Detalharemos a utilização desse novo recurso em outro aritgo).

Segue abaixo um exemplo de uso desse serviço no ASP.NET 5:

var config = new Configuration();  
config.Add(new MemoryConfigurationSource());  
config.Set("Producao", "false");  
string configItem = config.Get("Producao); // retorna false // ou  
string configItem2 = config["Producao"]; // retorna false  

Conclusão

Como pode-se observar o Request Pipeline para aplicações ASP.NET está mais leve, modularizado e foi totalmente reescrito, redesenhado e re-arquitetado. Essas mudanças nos beneficia de forma que nossas aplicações não precrisarão mais depender de códigos, implementações e declarações que estão em pacotes que não estamos utilizando, de fato. Outro ponto que precisa ser ressaltado é a implementação de serviços e middlewares. Através dessas estruturas podemos extender os mecanismos Http, Serviços e novos Middlewares e com isso usufruir da modularização que injeção de depenência nativa do ASP.NET 5 nos trás de melhor.

Referências:

ASP.NET 5 Documentation – https://docs.asp.net/en/latest

Github Asp.Net – https://github.com/aspnet

Comments