MVC Summit 2013

O MVC Summit é um evento anual, gratuito e online, 14 palestras sobre ASP.NET e Web foram transmitidas ao vivo e estão disponíveis para exibição no Youtube.

MVC Summit

No último sábado (27/07) ocorreu o MVC Summit 2013, um evento anual e online, organizado pelo André Baltieri e Victor Cavalcante.

Neste ano o formato do evento foi alterado, o Google Hangouts foi utilizado para transmissão online. O MVC Summit 2013 contou com 2 trilhas (MVC e Web) onde alguns dos grandes nomes da comunidade palestraram sobre ASP.Net e Web Standards.

A minha palestra foi sobre ASP.Net SignalR, para ter acesso as minhas demos e slides acesse o conteúdo deste outro artigo: Palestra sobre ASP.Net SignalR + Demos + Vídeo

As palestras foram transmitidas ao vivo mas foram todas gravadas pelo Youtube e estão disponíveis abaixo:

Trilha MVC

Parte 1

Parte 2

Parte 3

Trilha Web

Parte 1

Parte 2

Acesse o site do MVC Summit 2013
http://www.mvcsummit.com.br

Meus agradecimentos aos organizadores e todos os espectadores que assistiram, interagiram e deixaram seu feedback. Até a próxima edição.

ASP.Net Web API 2 – O que há de novo?

O ASP.Net Web API 2 foi anunciado no Microsoft Build Developer Conference 2013 (25/06 -28/06), onde foram também anunciadas ótimas novidades para o ASP.Net em geral em conjunto com o novo Visual Studio 2013.

ASP.Net Web API 2

Para ter um maior entendimento sobre ASP.Net Web API recomendo começar pela leitura do artigo ASP.Net Web API – Meu primeiro serviço REST.

Novidades no ASP.Net Web API 2

Attribute Routing

O ASP.Net Web API agora suporta atributos de roteamento (Attribute Routing). Com os atributos de roteamento é possível especificar as rotas Web API por anotação nas Actions e Controllers como no exemplo a seguir.

[RoutePrefix("orders")]
public class OrdersController : ApiController
{
    [HttpGet("{id}")]
    public Order Get(int id) { }

    [HttpPost("{id}/approve")]
    public Order Approve(int id) { }
}

O Attribute Routing possui uma sintaxe conveniênte para especificar parâmetros opcionais (people/{name?}), valores default (people/{name=Dan}) e constraints de rota (people/{name:alpha}).

Usando o Attribute Routing, é possível de forma fácil definir uma hierarquia de recursos através de um única API controller.

public class MoviesController : ApiController
{
    [HttpGet("movies")]
    public IEnumerable Get() { }

    [HttpGet("actors/{actorId}/movies")]
    public IEnumerable GetByActor(int actorId) { }

    [HttpGet("directors/{directorId}/movies")]
    public IEnumerable GetByDirector(int directorId) { }
}

O Attribute Routing é uma feature muito útil e proporciona um controle muito mais granular, tornando o desenvolvimento mais rápido e prático.

Para saber mais:

Melhorias com OData: $select, $expand, $batch, $value e extensibilidade.

O ASP.Net Web API OData agora tem suporte completo para $select, $expand e $value.
É possível usar $batch para requests em lotes e processamento de changsets.

Melhorias de extensibilidade nos formatadores OData permitem adicionar Atom entry Metadata, suporte a Named Stream e Media Link, adicionar Instance Annotations e customização de Link Generation.

Para saber mais:

Request Batching

Request Batching permite combinar várias operações em um único HTTP POST, assim reduzindo o tráfego de rede e fornecendo uma UI mais leve.

O ASP.NET Web API passa a suportar requisições em lote utilizando o endpoint $batch apresentado nas melhorias com OData.

Para ativar o Request Batching basta adicionar uma rota com um batching handler na configuração do Web API.

public static class WebApiConfig
{
    public static void Register(HttpConfiguration config)
    {
        config.Routes.MapHttpBatchRoute(
        routeName: "WebApiBatch",
        routeTemplate: "api/batch",
        batchHandler: new DefaultHttpBatchHandler(GlobalConfiguration.DefaultServer));
    }
}

Para saber mais:

Portable ASP.NET Web API Client

Agora é possível utilizar o client do ASP.NET Web API em bibliotecas de classes portáveis que irão trabalhar com aplicativos Windows Store e Windows Phone 8.
Além disso é possível também criar o próprio formatador que será compartilhado entre cliente e servidor.

Isto torna muito mais fácil a escrita de clients .Net que interagem com serviços HTTP RESTful.

Para saber mais:

Melhorias na Testabilidade

Testes de unidade em API Controllers ficaram muito mais fáceis de serem escritos, basta instanciar a API Controller e então chamar a Action Method que deseja testar. É possível de forma muito fácil fazer o mock da classe UrlHelper nos casos em que o Action Method realiza a geração de link.

IHttpActionResult

Na primeira versão do ASP.Net Web API existiam duas maneiras de criar um response de uma API Action, retornar a instância de um objeto conhecido e deixar a Web API convertê-lo em um HttpResponseMessage ou retornar um HttpResponseMessage padrão.

No ASP.Net Web API 2 existe uma terceira opção a IHttpActionResult, muito simples e extremamente poderosa, é efetivamente uma factory para HttpResponseMessage e pela implementação de sua interface é possível fornecer instruções de como o novo response deve ser construído.

Para saber mais:

CORS

O ASP.Net Web API 2 agora possui suporte total a CORS.

A segurança presente nos browsers impedem uma página web de fazer requisições AJAX em outro domínio, essa restrição é chamada de Same-origin policy, porém algumas vezes isso pode ser necessário.

Cross Origin Resource Sharing (CORS) é um padrão W3C que permite que um servidor relaxe em relação a Same-origin policy, usando CORS um servidor pode permitir explicitamente algumas solicitações e rejeitar outras.

Para saber mais:

Authentication Filters

Authentication Filters são um novo tipo de filtro no ASP.NET Web API, são executados antes dos authorization filters no pipeline do Web API e permitem que seja especificada a lógica de autenticação, podendo “per-action”, “per-controller” ou globalmente para todos os controllers.

Authentication Filters processam credenciais durante um request e também podem adicionar “challenges” de autenticação em resposta à solicitações não autorizadas.

Filter Overrides

Agora é possível sobrescrever os filtros que se aplicam a uma determinada action ou controller especificando um conjunto de tipos de filtros que não devem ser executados em um determinado escopo (action ou controller).

Isso permite que sejam configurados os filtros que se aplicam globalmente, porém em seguida excluir determinados filtros globais da aplicação em actions ou controllers específicos.

Suporte e integração com OWIN

O ASP.Net Web API 2 agora suporta totalmente OWIN e poderá rodar em qualquer host que também possua suporte ao OWIN.

Para saber mais:

External Authentication Services

Agora os serviços ASP.Net Web API poderão integrar-se com serviços de autenticação externos como OAuth e OpenID e serviços de autenticação de redes sociais como Microsoft, Twitter, Facebook e Google.

Para saber mais:

Resumo

O ASP.Net Web API 2 possui diversas novidades em relação a primeira versão, todas elas foram planejadas para proporcionar uma maior abrangência na implementação de integrações, extensibilidade com outras tecnologias, segurança no tratamento das requisições e facilidade no desenvolvimento.

Quem já usou o ASP.Net Web API com certeza identificou nessa nova versão grandes e potenciais melhorias que o torna a melhor opção para criação de serviços HTTP REST.

Referências

Gostou deste artigo? Compartilhe e deixe seu comentário abaixo 😉

e-Book 25 dicas de performance para ASP.NET

Confira como ganhar mais performance em suas aplicações ASP.Net com 25 dicas práticas disponíveis gratuitamente neste e-Book, muitas delas são simples de implementar e podem trazer muitos resultados positivos.

25 dicas de performance em ASP.Net

A crescente adoção de ASP.Net MVC 4 e Web API entre outras tecnologias significam novas oportunidades para melhorias de desempenho e funcionalidades.

Este e-Book foi escrito por influentes membros da comunidade ASP.Net e utiliza variadas tecnologias e funcionalidades para resolver problemas conhecidos, é uma leitura fácil e dinâmica, algumas das dicas dão vontade de parar de ler na hora para ir correndo implementar.

Confira alguns dos termos e tecnologias em destaque nestas 25 dicas:

  • ASP.Net MVC
  • ASP.Net Web API
  • LINQ
  • Entity Framework
  • RavenDB
  • C# Async / Await
  • Javascript
  • JSON
  • OutputCache

Download

Referência

Conseguiu ter uma boa experiência com estas dicas? Recomenda a leitura?
Participe contribuindo com sua opinião nos comentários abaixo.

Recomendações de Livros sobre ASP.Net MVC

Para aprender ASP.Net MVC é sempre recomendada a leitura de um bom livro sobre o assunto. Conheça quais são os livros são mais recomendados.

Recebo muitas perguntas sobre qual o melhor livro para ler e aprender ASP.Net MVC.
A leitura é um fator essencial e a escolha do livro adequado faz toda a diferença.
Ler estimula o autodidatismo e gera diversos benefícios além do propósito do aprendizado.

Infelizmente não possuímos várias opções em Português, inclusive alerto sobre o problema de ler livros traduzidos, geralmente são confusos e não vale a pena.

Nesta lista eu priorizei a ordem por livros que li e recomendo, autores conhecidos e feedback de outros leitores:

Livros ASP.Net MVC Título: Professional ASP.NET MVC 4
Autores: Jon Galloway, Phil Haack, Brad Wilson, K. Scott Allen, Scott Hanselman
Ano: 2012
Páginas: 504
Linguagem: Inglês
Feedback: Escrito por alguns dos mais brilhantes profissionais da Microsoft, leitura recomendada, primeira opção a ser considerada.
Livros ASP.Net MVC Título: Programming ASP.NET MVC 4
Autores: Jess Chadwick, Todd Snyder, Hrusikesh Panda
Ano: 2012
Páginas: 492
Linguagem: Inglês
Feedback: Assim como a maioria dos livros da O’Reilly é uma ótima obra, explica com clareza todas as features do MVC 4.
Livros ASP.Net MVC Título: ASP.NET MVC 4 in Action
Autores: Jeffrey Palermo, Jimmy Bogard, Eric Hexter, Matthew Hinze, Jeremy Skinner
Ano: 2012
Páginas: 404
Linguagem: Inglês
Feedback: Um livro com uma dinâmica mão na massa, com vários exemplos e tutoriais.
Livros ASP.Net MVC Título: ASP.NET MVC 4 Recipes
Autor: John Ciliberti
Ano: 2013
Páginas: 632
Linguagem: Inglês
Feedback: Um guia muito prático para criação modernas WebApps com MVC, HTML5, jQuery, Knockout.js e etc.
Livros ASP.Net MVC Título: ASP.NET MVC 4 and the Web API
Autor: Jamie Kurtz
Ano: 2013
Páginas: 152
Linguagem: Inglês
Feedback: Um livro com foco exclusivo em ASP.Net Web API com MVC, leitura enriquecedora e prática.
Livros ASP.Net MVC Título: Pro ASP.NET Web API Security
Autor: Badrinarayanan Lakshmiraghavan
Ano: 2013
Páginas: 416
Linguagem: Inglês
Feedback: Livro focado em segurança com ASP.Net Web API, dicas e informações importantes a serem aplicadas em uma integração.
Livros ASP.Net MVC Título: Programando com ASP.NET MVC
Autor: Alfredo Lotar
Ano: 2011
Páginas: 392
Linguagem: Português
Feedback: Livro para quem procura uma leitura original em Português, foi baseado em MVC 3 e aborda todos os tópicos com clareza e exemplos práticos.

Você já leu algum livro desta lista? Tem alguma recomendação ou pergunta?
Deixe seu comentário abaixo, vamos enriquecer esta lista com as nossas experiências.

ASP.Net Web API – Meu primeiro serviço REST

ASP.Net Web API é um framework que facilita a construção de serviços REST HTTP que alcançam uma grande variedade de clientes incluindo Mobile, Browsers e aplicações locais. É a plataforma ideal para construção de serviços REST baseados em .Net

Com o lançamento do ASP.Net MVC 4 em 2012 uma das novas features foi o ASP.Net Web API, entenda como funciona e aprenda a criar sua primeira aplicação HTTP REST.

Introdução

Serviços de internet são populares já faz um bom tempo, WebServices foram desenvolvidos e consumidos durante longos anos sendo uma tecnologia livre de plataforma, ou seja, aplicações .Net e Java se comunicam por WebServices sem dependência de tecnologias. Nos anos seguintes a Microsoft lançou o Remoting e por fim o famoso WCF que engloba (HTTP, TCP, MQ).

Apesar do Remoting e WCF serem tecnologias Microsoft o que WebServices, Remoting e WCF tem em comum? Todos eles são baseados em SOAP (Simple Object Access Protocol). O SOAP é baseado em XML e busca padronizar o conteúdo que é trafegado entre as pontas. O problema do SOAP é que algumas plataformas não conseguiram acompanhar sua evolução e a adoção se tornou complicada devido sua implementação, por este motivo começaram a surgir soluções alternativas mais simples.

Uma solução alternativa ao SOAP e altamente adotada é o REST (Representational State Transfer), baseado totalmente em HTTP e seus recursos. Para o melhor entendimento sobre ASP.Net Web API e REST sugiro conhecer um pouco sobre o protocolo HTTP.

Grandes empresas como Google, Facebook, LinkedIn, Netflix entre diversas outras já disponibilizam APIs Web para serem consumidas, todas elas são baseadas em HTTP com REST.

O ASP.Net Web API utiliza HTTP com REST e diferente do SOAP não depende de XML para trafegar as informações, o formato padrão para isso é JSON (Java Script Object Notation).

JSON é um formato amplamente utilizado em qualquer plataforma (não apenas .Net),  é um subconjunto da notação de objeto de JavaScript, mas seu uso não requer JavaScript exclusivamente. Isso proporciona um potencial muito grande para os serviços HTTP, pois é um formato intercambiável, leve e livre de plataformas.

É possível retornar XML com Web API ao invés de JSON ou outros formatos como CSV. Também é possível criar um formato próprio para retornar os dados, tudo fica a critério do desenvolvedor.

Mão na massa

Vamos iniciar a construção do nosso serviço REST com ASP.Net Web API, para isso este exemplo irá utilizar o Visual Studio 2012. Crie um novo projeto Web ASP.Net MVC 4.

ASP.Net Web API

Escolha o Template do ASP.Net Web API.

ASP.Net Web API

Espere seu projeto ser criado e será exibida esta tela inicial (clique para expandir).

ASP.Net Web API

Note que apesar de ser um template para construção de serviços o projeto não deixa de ser ASP.Net MVC, no caso da criação de um projeto MVC + Web API não é necessário ter dois projetos na mesma solution, utilize apenas o template ASP.Net Web API.

Rodando pela primeira vez a aplicação (F5).

ASP.Net Web API

Uma Web Application no layout padrão do ASP.Net MVC 4 foi criada, você pode utilizar este site para criar a documentação e apresentação de sua Web API.

Com o projeto configurado a proposta é construir um serviço de consumo do cadastro de clientes, o serviço irá realizar consultas no modelo de dados que iremos criar.

Na pasta Model adicione uma nova classe chamada Cliente.

public class Cliente
{
    public int ID { get; set; }

    public string Nome { get; set; }

    public string Email { get; set; }

    public bool Ativo { get; set; }
}

Na sequência crie uma Controller para trabalhar com a classe de Clientes (clique direito na pasta Controller > Add > Controller)

ASP.Net Web API

Observe que nesse exemplo está sendo utilizada uma opção de Scaffolding para criar uma Controller de Web API vazia, porém com as actions de leitura e escrita, caso estivéssemos utilizando Entity Framework a opção acima da selecionada já criaria uma estrutura com o CRUD e etc…

Com a Controller criada eis o código gerado.

using System.Collections.Generic;
using System.Web.Http;

namespace MeuServicoWebAPI.Controllers
{
    public class ClienteController : ApiController
    {
        // GET api/cliente
        public IEnumerable Get()
        {
            return new string[] { "value1", "value2" };
        }

        // GET api/cliente/5
        public string Get(int id)
        {
            return "value";
        }

        // POST api/cliente
        public void Post([FromBody]string value)
        {
        }

        // PUT api/cliente/5
        public void Put(int id, [FromBody]string value)
        {
        }

        // DELETE api/cliente/5
        public void Delete(int id)
        {
        }
    }
}

Total semelhança com MVC certo? Digo inclusive que é mais fácil construir uma Web API do que uma WebApp com MVC.

Como diferenciar uma Controller MVC de uma Controller Web API?
Uma Controller Web API herda de ApiController enquanto uma Controller MVC herda de Controller. Essa é a forma mais fácil de identificar.

Um ponto importante, o MVC assim como o Web API possuem rotas pré-definidas, no template de projeto a rota do MVC fica no arquivo RouteConfig.cs enquanto a do Web API fica no arquivo WebApiConfig.cs, ambas na pasta App_Start.

Observe as duas rotas.

// Rota Web API
config.Routes.MapHttpRoute(
                name: "DefaultApi",
                routeTemplate: "api/{controller}/{id}",
                defaults: new { id = RouteParameter.Optional }
            );

// Rota MVC
routes.MapRoute(
                name: "Default",
                url: "{controller}/{action}/{id}",
                defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional }
            );

Existem algumas diferenças, mas a que é mais importante de entender é que no caso da rota MVC a sequencia padrão será {controller}/{action}/{id} já na rota Web API a sequência é api/{controller}/{id}, sendo que “api” é um valor hard coded e não temos uma action configurada para ser chamada na URI.

Sendo assim como a rota do Web API sabe qual método está sendo chamado?

É um ponto muito importante a entender, por convenção do ASP.Net Web API os nomes dos métodos expressam a ocasião em que eles serão chamados. Dado os métodos da Controller acima:

  • Get
  • Post
  • Put
  • Delete

Estes são os nomes dos métodos e também são alguns dos verbos aceitos pelo HTTP, falando em HTTP para os verbos listados teríamos os seguintes comportamentos:

  • Get = Select
  • Post = Insert
  • Put = Update (ou Insert)
  • Delete = Delete

Ou seja, através do HTTP quando for realizado um GET via URI o Web API retornará o resultado do método Get, um POST via formulário o Web API fará uma inclusão através do metodo Post, PUT via formulário uma alteração através do método Put e DELETE via URI uma exclusão através do método Delete.

Vale lembrar que isso é uma convenção e podemos fazer de outras formas, por exemplo, o método Get poderia ser GetClientes, funcionaria da mesma forma, pois inicia com Get.
Se um método for criado como RetornarClientes seria necessário especificar qual verbo HTTP este método aceita, uma vez que o Web API não reconheceria sozinho qual dos métodos executar, nesse caso ficaria assim:

// Definindo qual o verbo o método aceita.
[AcceptVerbs("GET")]
public IEnumerable RetornarClientes()
{
    return new string[] { "value1", "value2" };
}

Especificando o tipo de verbo aceito no método podemos definir livremente a nomenclatura a ser utilizada sem depender da convenção padrão.

Atenção, cuidado ao definir os verbos aceitos, pois se um método tiver a mesma estrutura (mesmo verbo aceito e mesmo tipo de parâmetros recebidos) irá resultar em uma exception, pois o Web API não saberá qual dos métodos deverá executar.

Partindo da estrutura da Controller gerada faremos ela trabalhar com o modelo de dados da classe Cliente.

using System.Linq;
using System.Web.Http;
using MeuServicoWebAPI.Models;

namespace MeuServicoWebAPI.Controllers
{
    public class ClienteController : ApiController
    {
        private readonly Cliente[] Clientes = new Cliente[]
                {
                    new Cliente { ID = 1, Nome = "Eduardo Pires", Email = "[email protected]", Ativo = true },
                    new Cliente { ID = 2, Nome = "Bill Gates", Email = "[email protected]", Ativo = true },
                    new Cliente { ID = 3, Nome = "Aleister Crowley", Email = "[email protected]", Ativo = false }
                };

        // GET api/cliente
        public Cliente[] Get()
        {
            return Clientes;
        }

        // GET api/cliente/5
        public Cliente Get(int id)
        {
            var clientes = Clientes;

            return clientes.SingleOrDefault(x => x.ID == id);
        }

        // POST api/cliente
        public void Post([FromBody]string value)
        {
        }

        // PUT api/cliente/5
        public void Put(int id, [FromBody]string value)
        {
        }

        // DELETE api/cliente/5
        public void Delete(int id)
        {
        }
    }
}

*Para os métodos diferentes de Get (Post, Put, Delete) seria necessária uma estrutura de gravação de dados que não será abordada nesse exemplo.

Executando a aplicação testaremos a chamada do serviço ASP.Net Web API.
Primeiramente será chamado o método Get para testar se o serviço retornará toda a lista de clientes. Observe a URI no browser.

ASP.Net Web API

O serviço funcionou e respondeu sendo chamado pelo browser, o retorno foi em XML, pois o browser não interpreta JSON, por padrão o Web API está configurado para responder JSON sempre que possível.

Para testar com mais detalhes usaremos uma ferramenta chamada Fiddler (recomendo fortemente o conhecimento e uso desta ferramenta).

Nesse exemplo será chamado o método Get que aceita o parâmetro Id e retornará um dado de cliente específico através de uma pesquisa executada no método. Primeiramente chamaremos o serviço Web API através da aba Composer, note que o verbo escolhido é o Get e que agora está sendo informado o valor do Id do cliente na URI do serviço. Clicando no botão Execute será feita a chamada.

ASP.Net Web API

Na coluna da direita é possível observar que a consulta foi feita e o retorno dela é o código HTTP 200 (OK). Clicando no item desta coluna observe o retorno em JSON que será exibido pela ferramenta.

ASP.Net Web API

O serviço retornou um dado de cliente específico para esta consulta. Para ter uma visão completa do retorno clique na aba Raw, localizada ao lado da aba JSON.

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: =?UTF-8?B?RDpcTGFic1xNZXVTZXJ2aWNvV2ViQVBJXE1ldVNlcnZpY29XZWJBUElcYXBpXGNsaWVudGVcMg==?=
X-Powered-By: ASP.NET
Date: Thu, 11 Jul 2013 03:58:17 GMT
Content-Length: 71
{"ID":2,"Nome":"Bill Gates","Email":"[email protected]","Ativo":true}

A última linha é o retorno JSON da consulta em texto puro sem a formatação da ferramenta, observe que é muito mais simples que XML.

O serviço Web API está funcionando e retornando uma lista de clientes ou um cliente específico através de seu ID, basta agora ser consumido por qualquer tipo de aplicação.

Para aprender mais

Recentemente o Israel Aece lançou um e-Book gratuito sobre ASP.Net Web API, faça o download dele aqui. Recomendo a leitura.

O site oficial do ASP.Net Web API também possui diversos exemplos e tutoriais essenciais no aprendizado.

Resumo

Podemos observar que é muito simples criar um serviço REST HTTP utilizando ASP.Net Web API e para quem está habituado com ASP.Net MVC é mais simples ainda.

A ferramenta Fiddler ajuda muito em testes, podemos observar com riqueza os valores retornados e os códigos de HTTP, muito útil no caso de uma análise.

Continue acompanhando os posts da série, no próximo sobre Web API abordarei segurança com Autenticação e Autorização e exemplos de um site consumindo o retorno em JSON do serviço Web API.

Referências

Gostou do artigo? Comente e compartilhe suas impressões nos comentários abaixo 😉

ASP.Net MVC 5 – O que há de novo?

O ASP.Net MVC 5 foi anunciado no Microsoft Build Developer Conference 2013 (25/06 -28/06), onde foram também anunciadas ótimas novidades para o ASP.Net em geral em conjunto com o novo Visual Studio 2013.

ASP.Net MVC 5

ASP.NET MVC 5

One ASP.Net
Os templates de projeto ASP.Net MVC 5 integram-se em uma nova experiência de uso chamada One ASP.Net. Agora é possível customizar o template MVC e configurar o tipo de autenticação durante o processo de criação do projeto através do Wizard.
Todo projeto ASP.Net MVC 5 agora é uma Web Application padrão e não possui um próprio project GUID.

ASP.NET Identity
Os templates de projeto ASP.Net MVC 5 foram atualizados para utilizar o ASP.NET Identity para autenticação e gerenciamento das identidades.
Conheça mais sobre o ASP.Net Identity:
Introducing ASP.NET Identity – A membership system for ASP.NET applications

Bootstrap
Os templates de projeto ASP.Net MVC 5 foram atualizados para utilizar o Bootstrap, proporcionando um visual elegante e responsivo.
Conheça o Bootstrap

Authentication Filters
Authentication Filters são um novo tipo de filtro no ASP.NET MVC 5.
São executados antes dos filtros de autorização no pipeline ASP.NET MVC e permitem que você especifique uma lógica de autenticação “per-action”, “per-controller” ou globalmente para todos os controllers.

Authentication Filters processam credenciais durante um request e também podem adicionar “challenges” de autenticação em resposta à solicitações não autorizadas.

Filter Overrides
Agora é possível sobrescrever os filtros que se aplicam a uma determinada action ou controller especificando um conjunto de tipos de filtros que não devem ser executados em um determinado escopo (action ou controller).

Isso permite que sejam configurados os filtros que se aplicam globalmente, porém em seguida excluir determinados filtros globais da aplicação em actions ou controllers específicos.


Assista ao anuncio das novidades do ASP.Net feitas por Scott Hanselman

Resumo

Eu sempre considerei o ASP.Net MVC 4 uma versão excelente e completa, podemos notar que não foram anunciadas muitas novidades para a versão do ASP.Net MVC 5, afinal acredito que é difícil melhorar o que já era ótimo.

As mudanças em conjunto com o Visual Studio 2013 vão proporcionar mais facilidade e velocidade para criação de aplicações ASP.Net, as melhorias desta nova versão atendem diversas necessidades que eram contornadas de outras maneiras.

O Visual Studio 2013 com ASP.Net MVC 5 é um recente lançamento, pretendo abordar separadamente em artigos detalhados cada uma das novidades aqui listadas, continue acompanhado.

Referencias

Gostou do artigo? Compartilhe e deixe seu comentário abaixo 😉

ASP.Net MVC – Cuidado com links de exclusão “Delete” – Pode ser uma falha de segurança

ASP.Net MVC – Ao expor informações de um banco de dados, cuidado com o link do tipo “Delete”, siga essa dica para evitar uma falha de segurança em seu site.

Vamos supor que em nosso site ASP.Net MVC possuímos uma controller “FuncionarioController”, essa controller é responsável pelos métodos de CRUD da sua entidade Funcionario relacionada ao seu banco de dados.

Como o seu ActionResult de exclusão deveria estar escrito? Vamos observar este exemplo:

// GET: /Funcionario/Delete/5

public ActionResult Delete(int id = 0)
{
   Funcionario funcionario = db.Funcionario.Find(id);

   if (funcionario == null)
   {
      return HttpNotFound();
   }

   db.Funcionario.Remove(funcionario);
   db.SaveChanges();

   return RedirectToAction("Index");
}

Algo de estranho?
Teoricamente está tudo certo, o código está validando se o ID existe mesmo e caso não exista o usuário será redirecionando para uma página de erro, assim evitando em exibir mensagens de erro do banco de dados.

Mas nesse código habita uma grande falha de segurança, o ActionResult Delete é um método Get, ou seja, pode ser chamado diretamente de uma URL. O que aconteceria se alguém mal intencionado digitasse no browser a seguinte URL:

www.meusite.com.br/Funcionario/Delete/1

Provavelmente o registro de funcionário com o ID = 1 seria excluído certo?
“Ah, mas minha aplicação requer login e senha para esse tipo de ação.”

Isso não evita de receber um ataque, imagine que um usuário mal intencionado deseja deletar um registro e envia um e-mail para um usuário desse sistema com uma imagem “para parecer inofensivo” e nessa imagem contenha um link para a URL que citamos acima. Se o usuário que recebeu o e-mail e clicou estiver conectado (logado) no sistema naquele momento já seria o suficiente para concretizar a exploração dessa falha.

DICA

Nunca escreva seus métodos Get de exclusão realizando a exclusão direta da base.
A dica completa seria:
Nunca escreva nenhum método Get realizando alteração de informações do sistema.

Como resolver?

Vamos observar uma maneira indicada para evitar a falha citada:

    // GET: /Funcionario/Delete/5

    public ActionResult Delete(int id = 0)
    {
        Funcionario funcionario = db.Funcionario.Find(id);

        if (funcionario == null)
        {
            return HttpNotFound();
        }
        return View(funcionario);
    }

    // POST: /Funcionario/Delete/5

    [HttpPost, ActionName("Delete")]
    public ActionResult DeleteConfirmed(int id)
    {
        Funcionario funcionario = db.Funcionario.Find(id);
        db.Funcionario.Remove(funcionario);
        db.SaveChanges();

        return RedirectToAction("Index");
    }

Repare que existem dois métodos ActionResult para exclusão, o método Get Delete não realiza a exclusão do registro, apenas verifica se ele existe e redireciona o usuário para uma View de visualização e confirmação de exclusão:

ASP.Net MVC Exclusão

Ao realizar a confirmação dos dados e clicar em excluir a página será submetida via Post para o método DeleteConfirmed, que é responsável pela exclusão da base de dados.

Repare no código que um método chama-se Delete (Get) e o outro DeleteConfirmed (Post), repare também que existe um atributo ActionName(“Delete”) decorando o método DeleteConfirmed, isso significa que ele pode ser chamado como Delete, isso é necessário, pois o CLR (common language runtime) do .Net requer que haja apenas um método com a mesma assinatura, como os dois métodos recebem o mesmo tipo de parâmetro não seria possível possuírem o mesmo nome.

Utilizando o atributo ActionName(“Delete”)  faz que o roteamento do site aceite o método DeleteConfirmed como Delete quando uma URL que inclua o /Delete/ for acionada via Post.

Resumo

Essa técnica evita que de forma indesejável um registro seja manipulado e por mais que haja sucesso na tentativa do usuário mal intencionado o site resultará em uma página de confirmação, logo o usuário logado poderá intervir a essa tentativa de burlar o sistema.

Todas as controllers criadas automaticamente em projetos no Visual Studio, seja na criação do projeto ou via scaffolding já preveem essa técnica, caso você esteja criando suas controllers manualmente, lembre-se dessa dica 😉

Referência

Gostou do artigo, teve alguma dúvida? Deixe sua mensagem nos comentários abaixo.

Palestra sobre ASP.Net SignalR + Demos + Vídeo

Palestra sobre ASP.Net SignalR ministrada no Visual Studio Summit 2013.

ASP.Net SignalR

Desde que comecei a estudar ASP.Net SignalR me interessei muito e se tornou um dos meus assuntos favoritos, acompanhe aqui como foi minha palestra:

Vídeo da Palestra

Eu ainda não sou o bom palestrante que desejo ser, mas um dia chego lá 🙂

Slides

Demos (compatíveis com VS 2012)

*Jogo da velha original foi baixado aqui. Fiz melhorias, correções e complementos para demonstração.

Quer conhecer mais sobre ASP.Net SignalR? Leia o meu artigo aqui.

O Visual Studio Summit é um dos maiores eventos sobre desenvolvimento na plataforma Microsoft, assista todas palestras da edição 2013 aqui.

Deixe seu feedback logo abaixo 🙂
Abraços!

ASP.Net MVC – ViewData, ViewBag e TempData

ASP.Net MVC – ViewData, ViewBag e TempData entenda as diferenças.

Quando usar ViewData, ViewBag e TempData? Essa é uma das primeiras perguntas que qualquer desenvolvedor faz quando inicia nos aprendizados do ASP.Net MVC.

UPDATE – 13/06 – Adicionando detalhes/correções fornecidos pelo @vcavalcante

Vamos basear nossa explicação conforme a ilustração

ViewData, ViewBag, TempData

Similaridades entre ViewData e ViewBag

ViewData e ViewBag são similares nas seguintes características:

  • São utilizadas para persistir dados entre a Controller e a View correspondente.
  • A duração “tempo de vida” é apenas entre o envio através da Controller e a exibição na View, depois disso tornam-se nulas novamente.
  • No caso de um redirect se tornam nulas.

Diferenças entre ViewData e ViewBag

ViewData ViewBag
É um dicionário de objetos derivado de ViewDataDictionary e é acessível utilizando strings como chaves. É uma propriedade dinâmica baseada na funcionalidade “dynamic” do C# 4.0
Requer typecasting (conversão) quando associada a tipos complexos. Não necessida de conversão para tipos complexos.

Exemplos de aplicação

Controller

public class HomeController : Controller
{
    public ActionResult Index()
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = "Eduardo Pires",
                            Idade = 31
                        };

        // Propriedades "Dinâmicas"
        ViewBag.Funcionario = func;

        // Modo tradicional
        ViewData["Funcionario"] = func;

        return View();
    }
}

View

@model ProjetoModelo.Models.Funcionario;

@{
    ViewBag.Title = "Exemplo ViewData ViewBag";

    // Necessita de TypeCasting
    var viewDataVariavel = ViewData["Funcionario"] as Funcionario;

    // Não necessita de TypeCasting
    var viewBagVariavel = ViewBag.Funcionario;
}

Resumindo, ViewData e ViewBag possuem a mesma proposta, porém o ViewBag está disponível a partir do ASP.Net MVC 3, enquanto o ViewData existe desde a primeira versão.

OBS: O ViewData é um wrapper, uma implementação do ViewBag, pois utiliza o ViewBag internamente, portanto:

// Criar o ViewBag:
ViewBag.Teste = "Eduardo";

// É o mesmo que criar um ViewData["Teste"],
// pois o ViewData é utilizado internamente. Se chamarmos:

var teste = ViewData["Teste"]; // Teremos teste = "Eduardo";

Por este motivo ViewData é mais rápido que o ViewBag, porém essa diferença de velocidade é mínima, não é necessário deixar de usar o ViewBag por este motivo.

Eu preferencialmente sempre utilizo ViewBag

TempData

  • TempData assemelha-se mais a uma sessão de servidor, porém de curta duração.
  • Possui um tempo de vida maior que o ViewBag e ViewData, o TempData perdura desde sua criação até que seja chamado, ou seja, quando houver um request da informação do TempData, ele se tornará nulo novamente.
  • Uma informação em TempData criada em um Controller persiste após um redirect entre actions (apenas um) e pode ser exibido em sequência em uma View (muito usado em tratamento de erros).
  • Caso não seja chamado o TempData pode manter o estado de seus dados até que a sessão do usuário se encerre.
  • É utilizado para compartilhar informações entre Controllers.
  • O TempData salva suas informações no SessionState do servidor.
  • Após a leitura os dados do TempData são marcados para deleção, ou seja, no final do request todos os dados marcados serão deletados.
  • É um benefício quando necessário transmitir um volume de informações entre as Controllers sem se preocupar em zerar os valores, pois o TempData automaticamente faz isso.

Exemplo de aplicação

Controller

public class HomeController : Controller
{
    [HttpPost]
    public ActionResult CriarFuncionario(Candidato cd)
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = cd.Nome,
                            Idade = cd.Idade
                        };

        // Pertistir dados até o próximo request.
        TempData["Funcionario"] = func;

        // Redirect entre Controllers
        return RedirectToAction("CriarBeneficiosFuncionario");
    }

    [HttpGet]
    public ActionResult CriarBeneficiosFuncionario()
    {
        // Validando se está vazio
        if (TempData["Funcionario"] != null)
        {
            // Necessário TypeCasting para tipos complexos.
            var func = TempData["Funcionario"] as Funcionario;
        }

        return View();
    }
}

Neste exemplo pudermos entender que o propósito do TempData é compartilhar dados entre Controllers, portanto sua duração persiste até que a informação seja lida.
Outro detalhe é sempre checar se o TempData não está nulo.

Caso você queira manter o dado de um TempData mesmo após a leitura, basta chamar o método Keep(), assim o dado será persistido novamente até a próxima requisição.

// Mantendo o dado do TempData até a próxima leitura (requisição).
TempData.Keep("Funcionario");

// Removendo o dado do TempData desta e da próxima requisição.
TempData.Remove("Funcionario");

Recomenda-se utilizar sempre ViewBag e ViewData para transferência de dados entre Controller e View. O TempData em Views é recomendado no caso de um dado necessitar ser redirecionado entre Actions e posteriormente ser exibido numa View (ViewBag e ViewData são anulados em redirects).
Um caso comum dessa aplicação é no tratamento de erros, veja aqui um exemplo.

Espero ter esclarecido as diferenças e características de ViewData, ViewBag e TempData. Caso tenha alguma dúvida ou queira comentar algo, deixe seu recado logo abaixo 😉

Referências

Vou palestrar no evento de 10 anos do Codificando.Net

Olá Pessoal,

O Codificando.Net é uma das maiores comunidades de desenvolvedores de software e está comemorando seus 10 anos com um evento presencial.

O evento terá diversas apresentações sobre Desenvolvimento Web, SQL, Business Intelligence e Cloud Computing.

O tema da minha palestra será Comunicação em tempo real usando ASP.NET SignalR

Esta é mais uma ótima oportunidade de aprender, conhecer as novidades, fazer contatos e trocar conhecimentos com a comunidade técnica.

Informações

O dinheiro arrecadado com as inscrições do evento, cobrirão o coffee-break e a compra de alimentos não perecíveis para doação à instituição de caridade (à definir).

Espero você lá!