Visual Studio Summit 2014 – Novidades do ASP.NET MVC 5.x – Palestra + Vídeo

No sábado dia 26/04/14 aconteceu a terceira edição do Visual Studio Summit, um evento que eu participo como organizador e palestrante.

Sobre o Visual Studio Summit 2014

O Visual Studio Summit é o maior evento de desenvolvedores Microsoft do Brasil, ocorre pelo terceiro ano consecutivo na Sede da Microsoft Brasil na capital de São Paulo.

Eu tenho um grande prazer de atuar na organização deste evento ao lado do mestre Ramon Durães, meses antes do evento nós já estamos trabalhando para oferecer a melhor experiência possível para toda a comunidade técnica.

Alguns números sobre o evento

  • Palestrantes: 28
  • Staff apoio operação: 8
  • Palestras: 79 palestras 
  • Total de horas de conteúdo: 39.5 horas  
  • Salas: 6 simultâneas e 3 salas Ask the Expert.

Minha Palestra

A palestra apresentada nesta edição foi “Novidades do ASP.NET MVC 5.x” onde eu abordei todas as atualizações desde a versão do ASP.NET MVC 5.

Como a versão do Visual Studio Summit 2014 não foi gravada eu fiz questão de regravar minha palestra em casa e disponibilizar para quem não viu ou quer ver de novo, só que agora com 1h00 de duração e mais detalhes no conteúdo.

Segue minha apresentação de slides também para acompanhar o tema

Durante o lançamento da versão do ASP.NET MVC 5 eu escrevi alguns artigos relacionados

Gostaria de agradecer a todos presentes, palestrantes e staffs, especialmente o time de MSP’s e MTACs que foram indicados pela Microsoft para apoiar a realização do evento. Todos foram muito prestativos, educados e dedicados. Parabéns a vocês!

Aguardo você na próxima edição 😀

Links para seguir

Campus Party 2014 – Palestra sobre ASP.NET

No dia 31/01 eu tive o prazer de palestrar na Campus Party 7 – Edição 2014 / SP meu tema foi sobre ASP.NET, novidades, tendências e mobilidade.

Para quem não sabe a Campus Party é o maior evento tecnológico do mundo, ela atrai anualmente geeks, nerds, empreendedores, gamers, cientistas e muitos outros criativos que reúnem-se para acompanhar centenas de atividades sobre Inovação, Ciência, Cultura e Entretenimento Digital.

Foi o maior evento onde palestrei, fico muito satisfeito em ter palestrado no mesmo evento que meu ídolo Bruce Dickinson 😉

Motivos não faltaram para eu compilar e buscar compartilhar o máximo de informações possíveis sobre a plataforma ASP.NET, minha palestra foi na virada da madrugada, mas mesmo assim o público foi chegando e quando notei a audiência estava ótima!

Ao finalizar minha apresentação o retorno também foi ótimo, recebi muitos feedbacks positivos, tirei bastante dúvidas e conversei com o pessoal que ficou para continuar o assunto comigo fora do palco.

Disponibilizo para visualização os slides que utilizei em minha palestra.

Com certeza estarei de volta na Campus Party ano que vem, espero que me apresentando novamente também.

Acompanhe e conheça mais o evento no site oficial da Campus Party.

Abraços!

ASP.NET MVC 5.1 – O que mudou?

Foi anunciado em 20/01/2014 o release do ASP.NET MVC 5.1 que chegou com boas novidades e atualizações, na mesma data o Visual Studio recebeu o Update 1, confira em detalhes.

ASP.NET MVC 5.1

Requerimentos de Software

Download

A release do ASP.NET MVC 5.1 foi liberada como um pacote disponível na galeria NuGet. Todos os pacotes sequem a especificação Semantic Versioning, por exemplo o ASP.NET MVC 5.1 RTM tem a seguinte versão: “5.1.0”.

Para facilitar mais você ainda pode utilizar o NuGet Package Manager Console com o seguinte comando:

Install-Package Microsoft.AspNet.Mvc -Version 5.1.0

Documentação

Tutoriais e outras informações sobre o ASP.NET MVC 5.1 estão disponíveis no site oficial do ASP.NET (http://www.asp.net)

Novidades no ASP.NET MVC 5.1

Melhorias no Attribute routing

O Attribute Routing agora suporta restrições, permitindo o versionamento e header baseado na seleção da rota. Muitos aspectos de attribute routes podem agora ser customizados via a interface IDirectRouteFactory e a classe RouteFactoryAttribute.

Suporte a Enum nas views

  1. Novo helper @Html.EnumDropDownListFor() Pode ser usado como a maioria dos HTML helpers com a ressalva que a expressão precisa ser avaliada como um tipo de Enum ou um Nullable<T> onte T é um tipo de enun. Utilize EnumHelper.IsValidForEnumHelper() para verificar estes requerimentos.
  2.  

  3. Novo método EnumHelper.GetSelectList() qual retorna um IList<SelectListItem>.
    Isto é útil quando você precisa manipular uma select lista antes de chamá-la, por exemplo um @Html.DropDownListFor(), ou quando você desejar exibir os nomes que o @Html.EnumDropDownListFor() mostra.

O código a seguir demonstra como aplicar:

@if (EnumHelper.IsValidForEnumHelper(ViewData.ModelMetadata))
{
    @Html.EnumDropDownListFor(model => model, htmlAttributes: new { @class = "form-control" })
}
@if (EnumHelper.IsValidForEnumHelper(ViewData.ModelMetadata))
{
    foreach (SelectListItem item in EnumHelper.GetSelectList(ViewData.ModelMetadata,
	(Enum)Model)) { … }
}

Você pode conferir um exemplo completo aqui.

suporte a Bootstrap em editor templates

Agora é possível passar no EditorFor um atributo HTML como um objeto anônimo:

Exemplo:

@Html.EditorFor(model => model, new { htmlAttributes = new { @class = "form-control" }, })

Validação não intrusiva para MinLengthAttribute e MaxLengthAttribute

Validações client-side para string e arrays agora são suportadas para as propriedades decoradas com os atributos MinLength e MaxLength.

Supporte ao contexto ‘this’ no Ajax não intrusivo

As funções de callback (OnBegin, OnComplete, OnFailure, OnSuccess) agora estão habilitadas a localizar o elemento da invocação através do contexto ‘this’. Exemplo:

@Ajax.ActionLink("Click me", "AjaxAction", new AjaxOptions { UpdateTargetId = "foo", OnBegin = "OnClick" })

<script>
    function OnClick(jqXHR) {
        if ($(this).hasClass("foo")) {
            jqXHR.setRequestHeader("custom-header", "value");
        }
    }
</script>

Problemas Conhecidos e Mudanças Significativas

Attribute Routing

Ambiguidades nas correspondências de attribute routing agora irão reportar um erro em vez de escolher a primeira correspondência.

Attribute Routes estão proibidos de usar o parâmetro {controller} e de usar o parâmetro {action} em rotas colocada em actions. O uso destes parâmetros muito provavelmente levará a gerar ambiguidades.

utilizar Scaffolding de MVC/Web API em um projeto com pacotes 5.1 resultará em pacotes 5.0 para aqueles que ainda não existem no projeto.

Atualizar para ASP.NET MVC 5.1 através dos pacotes NuGet não atualiza as ferramentas como Scaffolding ou o template de ASP.NET Web Application.

Eles usam uma versão anterior do ASP.NET (5.0.0.0). Como resultado o Scaffolding irá instalar os pacotes antigos (5.0.0.0) como pacotes requeridos se ainda não estiverem disponíveis em seu projeto. Entretanto o Scaffolding do Visual Studio 2013 RTM ou Update 1 não sobrescreve os últimos pacotes em seu projeto.

Se você usar Scaffolding após ter atualizados os pacotes em seu projeto para Web API 2.1 ou ASP.NET MVC 5.1, confira se as versões estão consistentes.

Syntax Highlighting para Razor Views no Visual Studio 2013

Se você atualizar para o ASP.NET MVC 5.1 RTM sem atualizar o Visual Studio 2013, você não conseguirá o suporte no editor para o syntax highlighting enquanto estiver editando as Razor Views, você precisará atualizar o Visual Studio 2013 para obter este suporte.

tipos renomeados

Alguns dos tipos (types) utilizados para a extensibilidade do attribute routing foram renomeados na versão do ASP.NET MVC 5.1 RTM.

Nome do Tipo Antigo (5.1 RC) Novo Nome do Tipo (5.1 RTM)
IDirectRouteProvider IDirectRouteFactory
RouteProviderAttribute RouteFactoryAttribute
DirectRouteProviderContext DirectRouteFactoryContext

Correções de Bugs

O time do ASP.NET realizou a correção de diversos bugs da versão anterior como parte deste release (ASP.NET MVC 5.1 RTM). Confira a lista completa de todos os bugs corrigidos (e outros ainda em andamento) aqui.


Estas são todas as novidades da versão ASP.NET MVC 5.1, lembre-se de atualizar a sua versão do Visual Studio 2013 para o melhor proveito das novidades.

Em breve publicarei um artigo sobre as novidades do ASP.NET WebAPI 2.1.

Referências

Até a próxima 😉

Workshop de ASP.Net MVC 5 – Microsoft Technology Center

Foi realizado no dia 09/09 o Workshop de ASP.Net MVC 5 Fundamentals no Microsoft Technology Center (MTC) em São Paulo, onde foi realizada uma imersão de alto impacto para profissionais da área.

ASP.Net MVC 5 Fundamentals

Compartilho que tive o prazer de ministrar e conduzir o conteúdo técnico deste workshop exclusivo, cerca de 20 profissionais se inscreveram e compareceram para uma imersão completa ao ASP.Net MVC, profissionais de diversas áreas de TI, em sua maioria desenvolvedores.

O conteúdo do workshop abordou toda a trajetória do ASP.Net onde foram feitas comparações técnicas entre WebForms e MVC. Benefícios e diferenças do padrão MVC foram colocadas em destaque para que os profissionais pudessem descobrir as inúmeras vantagens em optar pelo ASP.Net MVC em seus projetos.

ASP.Net MVC 5 Fundamentals

O ASP.Net MVC 5 é uma das novidades que acompanham o lançamento do Visual Studio 2013, escrevi um artigo dedicado a esse assunto, no workshop os profissionais além de serem apresentados aos conceitos do padrão MVC também conheceram todas as novidades presentes no ASP.Net MVC 5 em conjunto com o Visual Studio 2013.

ASP.Net MVC 5 Fundamentals

Foram 8 horas de apresentação de conteúdos que proporcionaram um conhecimento geral, foram eles:

  • Controllers
  • Views
  • Models
  • Bootstrap
  • HTML Helpers
  • Data Annotations e Validation
  • Rotas
  • jQuery, JSON e Ajax
  • OutputCache
  • View Model e AutoMapper
  • ASP.Net Identity
  • Segurança
  • One ASP.Net
  • Filters Overrides
  • Authentication Filters

Foi muito bom interagir e conhecer novos profissionais da área, seus projetos, experiências, poder compartilhar conhecimento e claro apresentar as novidades.

O workshop foi organizado e realizado pelo Ramon Durães – 2PC, onde fui convidado a conduzir o conteúdo, registro aqui minha satisfação pelo convite.

ASP.Net – Web Application Projects x Web Site Projects

No Visual Studio, você pode criar Web Application Projects ou Web Site Projects. É melhor escolher o tipo certo antes de criar um projeto web, porque pode ser demorado, difícil e propenso a erros para depois converter de um tipo para o outro.

Web Application Project

Web Application Project ou Web Site Project? Estas duas opções de criar uma aplicação web costumam gerar diversas dúvidas e problemas. Este artigo aborda todas as vantagens e desvantagens de cada uma para que a melhor escolha seja tomada conforme o seus cenários e necessidades.

Nota
Para um novo desenvolvimento é recomendado que seja escolhido o Web Application Project. Este artigo explica que Web Site Projects possuem algumas vantagens, mas muitos desenvolvedores que escolhem Web Site Projects, eventualmente descobrem que as desvantagens superam as vantagens percebidas. Além disso, à medida que novos recursos ASP.Net são desenvolvidos eles não vão estar sempre disponíveis para Web Site Projects. Por exemplo, a versão do Visual Studio 2013 possui novas ferramentas para a criação de projetos web e esta nova ferramenta vai trabalhar apenas com Web Application Projects. Para mais informações consulte Creating an ASP.NET Web Project in Visual Studio 2013.

Este artigo contém as seguintes seções:

Cenários

Cenários em que os Web Application Projects são uma escolha indicada incluem as condições:

    • Você quer ser capaz de usar o recurso Edit and Continue característico do depurador do Visual Studio.
    • Você deseja executar testes de unidade em código que está nos arquivos de classe que estão associados a páginas ASP.Net.
    • Você quer se referir às classes que estão associadas com as páginas e user controls a partir de classes standalone.
    • Você quer estabelecer dependências do projeto entre vários projetos web.
    • Você quer que o compilador crie um assembly único para todo o site.
    • Você quer controle sobre o nome do assembly e número de versão que é gerado para o site.
    • Você quer usar MSBuild ou Team Build para compilar o projeto. Por exemplo, você pode querer adicionar passos prebuild e postbuild.
    • Você quer evitar colocar o código-fonte em um servidor de produção.

Cenários em que Web Site Projects são uma escolha indicada incluem as condições:

    • Você deseja incluir o código C # e Visual Basic em um único projeto web. (Por padrão, uma aplicação web é compilada com base em configurações de idioma no arquivo de projeto. Exceções podem ser feitas, mas é relativamente difícil.)
    • Você deseja abrir o site em produção no Visual Studio e atualizá-lo em tempo real, utilizando FTP.
    • Você não quer ter que compilar explicitamente o projeto.
    • Se você pré-compilar o site, você quer que o compilador crie vários assemblies para o site, que pode incluir um assembly por página ou controle de usuário, ou um ou mais assemblies por pasta.
    • Você quer ser capaz de atualizar arquivos individuais na produção copiando apenas novas versões para o servidor de produção, ou editando os arquivos diretamente no servidor de produção.
    • Se você pré-compilar o site, você quer ser capaz de atualizar páginas da Web ASP.NET. Individuais (aspx) sem ter que recompilar todo o site.
    • Você gosta de manter seu código fonte no servidor de produção, pois pode servir como uma cópia de segurança adicional.

Resumo das Diferenças

A tabela a seguir resume as principais diferenças.

Área Web Application Projects Web Site Projects
Estrutura do arquivo de projeto
  • Um arquivo de projeto Visual Studio (. Csproj ou. Vbproj) armazena informações sobre o projeto, tais como a lista de arquivos que estão incluídos no projeto, e todas as referências de projeto a projeto.
  • Não há nenhum arquivo de projeto (. Csproj ou. Vbproj). Todos os arquivos em uma estrutura de pastas são automaticamente incluídas no site.
Compilação
  • O código fonte é compilado no computador que é usado para o desenvolvimento ou source control.
  • Por padrão, a compilação de arquivos de código (excluindo. Arquivos.ascx aspx e.) Produz um único assembly.
  • O código-fonte é normalmente compilado dinamicamente (automaticamente) pelo ASP.NET no servidor pela primeira vez quando um request é recebido depois que o site foi instalado ou atualizado. É possível pré-compilar o site (compilar com antecedência em um computador de desenvolvimento ou no servidor).
  • Por padrão, a compilação produz múltiplos assemblies.
Namespaces
  • Namespaces explícitos são adicionados a páginas, controles e classes por padrão.
  • Namespaces explícitos não são adicionados a páginas, controles e classes por padrão, mas você pode adicioná-los manualmente.
Desenvolvimento
  • Você copia o assembly para o servidor. O assembly é produzido através da compilação do aplicativo.
  • O Visual Studio fornece ferramentas que se integram com Web Deploy (ferramenta de deploy para IIS) para automatizar muitas tarefas de implantação.
  • Você copia os arquivos de origem do aplicativo em um computador que tem o IIS instalado.
  • Se você pré-compilar o site em um computador de desenvolvimento, você pode copiar os assemblies produzidas por compilação para o servidor IIS.
  • O Visual Studio fornece ferramentas que se integram com Web Deploy (ferramenta de deploy para IIS) para automatizar muitas tarefas de implantação.

Estrutura de Arquivos

Web Application Projects usam arquivos de projeto do Visual Studio (. Csproj ou. Vbproj) para acompanhar as informações sobre o projeto. Isso torna possível especificar quais arquivos são incluídos ou excluídos do projeto e, portanto, os arquivos que são criados durante uma compilação.

Para Web Site Projects todos os arquivos em uma estrutura de pastas são automaticamente considerados para serem incluídos no site. Se você quiser excluir algo da compilação, você deve remover o arquivo da pasta do projeto do web site ou alterar a sua extensão de nome de arquivo para uma extensão que não é compilado e não é enviado ao IIS.

Uma vantagem de usar arquivos de projeto em Web Application Projects é o seguinte:

  • É fácil de remover temporariamente os arquivos do site, mas ainda certificar-se de que você não perdê-los, porque eles permanecem na estrutura da pasta. Por exemplo, se uma página não está pronta para ser implantada, você pode excluí-la temporariamente a partir da compilação sem excluí-la da estrutura da pasta. Você pode implantar o assembly compilado e em seguida incluir o arquivo no projeto novamente. Isto é especialmente importante se você estiver trabalhando com um repositório de source control.

Uma vantagem de usar estrutura de pastas sem arquivos de projeto em Web Site Projects é o seguinte:

  • Você não tem que gerenciar a estrutura do projeto exclusivamente no Visual Studio. Por exemplo, você pode copiar os arquivos para o projeto ou excluí-los do projeto usando o File Explorer.

Compilação

Para Web Application Projects, você normalmente pode compilar o projeto no Visual Studio ou usando um ASP.Net batch compiler em um computador que não é o servidor IIS de produção. Todos os arquivos de classe code-behind e arquivos de classe standalone no projeto são compilados em um único assembly, que é então colocado na pasta Bin do Web Application Projects. (Os arquivos. Aspx e. Ascx são compilados dinamicamente de forma semelhante ao que é feito para Web Site Projects.)

Para Web Site Projects, você não tem que compilar manualmente o projeto. Web Site Projects normalmente são compilados dinamicamente pelo ASP.NET (tanto no computador de desenvolvimento e servidor IIS de produção). Você pode escolher entre o modo de compilação em lotes, que normalmente produz um assembly por pasta e modo de compilação fixa, que normalmente produz um assembly para cada página ou user control.

Vantagens do modelo de compilação de Web Application Projects incluem o seguinte:

    • Você pode usar o MSBuild para criar um custom batch-compilation process.
    • É fácil especificar os atributos do assembly, tais como nome e versão.
    • Compilando com antecedência garante que os usuários não tenham que esperar enquanto o site compila no servidor de produção. (Se o site é muito grande, compilação dinâmica de um Web Site Project pode levar uma quantidade considerável de tempo. Compilação dinâmica ocorre quando um request para um site é recebido após uma atualização, o request que desencadeia a compilação pode ser retardado enquanto os recursos necessários são compilados. Se o atraso for inaceitável, é possível pré-compilar o site. No entanto, em seguida, algumas das vantagens da compilação dinâmica são perdidas.)
    • Você tem o controle completo sobre onde colocar os arquivos de código fonte na estrutura de pasta do projeto e como as classes no projeto referem-se uns aos outros. (Compilação dinâmica requer que o código fonte para todas as classes que são usados em todo o site deve estar na pasta App_Code).

Vantagens do modelo de compilação para Web Site Projects incluem o seguinte:

    • Você pode testar as páginas específicas, independentemente do estado de outras páginas. Isso ocorre porque a rodar uma página individual não requer que todo o site seja compilado com sucesso, apenas a página e quaisquer componentes que depende, como o código na pasta App_Code ou no Global.asax. (Em um Web Application Project, se houver erros de compilação em qualquer lugar do site, você não pode criar os assemblies e, portanto, não pode testar até mesmo as partes do site que compilaram.)
    • É fácil atualizar um site em produção. Você pode atualizar os arquivos de código fonte individuais no servidor de produção sem ter que recompilar explicitamente o site. Você pode atualizar arquivos individuais que estão prontos para a implantação, mesmo que outros arquivos não estejam prontos devido a erros de compilação. Você também pode abrir o site no servidor IIS de produção diretamente no Visual Studio e atualizar o site em tempo real.
    • Pré-compilação de vários assemblies pode ter uma vantagem de desempenho em alguns cenários. Um exemplo típico é um site que tem muitas páginas com um monte de código escrito para eles. A maioria das páginas raramente são solicitadas e só algumas são usadas com freqüência. Se você compilar um site como este em várias assemblies o servidor de produção pode carregar apenas os assemblies que são necessários para as requisições atuais. Se uma página não é solicitada, a sua assembly correspondente não será carregada.
Nota
Não há diferença de desempenho entre um Web Site Project e um Web Application Project. As únicas exceções significativas são as que já foram observadas e por uma questão prática que se aplicam apenas aos sites muito grandes. O primeiro request para o web site pode requerer o site a ser compilado, o que pode resultar em um atraso. Se o site está sendo executado em um servidor IIS que possui pouca memória, possuindo todo o site em um único assembly pode usar mais memória do que seria necessário para vários assemblies.

Deploy

Para realizar o deploy de um Web Application Project, você pode copiar o assembly que é criado ao compilar o projeto para um servidor IIS. Em contraste, para realizar o deploy de um Web Site Project, você pode normalmente copiar os arquivos de origem do projeto para um servidor IIS. (Qualquer uma destas tarefas pode ser feita manualmente ou através de ferramentas de deploy).

Vantagens da estratégia de deploy de Web Application Projects incluem o seguinte:

    • Evitar a exposição de código-fonte no servidor IIS. Em alguns cenários, tais como ambientes de hospedagem compartilhada, você pode estar preocupado com o acesso não autorizado ao código fonte no servidor IIS. (Para um Web Site Project, você pode evitar este risco pré-compilando em um computador de desenvolvimento e realizando o deploy dos assemblies gerados em vez do código fonte. Entretanto, nesse caso, você perde alguns dos benefícios de facilidade de atualizações do site).
    • O deploy muitas vezes envolve outras tarefas além de copiar assemblies ou código para um servidor. Por exemplo, os scripts de banco de dados podem precisar serem executados em produção e connection strings no arquivo Web.config podem precisar serem alteradas para um servidor de produção. O Visual Studio fornece ferramentas que com um clique publicam que trabalham com Web Application Projects para automatizar muitas destas tarefas. Essas ferramentas não estão disponíveis para Web Site Projects.

Vantagens da estratégia de deploy para Web Site Projects incluem o seguinte:

    • Se você fizer uma pequena mudança em um site, você não tem que realizar o deploy de todo o site. Em vez disso, pode copiar apenas o arquivo alterado para o servidor IIS de produção. Você também pode editar arquivos diretamente no servidor de produção. (Como os arquivos de código fonte de um Web Application Projects são compilados em um único arquivo assembly, você deve realizar o deploy de todo o site, mesmo para pequenas mudanças, a menos que a única mudança é para um arquivo aspx ou ascx).

Fonte

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 😉

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 😉