O Futuro do ASP.NET vNext – MVC 6

Publicado em por

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.

ASP.NET vNext

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.

  • É um “standart” uma especificação.
  • Não existe exatamente como código ou componente.
  • É a descrição de como idealmente o comportamento de sua implementação deve funcionar.

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

  • Windows 8 ou Windows Server 2012
  • .NET Framework 4.5.1
  • Visual Studio 2012 ou 2013

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 😉

78 pensou em “O Futuro do ASP.NET vNext – MVC 6”

  2. Quase chorei de emoção hahaha.
    Edu parabéns, grande post, novidades extremas, e para nós desenvolvedores uma verdadeira mão na roda.
    Agora com as atualizações constantes tornam os problemas de migração quase nulos, pois, não são grandes as mudanças.

    Tudo isso se deu após a microsoft tornar seus códigos open source não é Edu?

    Estou construindo um blog também e vou atras de informações para postar lá a respeito.

    Edu parabéns novamente, forte abraço.

    • Fala Fernando, obrigado!!!

      A Microsoft mudou o pensamento, saiu da idade da pedra e deu ao ASP.NET e muitas outras tecnologias aquilo que precisava!

      O OWIN foi o grande passo e sim, após se tornar open-source muita coisa mudou.

      Abraços!

  3. Eduardo, tudo bem?

    Sensacional!!! Finalmente sinto que estamos indo no caminho certo.

    Porém, sou muito cético com relação a adoção de novas tecnologias por empresas aqui em nosso país.

    Sinto nos últimos anos a Microsoft mais do que nunca levando as novidades aos clientes. Porém, continua enxergando resistência por parte das empresas. Exemplo disso são as diversas empresas que possuem aplicações rodando no Framework 2.0, 3.5!

    Você acha que isso vai mudar agora? Qual seu feeling?

    Abs!!

    • Olá Felipe!

      Eu penso assim, aqui no Brasil principalmente tudo é encarado como custo, pq nossos gestores não sabem fazer conta, mas quando a dor é insuportável ai alguma coisa tende a mudar.

      Nós precisamos é contaminar o máximo dos desenvolvedores parados no tempo para ajudarmos o movimento pró mudanças. Hoje em dia tem muita gente acomodada com seu WebForms. Hoje em dia é nuvem, é performance, é sistema que não pode parar um segundo. A solução dos problemas está ai, tem que abraçar.

      Acredito que a maturidade vai chegar cada vez mais rápido 🙂

      Abs!

  10. Sensacional, se o time do ASP.NET (auxiliado pela comunidade agora xD) de fato entregar oque o Hanselman prometeu, teremos uma plataforma com o poder, performance e escalabilidade de uma linguagem compilada e, ao mesmo tempo a flexibilidade e facilidade de uma linguagem dinâmica nível Ruby ou Node, mais uma vez, sensacional 🙂

  11. Olá, sou estudante de Tecnologia em Sistemas para Internet e estou muito feliz de ver essas mudanças para melhor acontecerem justamente quando começo a aprender sobre o padrão ASP.Net MVC. O post sanou minhas dúvidas, obrigado por compartilhar o conhecimento!

    • Olá Jhonny,

      Ótimo momento para entrar na tecnologia… Aproveite, acesso fácil à informação, comunidade ativa, é só mergulhar!

      Obrigado e Abs!

  12. Pingback: A próxima geração do .NET – ASP.NET vNext | Fernando Mamprin

  14. Show Eduardo. Obrigado pelas informações.

    Tira uma duvida minha.

    Atualmente trabalho com desenvolvimento em MVC 4, estava pensando em pegar desde o webforms ate chegar onde esta. Com essa mudança é melhor fazer isso ou começar do mvc 5 direto?

    Vlw.

    • Olá Lucas!

      Eu não me daria ao trabalho de conhecer um paradigma antigo, não vai lhe fornecer benefício nenhum, toca aprender MVC 5 mesmo e começa a ver sobre vNext tbm.

      Abs!

  15. Parabens pelo Post!

    Estamos criando um novo projeto aqui na empresa e vamos usar tudo novo “Empresa aqui no Canada, se fosse uma empresa brasileira imadura, certamente iria pelo Web forms ;(”

    Muito obrigado pelo post! Verei o video hoje a noite!

  17. Fala Eduardo, obrigado ai pelos posts… eu sou iniciante e estou tentando ver as diferenças usando o iis local… não hospedo a aplicação.

    teria alguma materia… ou artigo, algo assim, para me dar uma luz?

    obrigado ai… espero que um dia eu domine isso ai.. rs..

    • Olá Renato!

      A principal diferença é se vc usa IIS vc obtém proveito de toda a ferramenta, porém fica preso ao Windows e ao próprio IIS, no caso de SelfHosting você pode utilizar qualquer plataforma, Win/Mac/Linux além de abrir inúmeras possíveis customizações no seu processo de hosting.

      As diferenças são inúmeras, sugiro que leia bastante sobre o project Katana, Helios e ASP.NET vNext.

      Abs!

  18. E sobre a migração dos projetos MVC4 ou MVC5 para o vNext, como será? Muito trabalhosa será?
    Irei iniciar um projeto novo, e fico com medo de iniciar já que logo teremos a versão vnext completa

    • A migração deve ser facilitada mas com certeza haverá impactos, depende do como vc ainda usa o MVC, se depende de sessions ou HttpContexts por ex, mais mudanças, se usas da melhor forma, terás menos.

      Vai demorar um pouco, pode botar uns 6 meses pelas minhas estimativas…

      • Olá Eduardo,

        O que seria essa melhor forma? Não vejo uma aplicação Web sem fazer uso de sessions.

        Qual seria o equivalente de sessions e httpcontexts nesse cenário sugerido?

        Abraços e parabéns pelo post!

        • Douglas, obrigado!

          Sessions são malignas, livre-se delas!

          Você pode utilizar Claims, cache, cookies, tudo isso é melhor que session, depende para o que vc quer armazenar existe uma alternativa mais indicada.

          Vou preparar um post sobre isso!

          Abs!

  19. Parabéns pelo excelente artigo!
    Eu estava desanimado com o forte acoplamento de toda a stack microsoft, estava disposto a abrir mão mesmo sendo MCPD e ir para as novas tendências como Rails. Mas essas novidades trouxeram um novo ânimo, acredito que o Visual Studio é tão bom e produtivo, que mesmo podendo desenvolver usando o Sublime, ainda opto pelo VS por não existir no mundo uma IDE tão produtiva.

    Uma dúvida Edu, você aconselha já testar o vNext em cases reais? fiz isso com o MVC3 e o EF4.1 e não deu problemas, mas dessa vez são mudanças muito radicais!

    • Olá Pedro! Muito obrigado!

      A recomendação é geral, não utilize nenhuma versão do vNext em produção é um Alpha, não tem garantia nenhuma, e nem suporte.

      Assim que o vNext (MVC 6, EF7, SignalR e WebAPI 3) for liberado para uso eu repassarei o anuncio.

      Abraços.

  20. E aeee Eduardo..

    Show de bola esse artigo..

    Vou procurar saber mais sobre o vNext..
    Pelo jeito as novidades vão fazer grande diferença para o futuro dos desenvolvedores..

    Abraços!!!

  22. “Coisa linda de DEUS!” (Victor Cavalcante)…tive que copiar kkk…
    Incrível !!!! pena que acabei de tirar Certificação 70-486 ASP.NET MVC 4 e os cara me manda o 6… bora estudar agora essa nova plataforma… estou super empolgado para começar a desenvolver com ela , e Eduardo Pires parabéns pelo POST super esclarecedor.

    • Obrigado Humberto!

      Vc conhece MVC 4 ótimo, não muda muito, o que muda são “por baixo dos panos”. Com certeza vale muito a pena se aprofundar nisso.

      Abraços.

  24. Ótima matéria Eduardo, parabéns !
    Ainda mais para dar o norte para nóis programadores do Asp.Net classico, por que pelo que estou vendo o nosso asp classico agora é o asp.net web forms hahahhaahah.

    O que você acha do web forms ? Acha que logo a Microsoft vai deixar de suportar e vai acabar morrendo e virando tecnologia legada igual o asp 3 ? Estou com alguns projetos novos no trampo, que estão na fila para entrar como web forms, mas depois que comecei a ler sua matéria sobre o ASP MVC estou com receio de logo o suporte ao Web Forms acabar.

    Abraço !

    • Olá Francisco, obrigado pelo feedback.

      Olha, em relação a ASP quem está na versão clássica ainda está no mínimo 4 versões atrasado… A parte boa é que dá para pular direto para o MVC.
      Dica de amigo, fuja de web forms. Não que ele vá morrer, vai haver suporte ainda, porém na nova versão do ASP.NET vNext ele não existe.

      Simplesmente não existe mais motivos para usar web forms, ainda mais que vocês não entraram em ASP.NET então ótimo, da-lhe MVC!

      Abraços.

  26. Muito bom o post! Saberia dizer se isto também afetaria o desenvolvimento para Sharepoint?

    • Obrigado pelo feedback Anderson,

      Não sei lhe dizer, no primeiro momento penso que não, pois não soube nada a respeito. Existe a integração com o ASP.NET porém a mudança continua do mesmo lado.

      Abs!

  29. Primeramente parabens pelo artigo um dos melhores que eu ja vi!

    Agora sobre o vNext, caramba quanta evolução, fico muito feliz em ver como a Microsoft esta mudando o jeito de pensar, nestas plataformas, já programei em Ruby on Rails, e sempre senti que a comunidade de Rails é bem forte. A Microsoft agora esta investindo muito nisto, e esta dando muito certo isto.

  30. Parabéns pelo artigo!
    Estou estudando ASP.NET MVC agora e parti direto para o Vnext. Me tire uma dúvida: Alguma chance de que os arquivos que serão publicados para o servidor sejam compilados, ou criptografador? Deixar todo o código fonte solto no servidor me assusta um pouco. Trabalho com uma solução que é a mesma para muitos cliente. Se o cliente resolver piratear tá muito fácil assim.

    • Olá Marcelo, obrigado pelo feedback!

      Pode compilar sim, o método tradicional ainda deverá ser mantido (eu falo deverá, pois ainda a versão oficial não foi lançada, estou respondendo com o que temos hoje).

      Mas fique tranquilo, pois sua preocupação é bem pertinente, com certeza haverá cobertura para isso.

      Abs!

  33. Olá parabéns gostei muito do vídeo,

    Para um projeto grande você acha que devemos esperar a versão final do VS 2015 ? ou começaria no VS 2013 MVC 5 ?

    Não tem data de previsão na microsoft, quando você acha que iram lançar ?

    Obrigado

    • Fala José!

      Muito obrigado pelo feedback!
      Não tem previsão ainda, mas podemos esperar até meio desse ano.

      De qualquer forma essa tecnologia atual é recomendada sim.

      Abs!

  34. Olá Eduardo parabéns pela matéria.
    Tenho uma dúvida.
    Temos um e-commerce que está em produção utilizando EF 6 com Webforms e gostaria de sua opinião, a pergunta é;
    Fazer a migração por partes da aplicação para o MVC 5 até estar 100% MVC ou dá um New Project e começa do zero em MVC e aproveita DAL em EF 6 ?

    Obrigado.

    • Olá,

      Tenho uma experiência com esse tipo de migração e posso lhe dizer que realizar a migração por partes, disponibilizando o mesmo em forma de beta para o cliente final é uma boa opção. Além de realizar um “teste em produção” do seu projeto você pode pedir a opinião dos clientes finais e assim seu site iria ficar cada vez mais adaptado ao público. Fazer o mesmo projeto até terminar 100% reaproveitando o DAL também é uma opção viável, mas que pode não ser muito interessante se mensurarmos o tamanho atual do mesmo.

  35. Olá Eduardo, ótima matéria!!!

    Uma questão: Com a nova onda AngularJS para aplicações Web, você acha que o vNext e AngularJS podem coexistir, ou será necessário optar entre um ou outro?

    Atualmente não vejo muito entusiasmo nos desenvolvedores que estão migrando para Angular em mesclar AjS com Asp. NET MVC.

    Qual sua opnião sobre isso?

  36. Posso fazer uma aplicação no VS Community e comercializar?

    Tudo o que eu faço no Professional eu faço no community no vNext?

  38. Pingback: ASP.NET MVC vs ASP.NET Web Forms || asp.net{cast} S01EP06 – aspnet{cast}

Os comentários estão fechados.