Desde que a Microsoft anuncioua possibilidade do ASP.NET ser Cross-Plataform (Multi-Plataforma), foi gerada uma euforia e ansiedade na comunidade, todosqueriamver essa novidade, além de muitas dúvidas por alguns céticos. Pois bem, hoje esses rumores não são mais conversas de corredores, é uma realidade que o ASP.NET é sim Cross-Plataform (Multi-Plataforma).

Este artigo que está iniciando hoje é uma série que tratrá as novidades do ASP.NET 5, apresentando os novos recursos e as mudanças que foram introduzidas na plataforma possibilitando uma escalabilidade e flexibilidade que nos mostra, de fato, que o céu é o limite.

Hoje faremos uma introdução sobre os vários recursos, mudanças, ferramentas open-source que foram incorporados, além de apresentar algumasfuncionalidades que focamem reuso, aumento de produtividade, tanto para o desenvolvedor como para o web designer.

ASP.NET rodando em OSX e Linux

Para os que ainda são céticos ou não querem acreditar e afins, é isso mesmo que eu estou postando e o que a comunidade em peso está falando por ai: Microsoft ASP.NET Cross-Plataform. Hoje a Microsoft em peso entende que rodar única e exclusivamente em uma única plataforma não iria ampliar seus horizontes. Como assim? – Mas ela é uma dos grandes players de mercado, mesmo atuando apenas na plataforma black-box dela. Porque mudar no que está ganhando?

Para responder a essa pergunta eu repasso uma outra como ponto de análise: Quantos Macbook Pro, Macbook Air, computadores rodando Linux você encontra em vários congressos de desenvolvimento, web designer e programadores front-end ? Já parou para analisar isso? A Microsoft e o time dela SIM!

Mediante essa análise de mercado e, obviamente, querendo abarcar o mercado de apps como serviço a Microsoft precisou ampliar seus horizontes, como? Abrindo suas portas para que a comunidade pudesse contribuir com excelentes e revolucionárias idéias, e para isso é perciso permear nas maiores plataformas de S.O (Sistema Operacional) que temos hoje no mercado OSX e Linux, e não mais ficar no Windows.

Para atender a necessidade do ASP.NET rodar em um cenário cross-plataforma, temos dois core de ambientes, conforme listados e descritos abaixo:

  • .NET Core- Essa é a opção de Target que torna sua aplicação modular e cross-platform. A versão do core chamase coreclr. Essa versão você pode acompanhar as novidades através do Github Quando sua aplicação for marcada com essa opção, isso trará algumas vantagens, listadas abaixo: - A aplicação quando marcada com essa opção, é distribuida com a versão do runtime core que foi marcada no projeto. Isso gera uma interdependência da versão do Framework que está instalado no host que vai executar sua aplicação, ou seja, o host pode estar com uma versão 1.0.0-RTM e sua aplicação 1.0.0-beta. Outro benefício dessa modalidade é liberdade de atualização da versão do framework ou de outras aplicações que estão rodando naquele mesmo host, sem afetar a funcionalidade da sua aplicação, que pode estar rodando com uma versão beta (para testes) do core.
  • Utilizando essa opção de para fazer o deploy da sua aplicação, você poderá ter liberdade e sofrer menos impacto no que diz respeito a atualização de outras aplicações ou mesmo do Host. Isso faz o seu sistema utilizar só e somente só funcionalidades que são necessárias para a aplicação funcionar. O tempo de implementação, testes e deploy é menor e menos impactante.
  • Definitivamente, agora sua aplicação é cross-plataform. Ou seja, tanto faz o código do projeto. Ele vai rodar em OSX, Linux e, obviamente, Windows.
  • .NET Framework- Esta é a versão versão mais completa, é isso mesmo. Ainda que a versão core-clr seja o core do ASP.NET 5, ela é um subset de funcionalidades do .NET Framework. Então, eu recomendo MUITO que você leia a documentação do CoreCLR antes de mudar o target de seu projeto. Em caso de querer atualizar seu sistema de framework, sem ter grandes impactos, e manter as funcionalidades compativeis, recomendo que atualizem para a versão do framework 4.5.2 ou mais atuais.

Morte ao WebForms

*Muitos de nós desenvolvemos há muitos anos, muitas aplicações web utilizando o Web Forms. E digo mais, muitas aplicações web que hoje ainda rodam por ai utilizando esse tipo de plataforma. Mas chegou a hora dela de dizer-nos: Adeus.

Mas não chorem, amantes de aplicações .NET Web que ainda utilizam essa forma de desenvolvimento web. O Web Forms morrem de fato, mas nem tanto. Ainda que você ou seu projeto ou sua empresa mantenha o desejo e o prazer em desenvolver sistemas usando esse tipo de aplicação, vocês serão beneficiados, mas em partes! E qual seria a parte ruim de continuar utilizando Web Forms? Infelizmente, esse esse modo de desenvolvimento, não fará uso dos benefícios do ASP.NET 5. Então, se você não quiser sentir-se deixado pra trás, até porque a história caminha pra frente, chegou a hora de mudanças de: Paradigmas e Conceitos, ou seja, SAIA DA SUA ZONA DE CONFORTO, isso será muito prazeiroso e benéfico para a saúde dos seus projetos e carreira.

Morte ao Visual Basic?

Essa foi a notícia que veiculou por algum tempo nas redes e de fato foi publicada pela Microsoft. Isso se deu devido ao foco que foi desprendido em toda a reestruturação e adequação do core do .net framework em ser publicado para rodar cross-plataform. E com isso, eles noticiaram que essas mudanças não contemplariam o VB e que ele não seria mais suportado dentro dessas novas versões.

Essa afirmação por parte dos engenheiros da Microsoft, repercurtiu em toda a comunidade de Vbistas, e com isso, foi reinvindicado que ele voltasse. Pois bem amantes do VB, ele voltou! E mais, ele também será suportado pelo novo .NET Core Framework. Para maiores informações sobre essa nóticia, você pode ler aqui.

Novidades no uso de TagHelpers

Essa é uma mudança que agrada a gregos e troianos, dentro do meu ponto de vista. O temos de mudança aqui? Muitos dos que desenvolve aplicações asp.net utilizando o mvc já conhece e está cansado de escrever as famosas tags helpers: @Html.xxxxx, como segue a imagem abaixo:

NewTagHelper

É assim que muitos de nós desenvolvemos muitas aplicações web por alguns anos. Só que isso mudou um pouco e pra melhor J. Agora os web designers ficarão muito felizes em desenvolver uma interface e trabalhar com binds muito mais intuitivos e claros para eles. Abaixo segue uma imagem mostrando como podemos escrever o mesmo formulário acima, com as novas TagHelpers incluidas no ASP.NET 5:

NewTagHelper2

Além disso, você pode observar que as tags são 100% vinculadas ao model referenciado no inicio da página. O De-Para das tags apresentadas acima segue a tabela abaixo:

**ASP.NET 4.5.2 (Razor)****ASP.NET 5 (Modelo Unificado)**
@Html.BeginForm
@Html.LabelFor
@Html.TextBoxFor
@Html.ValidationSummary
**Unificação do MVC Controller com WebApi Controller**

*Essa é foi muito bem vinda. Mas do que se trata essa unificação? Bom, vamos explicar como funcionava antes. Antes nós tinhamos uma classe base no modelo ASP.NET MVC chamada Controller e uma outra classe base para o desenvolvimento utilizando WebApi chamada ApiController, onde nenhuma dessas classes se conversavam, ou seja, uma vez o seu controller assumisse a postura de um Controller MVC ele teria que seguir até o final do projeto sendo um Controller MVC, e assim dar-se esse comportamento também para os controllers que eram do tipo ApiController. E agora? Agora isso terminou de acabar J.

Agora no MVC 6, todos os controllers retornam um IActionResult. O que isso tem de bom? Tanto um controller MVC quando um controler WebApi retornaram o mesmo tipo, ou seja, o mesmo Controller pode retornar ora uma View ora uma lista de dados, por exemplo. Tanto o retorno das Action dos Controllers quanto as rotas, são as mesmas para ambos os controllers MVC ou WebApi, o que pode ser utilizado é rotas por convenção ou rotas por atributos ([Route(“api/pet”)]) que essa rota será aplicada para todas as actions do controller.

AngularJS incluido como templates client-side

O AngularJS é um dos framework MVVM bem difundidos na comunidade de desenvolvedores front-end e briga diretamente com alguns grandes players de frameworks javascript para front-end, como: KnockoutJS, BackboneJS, EmberJS, dentre muitos outros. Mas o AngularJS vem ganhando muita atenção dessa comunidade que não para de crescer e injetar novidades e modernidades as aplicações web. Visualizando essas tendências, a Microsoft e o time de ASP.NET decidiram intruduzir os templates do AngularJS dentro do Visual Studio, segue uma imagem demonstrando esses templates:

AngularJS-ASPNET5

View Components

*Mais uma vez vou retomar um pouco do passado para mostrar mais uma novidade e benefícios que o MVC 6 e o ASP.NET 5 trouxe como fator de produtividade e reuso para o nosso dia a dia de desenvolvedores web J. Quantos de vocês já utilizaram o Html Helper @Html.Action para chamar sub-controllers no lado servidor para renderizar alguma informação ou parte de um website? OU até mesmo implementou EditorTemplates que tanto nos salvaram o retrabalho de recodificar várias e várias vezes a mesma porção de código por toda a aplicação? Mais uma funcionalidade que é removida! Ok, mas o que temos de tão excepcional que justifica retirar algo tão simples quanto o @Html.Action ou @Html.Editor? Eu falo pra vocês: View Components.

Agora podemos construir componentes que são muito mais flexiveis, mais fáceis de escalar e aumenta o nosso poder de reusabilidade nos sistemas web que vamos desenvolver daqui pra frente. Segue uma pequena implementação de uma ViewComponent para:

 [ViewComponent(Name = "DropdownListUF")] public class UFDropdownListViewComponent : ViewComponent { private Lazy<List<UF>> _listUF = new Lazy<List<UF>>(() => new List<UF>()); public UFDropdownListViewComponent() { _listUF.Value.Add(new UF("Pernambuco", "PE")); _listUF.Value.Add(new UF("Distrito Federal", "DF")); _listUF.Value.Add(new UF("São Paulo", "SP")); } public IViewComponentResult Invoke() { return View(BuildDropdownlistItems()); } private IEnumerable<SelectListItem> BuildDropdownlistItems() { List<SelectListItem> ufList = new List<SelectListItem>(); _listUF.Value.ForEach(uf => { ufList.Add(new SelectListItem { Value = uf.Sigla, Text = uf.Nome }); }); return ufList; } } internal class UF { public UF(string nome, string sigla) { Nome = nome; Sigla = sigla; } public string Nome { get; private set; } public string Sigla { get; private set; } }

Abaixo temos a implementação do que será renderizado no front-end como componente:

@model IEnumerable<SelectListItem> <h3>Lista de UFs</h3> <span class="clearfix" /> <div class="form-control"> @Html.DropDownList("DropdownlistUF", Model) </div>

Segue o código de chamada de uma view component dentro de uma view:

<div class="col-md-4"> @Component.Invoke("DropdownListUF") </div>

O resultado dessa maravilha está marcado em vermelho e apresentado na imagem a seguir:

ViewComponent

Suporte ao GruntJS, Gulp, NPM e Bower

Mais uma vez a Microsoft reafirma seu compromisso que está realmente engajada em integrações cross-plataform e com a comunidade open-source. E quem ganha com isso? Todos nós que utilizamos essa fantástica plataforma de desenvolvimento. E dessa vez não será diferente!

Com a incorporação dessas formamentas, os maiores beneficiados foram os desenvolvedores front-end, pois com essas ferramentas será possível realizar gerenciamento de versão de pacotes JavaScript, CSS dentre outros pacotes necessários para o desenvolvimento de um front-end rico, integrado e seguro.

Essas ferramentas são sensacionais do ponto de vista da garantia da qualidade dos nossos projetos. Pois com elas torna-se possível automatizar tarefas, as quais antes tinham que ser executadas manualmente ou arrumar algum jeitinho de integrar uma ferramenta aqui e outra ali dentro do TFS Build para automatizar algumas rotinas front-end, como por exemplo: Teste unitário JavaScript.

O GruntJS é um Task Runner, isso mesmo! Ele automatiza todo o processo de build, concatenação e minificação de pacotes CSS e Javascript todas as vezes que um build rodar dentro do visual studio, por exemplo. Além dessa integração, a Microsoft também integrou o gerenciado de pacotes NPM (Node Package Manager), mas essa incorporação de ferramenta não foi atoa, isso deu-se devido a observação sobre os pacotes que o GruntJS depende para executar, todos eles são gerenciados pelo NPM Package Manager. Outro ponto que levou a Microsoft incorporar o Bower ao Visual Studio, foi a observação que a maioria das versões dos pacotes utilizados para desenvolvimento de front-ends ricos são geridos pelo Bower.

Injeção de Dependência no ASP.NET 5

Agora sim! O projeto Web do ASP.NET 5 não mais depende de nenhum container de injeção de dependência para realizar esse trabalho. Esse recurso já é o que chamamos de Built-in, ou seja, já vem implementado junto ao framework do ASP.NET 5. Claro que não para por ai! Caso você tenha necessidade dentro de sua arquitetura de utilizar qualquer outro container, isso também é possível. Bastando sobreescrever o container Built-in J.

Toda essa configuração será feita através da classe Startup.cs por meio do método ConfigureServices(). Mas você não fica limitado somente essas configurações para trabalhar a injeção de dependência; No caso da necessidade de chamar manualmente você pode utilizar o Pattern ServiceLocator para realizar esse trabalho “sujo” de procurar a implementação e instanciar a classe de sua necessidade.

Morte ao MSTest

Foi BOM enquanto durou. Por hora, temos a morte SIM do MSTest. Alguns acham isso desvantajoso devido sua integração com MTM (Microsoft Test Manager). Mas observem as vantagens do xUnit e vejam que existe um time de muita, mas MUITA gente boa do time ASP.NET utilizando o framwork xUnit e, se a Microsoft decidiu que foi melhor “matar” um framework que ela mesma desenvolveu a ANOS, não serei eu que vou dizer que seria uma excelente escolha continuar com o MSTest.

Para entender um pouco do que estou falando, basta acessar o repositório no Github do ASP.NET e observar que todos, e quando digo todos são TODOS os unit tests que o time vem implementando, são com base no xUnit.

Http Pipeline ainda mais rápido

*A Microsoft introduziu o owin através do projeto Katana, que trouxe uma coleção de recursos que davam suporte ao OWIN com uma variedade grande de componentes Microsoft. Atualmente foi incluido o suporte do OWIN para System.Web e System.Net.HttpListener, além disso foi incluido uma aplicação console chamada OwinHost.exe para rodar um servidor web self-hosting por meio de linha de comando.

A inclusão do suporte ao Owin tornou o pipeline totalmente modular, tornando possível adicionar apenas e só apenas os componentes que sua aplicação vai de fato utilizar, reduzindo o tempo de carga, processamento e resposta do pipeline. Toda essa configuração pode ser realizada através do método Configure() que pode ser encontrado na classe Startup.cs. A função do método Configure() é permitir que você mesmo configure qual tipo de Middleware será utilizado pela sua aplicação, tais como: Carga de arquivos estáticos (static files), sistema de autenticação (authentication/authorization, o famos Identity), sistemas de diagnósticos, Log, Acesso a dados, Injeção de Dependência, e assim por diante.

Conclusão

Bom pessoal, sei que ficou um pouco extensão mas a intensão aqui era mesmo mostrar algumas das muitas novidades que o ASP.NET5 vem trazendo e liberando em seu repositório no Github. Todas essas mudanças, trarão muitos benefícios a nível de arquitetura, tempo de resposta, interação e integração ainda maior da comunidade open-source inserindo excelentes contribuições para a plataforma. Facilidades para o desenvolvimento front-end, que vem crescendo exponencialmente nos ultimos anos. E quem ganha com tudo isso, somos nós DEVs. Espero que tenham gostado, e aguardem. Logo teremos mais nessa série de artigos sobre o ASP.NET 5. Até a próxima !!!

Referências