Desenvovedores web correndo atrás das novidades A versão 1.0 do ASP.Net MVC foi lançada seis meses atrás. Todo mundo ainda está pegando o jeito do novo framework web da Microsoft, ainda está se acostumando, que eu acho que a maioria não percebeu que eles estão tão ativos no desenvolvimento do framework que já lançaram, dois meses atrás, o primeiro preview da versão 2. As coisas andam rápido, não é?

Essa história toda de versões é um pouco confusa, então vou tentar explicar um pouco para deixar claro em que pé estamos:
A versão 2.0 é a versão que virá instalada por padrão no Visual Studio 2010, segundo dizem alguns funcionários da Microsoft. Não sei se seremos capazes de trabalhar também com a versão 1.1 no Visual Studio 2010, mas imagino que sim. A versão 1.1 é absolutamente idêntica com relação a funcionalidades à versão 1.0, mudando apenas a versão do .Net Framework, que na versão 1.0 utiliza o 3.5SP1, e na versão 1.1 o 4.0 é utilizado. A versão 1.1 foi liberada para trabalhar já com o Visual Studio 2010 Beta 1, e pode ser baixada desde junho, já que o Beta 1 do VS 2010 não possuía nenhuma versão do ASP.Net MVC. O Beta 2 já vai ter uma versão dele, já no preview 2, ou seja, se tudo estiver certo, teremos o preview 2 sendo lançado entre o fim de Outubro e começo de Novembro (lançamento do Beta 2). Update: errei feio, lançado em 30 de Setembro.

Este post é o primeiro de alguns onde vou abordar o primeiro preview da versão 2 do ASP.Net MVC. Neste post vou começar falando de algo muito esperado: áreas! Mas antes disso é bom dizer que a instalação do ASP.Net MVC 2P1 é segura, e pode ser instalada lado a lado da versão 1.0. Ela também não pode ser instalada no VS 2010, só no VS 2008.

Áreas é algo muito útil, que já vinha sendo implementado por alguns componentes open source no mercado, já para a versão 1.0 no ASP.Net MVC. A Microsoft resolveu incluir isso então na v2. Basicamente, áreas suportam nativamente urls mais simpáticas, como /Area1/Controlador1, e /Area2/Controlador1, algo antes só possível de ser feito com algum hack no ASP.Net Routing.

Pra fazer uma estrutura de áreas, neste primeiro preview, você cria pelo menos dois projetos ASP.Net MVC, um é o pai, e o outro é o filho, que vai conter a área. Você pode criar quantas áreas quiser. Aqui, por exemplo, criei o pai (MVC2Application1) e dois filhos (Area1 e Area2):

Estrutura de projeto de áreas

Vejam que os scripts, css, views, controllers, e global.asax não estão nos projetos de área. Fiz também uma referência do projeto principal para os dois filhos.

Incluí então alguns controladores e visões. Deixei tudo muito simples, os controladores e visões são iguaizinhos nos dois projetos de área, mudando só o namespace. Vejam o controlador:

public class Controller1Controller : Controller
{
    public ActionResult Index()
    {
        return View();
    }
    public ActionResult Acao1()
    {
        return View();
    }
    public ActionResult Acao2()
    {
        return View();
    }
}

Essa é uma das views:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>
<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    Acao1
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2>Area1 - Acao1</h2>
    <%= Html.ActionLink("Index", "Index")%>
    <%= Html.ActionLink("Acao 2", "Acao2") %>
</asp:Content>

Sem novidades. Código padrão ASP.Net MVC. Vejam que há links entre as views, mas esses links direcionam às mesmas views.

Quero ser capaz de linkar da minha área padrão para outras, daí acrescentei o seguinte à minha view Index do projeto padrão:

<%= Html.ActionLink("Home", "Index", "Home", new { area = "Rota padrão" }, null)%><br />
<%= Html.ActionLink("Área 1", "Index", "Controller1", new { area = "Area1" }, null)%><br />
<%= Html.ActionLink("Área 2", "Index", "Controller1", new { area = "Area2" }, null)%><br />
<%= Html.ActionLink("Área 1 - Acao 1", "Acao1", "Controller1", new { area = "Area1" }, null)%><br />
<%= Html.ActionLink("Área 1 - Acao 2", "Acao1", "Controller1", new { area = "Area1" }, null)%><br />
<%= Html.ActionLink("Área 2 - Acao 1", "Acao1", "Controller1", new { area = "Area2" }, null)%><br />
<%= Html.ActionLink("Área 2 - Acao 2", "Acao2", "Controller1", new { area = "Area2" }, null)%>

Precisamos agora configurar as rotas. Precisamos informar como configurar as áres. O código vai no método RegisterRoutes, no global.asax.cs, no lugar do código anterior, você coloca esse (não precisa excluir o código de IgnoreRoute):

routes.MapAreaRoute(
    "Area2",
    "Rota area 2",
    "MinhaArea2/{controller}/{action}/{id}",
    new {controller = "Home", action = "Index", id = ""},
    new[] {"Area2.Controllers"}
    );

routes.MapAreaRoute(
    "Area1",
    "Rota area 1",
    "Area1/{controller}/{action}/{id}",
    new {controller = "Home", action = "Index", id = ""},
    new[] {"Area1.Controllers"}
    );

routes.MapAreaRoute(
    "Main",
    "Rota padrão",
    "{controller}/{action}/{id}",
    new {controller = "Home", action = "Index", id = ""},
    new[] { "Mvc2Application1.Controllers" }
    );

Dessa forma, as novas rotas ficam configuradas pra trabalhar com áreas. Vejam que para a área 1, usei a url /Area1, mas pra área 2 usei a url /MinhaArea2. O novo código utiliza um método chamado MapAreaRoute, em vez do método MapRoute que existia antes.

É importante que você coloque o mapeamento das áreas filhas antes do mapeamento padrão de rotas. O mapeamento padrão é “{controller}/{action}/{id}”, se você colocar fora de ordem, as rotas filhas nunca vão ser encontradas, já que rotas são avaliadas na ordem em que são registradas. Isso significa que se mapear primeiro a rota padrão, ao chamar /Area2/Controller1/Acao1, em vez de bater com a área correta, vai bater com a rota padrão, e mapear “Area2” como o controller, “Controller1” como ação, e “Acao1” como id.

Agora a cola final. Para tudo isso funcionar, você precisa descarregar o projeto:

Descarregando o projeto 

Editá-lo:

Editando o projeto 

E onde estava comentado, descomentar:

<!-- To enable MVC area subproject support, uncomment the following two lines:
-->
<UsingTask TaskName="Microsoft.Web.Mvc.Build.CreateAreaManifest" 
    AssemblyName="Microsoft.Web.Mvc.Build, 
    Version=2.0.0.0, Culture=neutral, 
    PublicKeyToken=31bf3856ad364e35" />
<UsingTask TaskName="Microsoft.Web.Mvc.Build.CopyAreaManifests" 
    AssemblyName="Microsoft.Web.Mvc.Build, 
    Version=2.0.0.0, Culture=neutral, 
    PublicKeyToken=31bf3856ad364e35" />

Você também precisa descomentar o seguinte xml. Se for do projeto pai, descomente esse:

<!-- If this is an area parent project, uncomment the following lines:
-->
<CreateAreaManifest AreaName="$(AssemblyName)" AreaType="Parent" 
AreaPath="$(ProjectDir)" ManifestPath="$(AreasManifestDir)" ContentFiles="@(Content)" />
<CopyAreaManifests ManifestPath="$(AreasManifestDir)" CrossCopy="false" RenameViews="true" />

Senão, descomente esse:

<!-- If this is an area child project, uncomment the following line:
-->
<CreateAreaManifest AreaName="$(AssemblyName)" AreaType="Child" 
AreaPath="$(ProjectDir)" ManifestPath="$(AreasManifestDir)" ContentFiles="@(Content)" />

Depois recarregue o projeto. Se ele perguntar como você deve recarregar o projeto, escolha recarregar normalmente.

Isso é tudo. Rode, e vai funcionar.

Vejam aqui como o método Html.ActionLink funcionou conforme o esperado, criando o link corretamente:

Áreas linkando conforme o esperado

Aqui podemos ver dentro de uma área. O ActionLink agora aponta para a própria área, se eu não informar nenhuma. O código deste ActionLink é:

<%= Html.ActionLink("Acao 2", "Acao2") %>

Áreas sendo exibidas

Tem alguns bugzinhos, mas nada de mais, que impeça o uso. Vou reportar lá no Connect. Experimentem, está ficando bem legal. Se você quiser, também pode baixar o fonte do Preview 2 lá no Codeplex.

Neste momento, o processo de utilização de rotas está muito manual. Temos que descarregar projeto, editar o csproj, etc. Ainda que isso só seja feito uma única vez para cada rota, tenho certeza que até a versão final isso deve passar a ter um suporte melhor do Visual Studio. Outra coisa que o time está olhando é a utilização de áreas com um único projeto, sem precisar criar projetos adicionais para isso.

O que acharam?


Postado na(s) categoria(s) ASP.Net MVC pelo Giovanni Bassi em 28 de setembro de 2009 às 03:36 | Tags: ,

Comentários


setembro 28. 2009 14:33
Rafael Noronha
Giovanni,

Penso que existem recursos bem interessantes que infelizmente a comunidade não parece estar interessada. Consequentemente estes recursos vão ficando de fora do Asp Net Mvc.

Destaco entre estes recursos uma maior aproximação de conceitos ROA e também uma interface que permita responder a diferentes clientes de modo transparente (html, xml, json, etc).

Estes recursos, entre outros, existem hoje na plataforma Ruby on Rails, que ao meu ver vai se firmando cada vez mais como a tecnologia mais preparada para absorver as novas tendêcias da web.

Para dar sustentação a esta minha visão, o pessoal do Rails já está se aproximando do HTML 5 no desenvolvimento do Rails 3.0.

http://rafanoronha.net/http://rafanoronha.net/


setembro 28. 2009 14:38
Giovanni Bassi
Rafael,

É verdade, o ASP.Net MVC não tem o suporte tão completo a multiplos formatos da mesma forma que o rails tem. Mas ainda é versão 1.0, né? Ele suporta, mas vc tem que fazer na mão. Na prática, basta retornar um ActionResult customizado. Ele já tem o JsonResult, por exemplo.

http://unplugged.giggio.net/http://unplugged.giggio.net/


setembro 28. 2009 15:05
Rafael Noronha
Em relação a ROA, algo bastante simples mas que acho muito interessante no Rails é a facilidade de se modelar rotas, integrando com transparência as urls, o http e o ciclo de requisições de uma aplicação.

Seguindo o link abaixo pode-se ter uma idéia deste recurso:
guides.rubyonrails.org/routing.html

http://rafanoronha.net/http://rafanoronha.net/

Comentar


(Vai mostrar seu Gravatar)

  Country flag

biuquote
  • Comentário
  • Pré-visualização
Loading



Quem é Giovanni Bassi

Giovanni Bassi Sou uma pessoa apaixonada por tecnologia e especificamente por .Net. Sou consultor independente especialista em .Net, focado em arquitetura e melhores práticas. Tenho dezenas de artigos publicados na .Net Magazine, revista da qual sou editor técnico. Ministro palestras e cursos de vez em quando, e quando dá tempo eu respiro um pouco. Mais detalhes nesta página.

Busca

Selos

Eu vou ao TechEd Brasil 2010, e você?

MVP

MCPD

MCSD

.Net Magazine

Abaixo ao if!

Calendário

«  julho 2010  »
seteququsedo
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678
Ver detalhamento de posts no calendário

Blogs interessantes

    OPMLDownload OPML file

    Postagens recentes

    Comentários recentes

    Disclaimer / Aviso
    As opiniões colocadas neste blog são minhas e pessoais e não expressam necessariamente as opiniões de meus empregadores, pareceiros e amigos. Da mesma forma, os comentários feitos por leitores do blog não expressam a minha opinião.

    © Copyright 2010 .Net Unplugged
    Log in