ASP.NET 5

Introdução

Passados mais epende 13 anos sobre o lançamento do ASP.NET, a Microsoft decidiu começar do zero… ou quase. Com efeito, com o ASP.NET 5 vamos assistir a uma revolução no desenvolvimento para a web, que irá levar a uma reaprendizagem de todo o processo de desenvolvimento.

Um Bocado de História

ASP.NET: evoluçãoQuando o ASP.NET foi lançado, em 2002, a designação Web Forms era quase um pleonasmo: basicamente, não havia outro modelo de desenvolvimento para a web na framework .NET. A ideia da Microsoft era reproduzir, tanto quanto possível, em ambiente web o modelo de desenvolvimento já existente para o Windows:

  • Designer visual de páginas e controlos (drag and drop);
  • Modelo de eventos;
  • Manutenção automática de estado.

Em grande parte, estes objectivos foram bem-sucedidos: era possível a uma pessoa com relativamente poucos conhecimentos de desenvolvimento produzir aplicações ricas com controlos visuais e acesso a dados de forma rápida. Muitos fabricantes de software começaram a produzir bibliotecas de controlos e frameworks de desenvolvimento sobre Web Forms, permitindo a construção facilitada de ricas interfaces gráficas com funcionalidades avançadas, quase ao nível do que é possível encontrar em aplicações Windows Forms e Windows Presentation Foundation (WPF). A boa integração dos vários produtos da Microsoft com o Visual Studio deixou muita gente satisfeita durante bastante tempo. O SharePoint, o servidor colaborativo “de bandeira” da Microsoft, usa Web Forms, pelo que quem desenvolve para SharePoint tem obrigatoriamente de conhecer a framework.

Algumas versões notáveis do ASP.NET:

  • 1.0: versão inicial (Visual Studio .NET, Visual Studio 2003);
  • 2: introdução do mecanismo de providers (fornecedores de funcionalidades); disponibilização das ASP.NET AJAX Extensions; adaptadores de CSS configuráveis (Visual Studio 2005);
  • 3.5: integração das ASP.NET AJAX Extensions; novos controlos ListView e DataPager; LinqDataSource e EntityDataSource; routing; disponibilização do modelo MVC (Visual Studio 2008);
  • 4.0: páginas assíncronas; integração dos controlos gráficos ASP.NET Chart Controls; transformações do Web.config; mais fornecedores de funcionalidades (codificação de respostas, cache); novo modelo de validação de pedidos; inclusão do jQuery e do Modernizr; suporte a Content Delivery Networks (CDNs); view state opcional por página e controlo; geração de identificadores no lado do cliente configurável; possibilidade de endereçar diferentes versões do .NET; geração de HTML optimizado; disponibilização do ASP.NET Dynamic Data (Visual Studio 2010);
  • 4.5: binding model para controlos de exibição e inserção de dados; empacotamento (bundling) e minificação integrada; optimizações na garbage collection; suporte a mais funcionalidades do HTML 5; suporte a WebSockets; integração da biblioteca Microsoft AntiXSS; integração do WebAPI; integração do SignalR; integração de formas de autenticação sociais, como Facebook, Twitter, etc (Visual Studio 2012, Visual Studio 2013).

Entretanto, sobre Web Forms foram sido construídas outras frameworks: XML Web Services e Web Services Enhancements (para a versão 1.0), ASP.NET AJAX Extensions (2), ASP.NET Provider Model (2), Dynamic Data (3.5), Routing (3.5), SignalR (4.5), para citar apenas algumas, e a própria base foi evoluindo, tornando-se mais extensível e completa, com um mecanismo que permite trocar grande parte das funcionalidades nativas. A versão mais recente é a 4.5.2.

Críticas ao Modelo Web Forms

Grande parte das críticas ao modelo Web Forms assenta essencialmente nos seguintes aspectos:

  • A web é complexa e o modelo Web Forms esconde essa complexidade (manutenção de estado, actualizações parciais, etc);
  • A utilização do designer visual para produzir funcionalidades conceptualmente complexas pode levar a uma má separação de código, onde a própria página chega a conter código SQL ou LINQ;
  • A existência do view state e a dependência que certos controlos têm dessa funcionalidade, que por vezes faz com que as páginas fiquem extremamente “pesadas”, contendo grandes quantidades de dados que, de forma invisível, atrasam a sua submissão;
  • A dependência de uma biblioteca JavaScript embutida para algumas das suas funcionalidades (ASP.NET AJAX Library);
  • A complexidade/pouca qualidade do código gerado automaticamente pelos seus controlos: até há bem pouco tempo estes geravam elementos TABLE e outro conteúdo HTML que actualmente é considerado má prática;
  • O modelo “same-page” por omissão leva a que uma só página contenha muita lógica, porque a página faz submissões para si própria e tem de considerar várias acções possíveis aquando do processamento dos eventos;
  • O ciclo de vida de uma página e dos seus controlos é complexo; há certas coisas que têm de ser feitas em (ou até) determinado evento e por vezes é difícil sincronizar as dependências entre os vários controlos e a própria página (“event hell”);
  • Monolítico e pesado; as novas versões apenas são distribuídas com a própria framework .NET, o que não acontece tão frequentemente como isso; além disso, para usar uma qualquer funcionalidade, temos de trazer várias dependências atrás;
  • Apesar da adição tardia de routing, as páginas Web Forms não são geralmente amigas de Search Engine Optimization (SEO), dependendo de URLs relativamente crípticos (ex: /Categorias.aspx?ID=b1aee664-aa95-44bb-a0c8-45a567b56919, por oposição a /Categoria/Smartphone).

ASP.NET MVC

ASP.NET MVC: versõesO modelo de desenvolvimento MVC foi lançado em 2009 com o objectivo de fornecer uma alternativa “oficial” a quem não gostasse do Web Forms. Como grandes vantagens, propunha:

  • A familiaridade de um design pattern, Model-View-Controller (MVC), usado noutras linguagens e frameworks de desenvolvimento para a web (Java, PHP);
  • Uma distinção clara entre as várias camadas de desenvolvimento, conducente a uma melhor separação de responsabilidades, que eventualmente poderá levar a código mais fácil de manter e evoluir;
  • O regresso ao HTTP e HTML: o programador passa a ter de considerar questões como os verbos HTTP, os URLs e a gerar ele próprio o HTML dos conteúdos, o que lhe dá mais controlo; a necessidade de produzir HTML levou a uma maior utilização de frameworks JavaScript;
  • O modelo de rotas leva a URLs mais “amigos” de REST e de SEO, tópicos “quentes” actualmente;
  • Mais facilidade em testar o código por meio de testes unitários;
  • A disponibilização de actualizações “out-of-band”, ou seja, não coincidentes com as actualizações da framework .NET, levando a que possam ser mais frequentes;
  • Elevada extensibilidade: abraçando conceitos modernos, tais como Dependency Injection (DI) e Inversion of Control (IoC), é possível substituir ou complementar grande parte dos seus mecanismos internos (validação, autenticação, autorização, logging, etc). Praticamente todas as funcionalidades são extensíveis.

O modelo MVC tornou-se muito popular. Apesar de ainda não poder rivalizar com o Web Forms nalguns aspectos – falta de designer visual, menor capacidade de reutilização de controlos – rapidamente se tornou a framework de escolha para muitos programadores com tecnologias Microsoft, descontentes com o modelo anterior. A própria Microsoft pareceu empurrar nessa direcção, incluindo até o apoio a projectos construídos sobre MVC, externos (Orchard, por exemplo) ou internos (Web API, Web Pages, Razor) e à especificação OWIN. Como prova dessa evolução, podemos ver que passou da versão 1, em 2009, para a versão 5 em 2013, com vários lançamentos pelo meio, estando actualmente na 5.2.3.

OWIN e Open Source

Numa tentativa de “democratizar” o ASP.NET, levando-o a outros sistemas operativos, juntamente com o resto da família .NET, a Microsoft libertou grande parte do código fonte como open source, sob o licenciamento Microsoft Public License (MS-PL). Adicionalmente, tem vindo a trabalhar numa especificação que define o fluxo de processamento de um pedido pelo servidor e como o código .NET se pode integrar com um servidor HTTP que não exclusivamente o IIS: é o standard Open Web Integration for .NET (OWIN). O problema é que OWIN, neste momento, não se integra verdadeiramente com Web Forms, embora seja possível usá-los em conjunto, de forma a suportar componentes que dependam de OWIN num cenário Web Forms, mas a framework Web Forms propriamente dita não o usa, ao contrário da MVC. Todo o desenvolvimento continua a assentar na velha pipeline ASP.NET e nas bibliotecas System.Web.DLL e System.Web.Extensions.DLL.

ASP.NET vNext

Na realidade o que temos em cima da mesa é não uma mas duas versões do ASP.NET:

  • 4.6: trata-se da evolução natural da versão actual do ASP.NET; inclui alguns melhoramentos em Web Forms e MVC e integra várias correcções de segurança entretanto lançadas;
  • 5: reescrita total do ASP.NET.

ASP.NET: Open .NET 2015Foquemo-nos no ASP.NET 5. Esta nova framework – pois é disto que estamos a falar – vai funcionar sobre o .NET 5. As suas principais características vão ser:

  • Totalmente open source sob a licença MIT; serão aceites contributos da comunidade, como já agora acontece;
  • Fim do modelo de desenvolvimento Web Forms; não será incluído com o ASP.NET 5 qualquer classe de suporte ao Web Forms;
  • C# e VB serão suportados, apesar de inicialmente a Microsoft ter anunciado que não existiria suporte inicial para VB;
  • Baseado em OWIN, sendo que a framework “natural” de desenvolvimento será MVC e Razor, mas será alojável em vários servidores, desde o IIS até o novo Kestrel, desenvolvido de raiz para Mac e Linux, passando por correr num processo .NET;
  • Por assentar em .NET 5, será implicitamente multi-plataforma, devendo correr em Windows, Mac e Linux, com suporte a versões limitadas do .NET (.NET Core CLR) a pensar na cloud, e podendo usar simultaneamente componentes de várias versões do .NET;
  • Será modular e suportado em packages NuGet: as novas versões serão distribuídas “out-of-band” sob a forma de packages NuGet; os programadores poderão escolher apenas aquelas de que necessitam; estas serão actualizadas em ciclos próprios, não ditados pelas novas versões da framework .NET;
  • Unificação dos APIs MVC, Web API e Web Pages, para evitar duplicação e fornecer um modelo coerente e coeso, sobre a pipeline especificada pelo OWIN;
  • Totalmente extensível por meio de DI e IoC, sendo fornecido um contentor próprio, que pode ser substituído por um mais tradicional (AutoFac, Unity, Ninject, etc);
  • Compilação dinâmica: deixa de ser necessário compilar o código explicitamente para experimentar as alterações, estas são detectadas automaticamente e compiladas pelo novo compilador Roslyn;
  • Novas ferramentas de linha de comandos com nomes estranhos: DNX, DNVM e DNU;
  • Integração com bibliotecas populares de desenvolvimento e gestão de dependências JavaScript, como Bower, Grunt, Gulp e NPM;
  • Gestão de dependências de bibliotecas .NET por meio de packages NuGet e suas versões em ficheiros JSON;
  • Suporte ao HTTP 2.0, quando a correr sobre o Windows 10 ou superior.

Reconhecendo os problemas actuais – código monolítico, muito agarrado e com muitas dependências, obrigatoriedade de respeitar os ciclos mais lentos de lançamento da framework .NET, grande disparidade e duplicação de funcionalidades entre o MVC, Web API e Web Pages, a Microsoft decidiu começar de raiz e reescrever a framework a partir do zero. O novo ambiente de desenvolvimento integrado (IDE) será o Visual Studio 2015 e irá suportar quer a nova framework baseada em .NET 5 quer as anteriores.