Você já parou para pensar no futuro do ASP.NET daqui alguns anos? O futuro chegou e foi anunciado hoje! Quem acompanha já deve ter reparado no termo OWIN ou lido algo sobre Project Katana / Helios, etc. Hoje uma página de 12 anos foi virada para um novo tempo. Conheça aqui o ASP.NET do Futuro.
O artigo é extenso e foi utilizada uma linha cronológica para apresentar todo o processo da evolução do ASP.NET.
Um breve olhar no passado do ASP.NET
O ASP.NET desde seu lançamento foi criado originalmente para dois publicos em específico:
- Desenvolvedores ASP Clássico
- Desenvolvedores Windows
O resultado não podia ser diferente, a primeira versão do ASP.NET conhecida como Web Forms é uma combinação do desenvolvimento Windows (componentes ricos, desenvolvimento rápido, arrastar e soltar) com a plataforma Web.
Para suportar toda a riqueza de funcionalidades do Web Forms foi necessário implementar muitas classes no .Net Framework, este que por sua vez é mono-bloco, ou seja, muitas funcionalidades estão acopladas em um único assembly, o System.Web (núcleo de objetos HTTP e o próprio framework de WebForms).
Devido a isso o ASP.NET sempre esteve fortemente acoplado ao .Net Framework e dependente de um específico Web host, o Internet Information Services (IIS).
O ASP.NET Web Forms foi a única forma conhecida de ASP.NET durante muitos anos.
Evolução da plataforma ASP.NET e suas dificuldades
Quem desevolve com ASP.NET desde seus primórdios sabe que antigamente era necessário muito tempo (ordem de anos) para que fosse liberada uma nova versão do ASP.NET, e isso nunca foi bom, pois as outras plataformas avançavam muito mais rápido, muitas novas tecnologias surgiam e o ASP.NET precisava se manter competitivo para atender as novas necessidades.
O grande ponto é que o ASP.NET sempre precisou crescer numa velocidade muito maior do que o .NET Framework cresce, porém ambos sempre estiveram muito acoplados através do System.Web que faz parte do .NET Framework, ou seja, muitas vezes para a implementação de um simples recurso no ASP.NET poderia haver algum impacto no .NET Framework e que por sua vez poderia demorar anos até receber a atualização para suporte a tal recurso.
Além do problema do alto acoplamento, por mais que o ASP.NET e o .NET Framework recebessem novas funcionalidades a adoção era demorada demais, o motivo maior é que as empresas não atualizam o .NET Framework de imediato, é necessário todo um processo de validação, revisão de plataforma, homologação e etc, até hoje em 2014 boa parte dos servidores de hospedagem não trabalham com a versão 4.5 do .NET Framework.
O desenvolvedor muitas vezes precisava esperar anos e anos para utilizar um novo recurso da plataforma.
Como resolver isso?
Solução número 1 – Separar
O ASP.NET MVC foi introduzido em 2007-2008 sendo que é distribuido separadamente do ASP.NET clássico, ou seja, isso aumentou a velocidade da entrega de novidades para o ASP.NET as versões do MVC foram entregues como complemento através de novas versões do Visual Studio, via NuGet ou via o aspnetwebstack do ASP.NET, onde é possível utilizar as versões dos build noturnos, código ASP.NET que foi desenvolvido a menos de 24 horas.
Quem desenvolve com ASP.NET há algum tempo vem nos últimos anos presenciando muitas mudanças, além do ASP.NET MVC ainda vieram o Razor, Web API, SignalR, SPA, ASP.NET Identity e todos foram distribuidos separadamente.
Existe a sensação que a Microsoft esta com grande foco em evoluir a plataforma ASP.NET, atualmente em média de a cada seis meses é liberada uma nova versão ou novas funcionalidades / tecnologias agregadas ao ASP.NET. para que ela se mantenha altamente competitiva entre as demais de mercado, e isso já é fato, analisando a produtividade em utilizar ASP.NET com Visual Studio e todas as vantagens que o ASP.NET oferece, fica muito claro o motivo pelo qual cada vez mais empresas e profissionais adotam o ASP.NET como plataforma oficial de desenvolvimento Web.
Para um maior detalhamento assista meu vídeo da palestra Novidades do ASP.NET MVC 5.x
Mesmo com a separação do ASP.NET MVC em relação ao ASP.NET clássico ainda existe uma forte dependência com o System.Web e por sua vez a necessidade de utilizar IIS como única opção de Host.
Quando iniciamos um projeto em ASP.NET MVC, por mais que seja um simples “Olá Mundo!” pode ser que não tenha reparado, mas as dependências com o System.Web estão lá, o System.Web provê suporte a envio de e-mail, controles do Web Forms, sessão e etc… Você não precisa disso? Não importa, vai ter que usar, pois se tirar o System.Web de suas referências seu projeto simplesmente não vai funcionar.
O outro problema é que por mais que o ASP.NET MVC tenha capacidade de ser uma plataforma leve e performática ela sofre uma boa perda devido ao fardo do System.Web que precisa estar presente para fazer o pipeline com o IIS.
Solução número 2 – Quebrar as dependências.
Em 2012-2013 surgiram o ASP.NET SignalR e ASP.NET WebAPI, estes dois componentes ASP.NET não possuem nenhuma dependência com o System.Web, foram desenvolvidos para levar o ASP.NET a um novo patamar, a da independência de plataforma, pois tanto o SignalR como o WebAPI podem rodar em ambientes não Microsoft (Linux/OSx).
Essa foi a quebra da independência ao legado do System.Web, mas até então apenas estes dois componentes podiam rodar independente do IIS, System.Web e Windows.
Foi neste momento que a comunidade técnica conheceu o OWIN.
Apresentando o OWIN
Desde meados de 2009 o ASP.NET se tornou open source e devido a este fato a comunidade técnica pode se juntar ao time de engenheiros da Microsoft para conhecer e implementar melhorias e sugestões. Foram os próprios membros da comunidade técnica que baseando-se no design do Node.js e do Rack da comunidade Ruby, criaram uma especificação chamada OWIN (Open Web Interface for .NET).
O OWIN define uma interface padrão entre servidores Web e aplicações .NET.
O objetivo da interface OWIN é desacoplar o servidor e a aplicação, incentivar a criação de módulos simples para o desenvolvimento em ASP.NET, e, por ser um padrão aberto, estimular o ecossistema open source de ferramentas .NET de desenvolvimento Web.
Resumidamente o OWIN é uma camada de abstração entre o server e a aplicação.
O objetivo do OWIN é que novos componentes possam ser facilmente desenvolvidos e consumidos, porém de forma agnostica, ou seja, que possam rodar em outras plataformas como Unix (Mac/Linux) e que possam ser portados de uma plataforma para outra sem necessidade de recompilação.
Katana Project
É uma implementação Microsoft da especificação OWIN no ASP.NET.
A Microsoft apostou na proposta do OWIN e o implementou nos projetos ASP.NET SignalR e ASP.NET WebAPI, essa implementação recebe o nome de Katana Project. Mais tarde o ASP.NET Identity surgiu implementando bibliotecas do Katana Project também.
Além da Microsoft, outros projetos implementam OWIN como NancyFx, FubuMVC, NOWIN etc.
Confira no vídeo abaixo mais detalhes sobre arquitetura OWIN – Katana Project.
Project Helios
A implementação do OWIN atrávés do Katana Project proporcionou a criação de componentes ASP.NET muito mais leves, performáticos, independentes de plataforma e SelfHost, porém caso seja necessário contar com alguns recursos que o Host ASP.NET clássico (IIS) provê, tudo isso fica a cargo do desenvolvedor da aplicação.
O IIS apesar de trabalhar apenas no pipeline do ASP.NET clássico (System.Web) possui uma série de benefícios que nem sempre podem ser deixadas de lado:
- IIS lida com gerenciamento da vida útil aplicação.
- Ele pode suspender (em vez de encerrar) processos que estão ociosos para ajudar a equilibrar os recursos disponíveis do sistema.
- IIS oferece um cache de modo de usuário embutido e pode comprimir automaticamente o conteúdo dos responses se for o caso.
- IIS suporta filtragem de requests e transient worker process identities.
- Mais de 10 anos de implementações e melhorias de segurança.
- No cenário do Self Host você é responsável por muitas das responsabilidades que o IIS toma conta, além disso ele já existe para isso por que não utilizá-lo?
São esses os motivadores do Project Helios, porém devido à necessidade do IIS trabalhar no pipeline no System.Web muita performance seria perdida, por isso o Project Helios trabalha apenas com o “Core” do IIS o utilizando como uma espécie de API, o “Core” do IIS é extremamente rápido e poderoso, pois disponibiliza apenas as suas funcionalidades sem depender do pipeline do ASP.NET clássico (System.Web).
O Project Helios oferece suporte aos projetos desenvolvidos em Katana (OWIN), porém não é dependente dele para ser utilizado, é possível desenvolver uma aplicação baseada apenas em Project Helios que rodará apenas no padrão IIS e não terá opções de SelfHost e multiplataforma, em uma arquitetura de aplicações para Windows pode ser muito vantajoso, pois é pelo menos 96% mais rápido que o ASP.NET clássico. Na demo exibida no vídeo abaixo o resultado foi quase 6x mais rápido utilizando Helios.
Requerimentos mínimos para utilização do Project Helios
Resumo Cronológico
O ASP.NET desde seu lançamento sofreu com a grande demora de liberações de novas versões, algumas plataformas novas surgiram e passaram a frente devido uma evolução mais rápida, com a implementação do ASP.NET MVC esse tempo de liberações diminuiu, porém a plataforma ainda era limitada em relação às outras devido a herança historica do Web Forms (System.Web) em seu pipeline, impedindo que algumas melhorias fossem implementadas.
Com o surgimento do OWIN e os projetos Katana e Helios novas frentes se abriram e a engenharia do time de ASP.NET começou a trabalhar em uma nova versão, a maior e melhor mudança do ASP.NET em todo o seu período de existência, hoje o futuro chegou.
ASP.NET vNext – MVC 6
Foi anunciado dia 13/05 durante uma sessão do TechEd North America 2014 a nova versão do ASP.NET chamada vNext e que vai mudar tudo o que você sabe sobre ASP.NET, é um novo paradigma, um novo stack, tudo que os desenvolvedores Web mais maduros sabiam que era possível e torciam para que um dia fosse feito.
Todos os nomes que vimos como Katana, Helios e ASP.NET vNext provavelmente irão mudar, são nomes dados para projetos em execução, na versão final ganham um outro nome mais familiar.
Você desenvolvedor ASP.NET veterano, levante agora da cadeira e aplauda, você está diante a maior mudança do ASP.NET em seus 12 anos de existência. Você iniciante ASP.NET nem pense em Web Forms, caia direto nesse stack e comece a entender tudo como funciona daqui pra frente.
O que mudou
- Web Pages, MVC, Web API agora é uma coisa só, chamado de MVC 6
- Novas versões otimizadas para nuvem do MVC 6, SignalR 3 e Entity Framework 7
- Acabou a dependência do System.Web, MVC 6 agora é um middleware, leve e performático, agora apenas o Web Forms depende (para sempre) do System.Web.
- Versões otimizadas para nuvem do MVC, Web API, Web Pages, SignalR e Entity Framework.
- Maior portabilidade, não existe dependência de assemblies do GAC facilitando o deploy em nuvem e em ambientes não Windows (Linux/OSx/Etc)
- Possibilidade de hospedar sua aplicação no IIS ou em um processo self hosted
- Injeção de dependência nativa dentro do framework
- Suporte ao legado do Web Forms, MVC 5, Web API 2, Web Page 3 , SignalR 2 e EF 6
- Deploy do runtime e framework com a sua aplicação, possibilitando rodar lado a lado 2 versões diferentes do framework
- Arquivo project.json irá integrar o arquivo de projeto (.csproj), o packages.config e o Nuget specifications (nuspec);
- Suporte ao Rosyln, ou seja, não precisa mais parar a aplicação para alterar uma classe, basta alterar salvar e dar F5 no browser, pronto! Muita produtividade!
- Tudo é entrege via NuGet até o runtime!
- Mais open source que nunca (foi para o GitHub) e faz parte do .Net Foundation.
- Baixissimo consumo de memória
- Completamente Multiplataforma!!! Rode ASP.NET onde quiser!
Veja alguns screenshots
Assista ao vídeo da palestra – O Futuro do ASP.NET + Novidades do vNext – MVC 6
Acompanhe os slides da palestra
Assista esse vídeo exibindo como rodar a nova versão do ASP.NET vNext – MVC 6
Bons estudos!!!
Referências
Vamos continuar a troca de conhecimentos, escreva seu comentário abaixo 😉
