ASP.NET 4.5.1 by Grupo Lidel

Luís Abreu

Este livro concentra-se na apresentação das novidades introduzidas pela versão 4.5.1 da plataforma ASP.NET e aposta em analisar as várias novidades introduzidas nas plataformas e bibliotecas que a compõem atualmente. Entre outros são abordados os seguintes temas: • Visual Studio 2013 • One ASP.NET • OWIN e Katana • Autenticação

• ASP.NET Identity • ASP.NET MVC • Web API • SignalR

Para além dos capítulos dedicados às novidades introduzidas ao nível do Visual Studio 2013 e das plataformas Web API e MVC, o livro introduz ainda a especificação OWIN e o projeto Katana, o novo modelo de autenticação baseado em middleware OWIN e o novo modelo de gestão de dados de um utilizador (ASP.NET Identity). Todas estas funcionalidades são transversais às bibliotecas e plataformas de alto nível ASP.NET. Estamos, assim, perante um livro ideal para o leitor que já possui alguma experiência no desenvolvimento Web em ASP.NET e que procura obter todas as novidades introduzidas pela última versão da plataforma. Com exemplos práticos de aplicação, é um livro complementar às outras obras de ASP do mesmo autor.

ASP.NET 4.5.1 One ASP.NET, OWIN, Identity, MVC, Web API e SignalR

A plataforma ASP.NET é usada por muitos programadores que necessitam de criar aplicações Web dinâmicas e ricas. Com o passar dos anos, a plataforma passou a disponibilizar cada vez mais funcionalidades e abordagens diferentes que podiam ser aplicadas na construção de aplicações Web. Para além disso, os ciclos de iteração têm sido cada vez mais rápidos, o que, muitas vezes, dificulta a vida dos programadores, que tentam acompanhar todas as novidades de cada uma das novas versões.

LUÍS ABREU – Licenciado em Engenharia de Sistemas e Computadores pela Universidade da Madeira.

ISBN 978-972-722-797-6

www.fca.pt

Código fonte disponível em www.fca.pt, até o livro se esgotar ou ser publicada nova edição atualizada ou com alterações.

Luís Abreu

Tem sido um utilizador regular da plataforma .NET desde 2002. Ao longo dos últimos anos, participou em vários projetos Web e contribuiu com vários artigos para o site do grupo português PontoNetPT. Atualmente, trabalha na SRA, onde é um dos responsáveis pela arquitetura e desenvolvimento de aplicações. É MVP ASP.NET desde outubro de 2005. A partir de 2006, passou a ser o único português a integrar o grupo internacional ASP Insiders (um grupo de elite que mantém contactos regulares com a equipa da Microsoft que desenvolve a plataforma ASP.NET). Autor dos livros ASP.NET 4.5, AJAX com ASP.NET, Silverlight 4.0, Desenvolvimento em Windows 8, pertencentes à coleção Curso Completo, e ASP.NET MVC, Javascript e LINQ com C#, da coleção MyTI, editados pela FCA.

Contém todas as novidades Introdução à especificação OWIN e projeto Katana Exemplos práticos de aplicação

Distribuição

Lidel – edições técnicas, lda

Sede R. D. Estefânia, 183, R/C Dto. – 1049-057 LISBOA Tel: +351 213 511 448 * Fax: +351 213 522 684 Revenda: revenda@lidel.pt Exportação: depinternacional@lidel.pt Venda online: livraria@lidel.pt Marketing: marketing@lidel.pt

Livraria Av. Praia da Vitória, 14 – 1000-247 LISBOA Tel: +351 213 511 448 * Fax: +351 213 173 259 livraria@lidel.pt

Edição

FCA – Editora de Informática

Av. Praia da Vitória, 14 – 1000-247 LISBOA Tel: +351 213 511 448 Email: fca@fca.pt

Copyright © junho 2014 FCA – Editora de Informática, Lda. ISBN: 978-972-722-797-6 Capa: Emília Calçada Impressão e acabamento: Cafilesa – Soluções Gráficas, Lda. – Venda do Pinheiro Depósito Legal N.º 376623/14 Livro segundo o Novo Acordo Ortográfico Todos os nossos livros passam por um rigoroso controlo de qualidade, no entanto, aconselhamos a consulta periódica do nosso site (www.fca.pt) para fazer o download de eventuais correções. Os nomes comerciais referenciados neste livro têm patente registada. Marcas Registadas de FCA – Editora de Informática, Lda. – ®

Reservados todos os direitos. Esta publicação não pode ser reproduzida, nem transmitida, no todo ou em parte, por qualquer processo eletrónico, mecânico, fotocópia, digitalização, gravação, sistema de armazenamento e disponibilização de informação, sítio Web, blogue ou outros, sem prévia autorização escrita da Editora, exceto o permitido pelo CDADC, em termos de cópia privada pela AGECOP – Associação para a Gestão da Cópia Privada, através do pagamento das respetivas taxas.

ÍNDICE GERAL 1. INTRODUÇÃO ................................................................................................... 1 1.1 O que posso encontrar neste livro? .................................................................................................. 1 1.2 Requisitos ............................................................................................................................................ 1 1.3 A quem é dirigido este livro?............................................................................................................ 2 1.4 Código e samples ................................................................................................................................. 2 1.5 Convenções ......................................................................................................................................... 2 1.6 Organização do livro.......................................................................................................................... 2 1.6.1 Capítulo 2: Visual Studio 2013 .................................................................................................. 3 1.6.2 Capítulo 3: OWIN e KATANA ................................................................................................. 3 1.6.3 Capítulo 4: Autenticação .......................................................................................................... 3 1.6.4 Capítulo 5: ASP.NET IDENTITY ............................................................................................. 4 1.6.5 Capítulo 6: ASP.NET MVC ...................................................................................................... 4 1.6.6 Capítulo 7: Web API .................................................................................................................. 4 1.6.7 Capítulo 8: SignalR .................................................................................................................... 4 1.7 Suporte ................................................................................................................................................. 5 2. VISUAL STUDIO 2013 ....................................................................................... 7 2.1 Um pouco de história......................................................................................................................... 7 2.2 ONE ASP.NET................................................................................................................................... 10 2.3 Visual Studio 2013 .............................................................................................................................. 11 2.3.1 Novos Templates ...................................................................................................................... 11 2.3.2 NuGet ........................................................................................................................................ 17 2.3.3 Bootstrap .................................................................................................................................... 21 2.3.4 Scaffolding ................................................................................................................................. 24 2.3.5 Browser Link .............................................................................................................................. 25 2.3.6 Melhorias no editor................................................................................................................. 30 2.3.6.1 Esquema unificado de HTML ................................................................................... 30 2.3.6.2 Encerramento automático de chavetas .................................................................... 30 2.3.6.3 Agrupamento de atributos ........................................................................................ 30 2.3.6.4 Mais Intellisense para bibliotecas cliente .................................................................. 31 2.3.6.5 Suporte para CoffeeScript e LESS ............................................................................... 31 2.3.6.6 Melhorias na formatação e indentação .................................................................... 31 2.3.6.7 Definições avançadas para documentos HTML ..................................................... 32 2.3.7 Publicação de sites ................................................................................................................... 33 2.3.8 Windows Azure ......................................................................................................................... 35 Conclusão....................................................................................................................................................... 35 Webgrafia ....................................................................................................................................................... 36 3. OWIN E KATANA ........................................................................................... 37 3.1 Um pouco de história....................................................................................................................... 37 3.2 Introdução ao OWIN ....................................................................................................................... 38 © FCA – Editora de Informática

VIII

ASP.NET 4.5.1

3.3 Projeto Katana .................................................................................................................................... 40 3.3.1 Consumo de componentes Katana ........................................................................................ 46 3.3.2 Arquitetura do projeto Katana ............................................................................................... 47 3.3.2.1 Middleware.................................................................................................................... 50 3.3.2.2 Aplicações .................................................................................................................... 54 3.3.2.3 Hosting/servidores ...................................................................................................... 60 3.3.3 Katana nos projetos Web.......................................................................................................... 66 Conclusão....................................................................................................................................................... 69 Webgrafia ....................................................................................................................................................... 69 4. AUTENTICAÇÃO .............................................................................................. 71 4.1 Um pouco de história....................................................................................................................... 71 4.2 Autenticação OWIN ......................................................................................................................... 76 4.2.1 Autenticação baseada em cookies ........................................................................................... 77 4.2.2 Autenticação efetuada por entidades externas ................................................................... 86 4.2.3 Autenticação no Visual Studio ................................................................................................ 92 Conclusão....................................................................................................................................................... 95 Webgrafia ....................................................................................................................................................... 95 5. ASP.NET IDENTITY ....................................................................................... 97 5.1 Um pouco de história....................................................................................................................... 97 5.2 Introdução à ASP.NET Identity ..................................................................................................... 100 5.3 A API de ASP.NET Identity na prática......................................................................................... 101 5.3.1 Um exemplo prático ............................................................................................................. 105 5.3.1.1 Base de dados ............................................................................................................ 108 5.3.1.2 Store predefinida baseada em Entity Framework ................................................... 111 5.3.1.3 Migrações de dados .................................................................................................. 117 5.3.1.4 Logins mantidos por outras entidades ................................................................... 121 5.3.1.5 Claims ......................................................................................................................... 126 5.3.1.6 Pensamentos finais ................................................................................................... 129 Conclusão..................................................................................................................................................... 130 Webgrafia ..................................................................................................................................................... 130 6. ASP.NET MVC ........................................................................................... 131 6.1 Migração de projetos criados na versão 4 ................................................................................... 131 6.2 Novos atributos de autenticação .................................................................................................. 138 6.3 Override de filtros............................................................................................................................ 142 6.4 Atributos de routing ....................................................................................................................... 144 6.4.1 Justificações para o uso de atributos................................................................................... 144 6.4.2 Ativação dos atributos de routing ....................................................................................... 145 6.4.3 Definição de rotas ................................................................................................................. 145 6.4.4 Restrições ............................................................................................................................... 148 6.4.5 Ordem de avaliação .............................................................................................................. 150 6.4.6 Nomes de rotas ...................................................................................................................... 151 6.4.7 Áreas ....................................................................................................................................... 152 6.5 Outras alterações ............................................................................................................................ 153 © FCA – Editora de Informática

ÍNDICE GERAL

Conclusão..................................................................................................................................................... 153 Webgrafia ..................................................................................................................................................... 154 7. WEB API ................................................................................................... 155 7.1 Migração de projetos...................................................................................................................... 155 7.2 Atributos de routing ....................................................................................................................... 159 7.3 Filtros ............................................................................................................................................... 160 7.4 Portable client ................................................................................................................................... 160 7.5 Tipo IHttpActionResult ................................................................................................................... 160 7.6 Suporte ao CORS ............................................................................................................................ 165 7.6.1 Policy providers ....................................................................................................................... 171 7.7 HttpRequestContext ...................................................................................................................... 173 Conclusão..................................................................................................................................................... 175 Webgrafia ..................................................................................................................................................... 175 8. SIGNALR .................................................................................................... 177 8.1 Introdução ao SignalR .................................................................................................................... 177 8.2 Alguns detalhes sobre funcionamento interno........................................................................... 178 8.3 Pacotes NuGet ................................................................................................................................. 180 8.4 Ligações persistentes...................................................................................................................... 181 8.4.1 Implementação do serviço ................................................................................................... 181 8.4.2 Implementação do cliente .................................................................................................... 186 8.4.3 Negociação do transporte .................................................................................................... 190 8.4.4 Grupos de ligações ................................................................................................................ 191 8.4.5 Ligações CORS ...................................................................................................................... 193 8.5 Hubs .................................................................................................................................................. 194 8.5.1 Implementação do serviço ................................................................................................... 195 8.5.2 Implementação do cliente .................................................................................................... 200 8.5.3 Implementação do cliente sem proxy .................................................................................. 205 8.5.4 Grupos de ligações ................................................................................................................ 206 8.5.5 Estado associado a uma ligação .......................................................................................... 208 8.6 Eventos relacionados com ligações .............................................................................................. 209 8.6.1 Término de ligações de transporte...................................................................................... 211 8.6.2 Término de ligações iniciadas pelo cliente ........................................................................ 214 8.6.3 Término de ligações iniciadas pelo servidor ..................................................................... 214 8.6.4 Configurações ........................................................................................................................ 215 8.7 Segurança ........................................................................................................................................ 216 8.8 Pensamentos finais ......................................................................................................................... 218 Conclusão..................................................................................................................................................... 219 Webgrafia ..................................................................................................................................................... 219 ÍNDICE REMISSIVO ........................................................................................... 221

OWIN E KATANA

Durante anos, a plataforma ASP.NET dependeu sempre do IIS (Internet Information Server) para efetuar o hosting de aplicações Web. Com o lançamento de novas plataformas de alto nível como, por exemplo, o ASP.NET Web API e com o cloud computing a ganhar cada vez mais adeptos, tornou-se óbvia a necessidade de termos cada vez maior flexibilidade na forma como efetuamos o alojamento de aplicações. Foi a pensar nisto que surgiu as especificação OWIN (Open Web Interface for .NET) e o projeto Katana, a implementação desta especificação por parte da Microsoft.

3.1

UM POUCO DE HISTÓRIA

Antes de falarmos da especificação OWIN e do projeto Katana, convém recuarmos um pouco para percebermos a justificação para o aparecimento desta nova especificação. Durante mais de dez anos, o ASP.NET serviu de base ao desenvolvimento de muitas aplicações Web, quer para os programadores com experiência na Web, quer para aqueles oriundos do desenvolvimento tradicional de aplicações para desktop, onde o modelo introduzido pelos Web Forms permitiu a reutilização de muitos dos seus conhecimentos. Com o passar dos anos, a abordagem e o modelo de desenvolvimento de aplicações Web evoluíram imenso. Nos dias de hoje, onde cada vez mais browsers são compatíveis com o HTML5, a tendência passou a ser o desenvolvimento de aplicações Web ricas, onde a maior parte do código é executado no lado cliente, sendo o lado servidor responsável apenas por devolver os dados necessários ao correto funcionamento do código executado no lado cliente. Esta alteração de paradigma (recorde-se que, anteriormente, o modelo apostava na geração de markup a partir do lado servidor) foi ainda reforçada pela explosão das aplicações móveis, onde a redução da quantidade de dados devolvida pelo servidor ganha ainda mais importância. Na prática, isto significa que as plataformas monolíticas, que disponibilizam funcionalidades que abrangiam várias áreas, estão a ser substituídas por plataformas mais leves e flexíveis, que se caraterizam por se concentrarem apenas numa determinada área e por terem tempos de iteração muito mais curtos no que diz respeito ao lançamento de novas versões. Se olharmos para a plataforma ASP.NET, é fácil comprovarmos esta tendência. Ao contrário do que acontecia com os Web Forms, quer a plataforma MVC, © FCA – Editora de Informática

ASP.NET 4.5.1

quer a plataforma Web API possuem ciclos de vida diferentes dos da plataforma .NET, podendo mesmo ser obtidas separadamente da plataforma .NET. No caso da plataforma Web API, a Microsoft foi ainda mais longe e conseguiu remover todas as dependências da assembly System.Web e, por isso, esta plataforma pode evoluir sem ter de se preocupar com o que acontece com a plataforma ASP.NET. Note-se ainda que todos os serviços criados a partir da Web API podem ser alojados em qualquer processo, isto é, não existe a necessidade de eles serem alojados num site gerido pelo IIS. Esta não dependência do IIS pode deixar alguns motivos de preocupação ao leitor experiente. Afinal de contas, a Microsoft tem dedicado imensa atenção ao desenvolvimento e evolução do IIS ao longo dos anos. Por exemplo, desde a versão 7 que o IIS está completamente integrado na pipeline do ASP.NET, com excelentes resultados no que diz respeito à performance. Além desta integração, este servidor disponibiliza ainda muitas outras funcionalidades como, por exemplo, caching, autenticação, compressão, encriptação, etc. Apesar de todas as vantagens inerentes ao seu uso, a verdade é que, com a alteração de paradigma que referimos nos parágrafos anteriores, cada vez mais pessoas procuram servidores mais leves e flexíveis, capazes apenas de alojar serviços assíncronos que devolvam unicamente os dados necessários à realização de determinadas operações (note-se que este tipo de servidores tem ainda mais importância quando consideramos o alojamento na cloud, onde cada byte de dados e cada ciclo de processamentos possui custos que, muitas vezes, não são negligenciáveis). Um dos exemplos mais flagrantes do que estamos a afirmar é a explosão do Nodejs (http://nodejs.org/), cada vez mais usado atualmente. Apesar de não ser um servidor, o Nodejs pode ser visto como uma biblioteca do lado servidor que permite a criação rápida de aplicações escaláveis para Web. Na prática, isto significa que podemos recorrer a esta biblioteca para rapidamente criarmos um servidor modularizado, capaz de alojar aplicações Web. Foi na sequência destas alterações de paradigma que acabou por surgir o OWIN, uma especificação open source que tenta criar interfaces standard que permitam a comunicação entre aplicações Web e servidores.

3.2

INTRODUÇÃO AO OWIN

O OWIN (Open Web Interface for .NET) é uma especificação que tenta definir a comunicação entre uma aplicação Web e um servidor .NET. Esta especificação, que foi inspirada pelo Rack (http://rack.github.io/) (oriundo da comunidade Ruby), foi criada com três objetivos em mente: fácil composição de componentes, portabilidade e performance. Ao contrário do que aconteceu até aqui, em que a Microsoft apostava no desenvolvimento de um bloco monolítico, o OWIN aposta na composição de componentes por forma a garantir que apenas são usados os componentes necessários a uma determinada

OWIN E KATANA

aplicação. Este novo modelo contribui claramente para facilitar a portabilidade de código e para melhorar a performance de uma aplicação. Para atingir estes objetivos, a especificação tinha de ser simples, reduzindo, assim, ao mínimo o número de tipos referenciados. Só assim será possível facilitarmos o desenvolvimento e consumo de novos componentes e permitir o fácil alojamento de uma aplicação em hosts diferentes. Estes princípios levaram a que a especificação assente no uso de dois elementos base: um dicionário e um application delegate. Comecemos pelo dicionário… O dicionário ambiente (environment dictionary) é a estrutura de dados responsável por guardar toda a informação necessária ao correto processamento dos pedidos e respostas HTTP. Este dicionário tem uma assinatura semelhante à seguinte: IDictionary<String, Object>

Um servidor OWIN é responsável por preencher este dicionário com várias entradas predefinidas como, por exemplo, as streams do corpo ou a coleção de cabeçalhos HTTP do pedido e da resposta. O Quadro 3.1 apresenta as entradas obrigatórias que contêm informação sobre o pedido e que são adicionadas ao dicionário de ambiente por um servidor compatível com a especificação OWIN.

owin.RequestPath

Referencia um objeto do tipo Stream que representa o corpo do pedido efetuado (quando o pedido não possui corpo, esta propriedade pode ser representada pelo valor Stream.Null). Um dicionário do tipo IDictionary<String, String[]> que representa os cabeçalhos HTTP existentes no pedido recebido. Devolve uma string, que indica o método HTTP (ex.: post, get, etc.) usado na realização do pedido atual. String que indica o caminho relativo à raiz do site atual.

owin.RequestPathBase

String que indica o caminho até à raiz do site atual.

owin.RequestBody

owin.RequestHeaders

owin.RequestMethod

Owin.RequestProtocol owin.RequestQueryString owin.RequestScheme

String com informação sobre o protocolo usado (ex.: HTTP/1.1). String com o valor da query string usada no URI do pedido atual (sem o caráter ?). Devolve uma string que indica o esquema HTTP usado no pedido (ex.: http, https, etc.).

QUADRO 3.1 – Entradas obrigatórias com informação sobre o pedido HTTP

Além destas entradas, existem ainda outras relacionadas com os dados da resposta HTTP devolvida pela aplicação (ex.: owin.RequestBody permite-nos aceder a um objeto do tipo Stream que representa o corpo da resposta devolvida pelo servidor) ou © FCA – Editora de Informática

ASP.NET 4.5.1

com dados gerais relativos ao processamento (ex.: owin.CancellationToken devolve um objeto do tipo CancellationToken, que pode ser usado por um componente para saber se o processamento atual foi abortado ou cancelado). Muitas das entradas relacionadas com a resposta são simétricas às apresentadas no Quadro 3.1 para o pedido. Ao leitor interessado, recomendamos a consulta da secção 3.2 da especificação OWIN (http://owin.org/#spec) para obter a listagem completa das entradas obrigatórias disponibilizadas pelo dicionário de ambiente. Além do dicionário, a especificação OWIN introduz ainda um outro conceito importante: o application delegate. Este delegate define a assinatura de uma função que serve de interface primária para permitir a comunicação entre os vários componentes OWIN que formam uma aplicação: Func<IDictionary<String, Object>, Task>

Como é possível verificar, o application delegate (também designado por AppFunc) não é mais do que um delegate de tipo Func, que aceita uma referência para um dicionário de ambiente (IDictionary<String, Object>) e devolve um objeto do tipo Task. As dependências externas de cada um destes dois conceitos importantes introduzidos pela especificação são mínimas, o que simplifica a criação de componentes compatíveis com a especificação OWIN. Além disso, o uso de tarefas (tipo de retorno Task devolvido pelo AppFunc) contribui para aumentar a eficiência do servidor ao forçar o uso de processamento assíncrono (especialmente quando estamos perante operações I/O – ex.: acesso a um ficheiro ou invocação de um web service). Finalmente, importa ainda salientar que o facto de o dicionário de ambiente ser transportado entre componentes (através do parâmetro definido no AppFunc) permite a fácil composição de sequências complexas de componentes OWIN que podem ser usados para processar um pedido HTTP. Antes de passarmos a analisar o projeto Katana (implementação da especificação OWIN da Microsoft), queríamos, uma vez mais, salientar que o OWIN é uma especificação e não a próxima plataforma Web da Microsoft. Ou seja, o seu principal objetivo é especificar a forma como as plataformas podem interagir com um servidor Web, e não introduzir um conjunto de novas classes usadas na construção de aplicações Web.

3.3

PROJETO KATANA

O projeto Katana tenta reproduzir muitas das vantagens introduzidas pela plataforma Nodejs no ecossistema .NET. Ou seja, este projeto – que disponibiliza vários componentes compatíveis com a especificação OWIN – permite-nos usufruir de muitas

OWIN E KATANA

das vantagens disponibilizadas pela plataforma Nodejs, ao mesmo tempo que permite ao programador reutilizar os conhecimentos que este já possui sobre a plataforma ASP.NET. Uma das principais caraterísticas disponibilizadas pela biblioteca Nodejs que costuma impressionar os novatos é a simplicidade com que se consegue criar rapidamente uma aplicação que responde a pedidos HTTP (isto é, a simplicidade com que conseguimos criar uma aplicação Web). Vejamos, então, o trabalho necessário para obter o mesmo resultado com o projeto Katana. A primeira coisa a fazer é criar um novo projeto. Neste caso, vamos optar por criar um novo projeto do tipo consola, conforme ilustrado pela Figura 3.1.

FIGURA 3.1 – Criação de um novo projeto consola

Em seguida, queremos transformar a consola num servidor, capaz de receber e tratar pedidos HTTP. Para isso, vamos começar por adicionar alguns pacotes NuGet. O primeiro dos pacotes que vamos instalar é o pacote Microsoft.Owin.Hosting, conforme ilustrado na Figura 3.2.

FIGURA 3.2 – Instalação do pacote Microsoft.Owin.Hosting

ASP.NET 4.5.1

Aquando da escrita do livro, este pacote só estava disponível em versão experimental, pelo que fomos forçados a colocar a flag –prerelease. Como é possível verificar através da Figura 3.3, a instalação deste pacote resulta ainda na instalação de outros (dos quais ele depende para funcionar corretamente em runtime).

FIGURA 3.3 – Dependências do pacote Microsoft.Owin.Hosting

Antes de iniciarmos a escrita, temos ainda de adicionar um outro pacote NuGet ao nosso projeto: o pacote Microsoft.Owin.Host.HttpListener (disponível também em fase experimental). Este pacote contém componentes responsáveis por interagir com o sistema operativo e por tratar as mensagens HTTP recebidas numa determinada porta HTTP.

FIGURA 3.4 – Adição do pacote Microsoft.Owin.Host.HttpListener

Terminada a importação destes pacotes, ficamos com um projeto que referencia quatro novas assemblies (Figura 3.5). A assembly Owin.dll contém apenas uma interface, designada por IAppBuilder, cujo principal objetivo é abstrair o processo de inicialização definido pela secção 4 da especificação OWIN. Apesar de a especificação não mencionar esta interface, ela fornece-nos um ponto concreto de referência e é usada por todos os componentes Katana. O excerto seguinte apresenta os principais métodos disponibilizados por esta interface:

OWIN E KATANA

public interface IAppBuilder { IDictionary<string, object> Properties { get; } IAppBuilder Use(object middleware, params object[] args); object Build(Type returnType); IAppBuilder New(); }

Por sua vez, a assembly Microsoft.Owin.dll introduz um conjunto de tipos que simplificam o acesso às entradas mantidas no dicionário de ambiente (ex.: IOwinRequest) e de extensões que simplificam a realização de determinadas operações. Finalmente, as restantes duas assemblies (Microsoft.Owin.Host.HttpListener.dll e Microsoft.Owin.Hosting.dll) introduzem tipos compatíveis com a especificação OWIN que nos permitem transformar rapidamente a consola num servidor HTTP.

FIGURA 3.5 – Assemblies adicionadas pelos pacotes NuGet anteriores

Agora que já temos todas as assemblies necessárias referenciadas, temos de configurar a nossa aplicação Katana. Para isso, vamos começar por adicionar uma nova classe, designada por Startup, que disponibiliza um método designado por Configuration: public class Startup { public void Configuration(IAppBuilder app) { } }

Este método espera um parâmetro, do tipo IAppBuilder, que, como mencionámos anteriormente, disponibiliza um conjunto de métodos que nos permitem definir a © FCA – Editora de Informática

ASP.NET 4.5.1

forma como a aplicação se deve comportar e responder perante os pedidos HTTP recebidos. Neste exemplo, vamos recorrer apenas ao método Run, que será executado pelo runtime do Katana para cada um dos pedidos HTTP recebidos. Este método espera um delegate do tipo Func<IOwinContext,Task>. O tipo IOwinContext abstrai o contexto atual e disponibiliza vários membros úteis (Figura 3.6) que nos permite, por exemplo, aceder ao pedido (propriedade Request) ou à resposta (propriedade Response). Uma das propriedades mais importantes disponibilizada por esta interface é a propriedade Environment, que retorna uma referência para o dicionário de ambiente que é passado ao longo de toda a pipeline OWIN (mais informações nas secções seguintes).

FIGURA 3.6 – Alguns dos membros disponibilizados pela interface IOwinContext

Como estamos ainda a iniciar-nos na biblioteca Katana, vamos configurar a nossa aplicação para responder a todos os pedidos recebidos com uma mensagem de texto (Ola mundo!). public class Startup { public void Configuration(IAppBuilder app) { app.Run(ctx => { ctx.Response.ContentType = "text/plain; charset=UTF-8"; return ctx.Response.WriteAsync("Ola mundo!"); }); } }

A nossa aplicação acede ao objeto que representa a resposta devolvida (propriedade Response do contexto passado ao delegate) para definir o tipo de conteúdo devolvido (propriedade ContentType), e a escrever a mensagem de texto na stream que será devolvida ao cliente. Para podermos executar a nossa aplicação, falta-nos apenas adicionar o código responsável por escutar os pedidos HTTP efetuados sobre um determinado porto. O excerto seguinte apresenta esse código: © FCA – Editora de Informática

OWIN E KATANA

private static void Main(string[] args) { var url = "http://localhost:9999"; using (WebApp.Start<Startup>(url)) { Console.WriteLine("Servidor iniciado..."); Console.ReadLine(); Console.WriteLine("Servidor parando..."); } }

A classe auxiliar WebApp encontra-se definida na assembly Microsoft.Owin.Hosting.dll e permite-nos iniciar o servidor Katana, responsável por escutar os pedidos HTTP efetuados no porto 9999 (foi esta a configuração definida pela nossa classe Startup). A partir desta altura, a nossa aplicação consola está pronta para ser usada como servidor Web, conforme ilustrado pela Figura 3.7.

FIGURA 3.7 – Aplicação consola preparada para receber pedidos HTTP

Depois de termos a aplicação consola a correr, ao redirecionarmos o browser para o URL http://localhost:9999/, devemos obter a resposta de texto Ola Mundo!, conforme ilustrado pela Figura 3.8.

ASP.NET 4.5.1

Como é óbvio, esta aplicação não é lá muito útil, já que se limita apenas a devolver a mesma resposta para todos os pedidos recebidos na porta 9999. E que tal modificarmos a aplicação atual para termos uma página de boas-vindas?

3.3.1

CONSUMO DE COMPONENTES KATANA

Felizmente para nós, este tipo de operação já é suportado out of the box pelo pacote NuGet Microsoft.Owin.Diagnostics. Portanto, vamos começar por adicionar este pacote ao nosso projeto através da instrução seguinte: install-package microsoft.owin.diagnostics

Este pacote disponibiliza um conjunto de componentes que nos auxiliam a construir aplicações, nomeadamente no que diz respeito a efetuar o troubleshooting de eventuais problemas que venham a ocorrer. Um desses componentes encarrega-se de apresentar uma página de boas-vindas. Para o usar na nossa aplicação, vamos substituir o nosso código atual de configuração pelo seguinte: public class Startup { public void Configuration(IAppBuilder app) { app.UseWelcomePage(); } }

O utilizador atento reparou, com toda a certeza, na utilização do método UseWelcomePage, que não é definido pela interface IAppBuilder. O que se passa é que o

pacote que instalámos injeta métodos de extensão, que encapsulam todo o código de configuração que teríamos de escrever. Esta é, aliás, uma técnica seguida por praticamente todos os componentes Katana adicionados através de pacotes NuGet. Por outras palavras, estes componentes introduzem métodos de extensão ao tipo IAppBuilder, que simplificam a sua configuração. Portanto, é normal vermos a lista de métodos apresentada pelo Intellisense para o tipo IAppBuilder aumentar com a adição de novos pacotes NuGet que contêm componentes Katana. A Figura 3.9 ilustra o aspeto da página devolvida pela consola depois de esta ter sido colocada em execução. Nesta altura, temos um projeto que recorre a um objeto WebApp para efetuar o alojamento de uma aplicação Web OWIN, que foi configurada para apresentar sempre uma página de resposta a todos os pedidos HTTP recebidos. Como vimos, a interface IAppBuilder desempenhou um papel importante na configuração da nossa aplicação: limitámo-nos a recorrer a um par de métodos que produziram automaticamente

Luís Abreu

• ASP.NET Identity • ASP.NET MVC • Web API • SignalR

ASP.NET 4.5.1 One ASP.NET, OWIN, Identity, MVC, Web API e SignalR

LUÍS ABREU – Licenciado em Engenharia de Sistemas e Computadores pela Universidade da Madeira.

ISBN 978-972-722-797-6

www.fca.pt

Código fonte disponível em www.fca.pt, até o livro se esgotar ou ser publicada nova edição atualizada ou com alterações.

Luís Abreu

Contém todas as novidades Introdução à especificação OWIN e projeto Katana Exemplos práticos de aplicação