ASP.NET MVC 2.0 Areas


Introdução

Conforme as necessidades de uma aplicação WEB crescem,o número de arquivos associados com esta aplicação cresce rapidamente.Em uma aplicação web form,as páginas são geralmente seperadas em subpastas,com cada subpasta representando um grupo lógico destas páginas.Projetos web form podem usar qualquer estrutura de pastas para organizar os arquivos.
ASP.NET MVC trabalha por convenção,por isso a estrutura de arquivos é um pouco mais “rigida”;todas as páginas são agrupadas em subpastas da pasta raiz “Views”,com cada subpasta representando o nome de um controle na pasta Controllers.Por exemplo,o controle “Organizations”,tem uma pasta “Organizations” dentro da pasta “Views”,com todas as páginas ASPX representando as views para o controle “Organization”.Um exemplo de estruturas de pastas está na imagem a seguir:

Apesar do processo poder tambem ser um pouco customizado,a estrutura de páginas permanece rigída por causa da convenção.Uma recente mudança a essa convenção trouxe o conceito de “Areas”,que é um balanço entre a rigída configuração do framework ASP.NET MVC e a separação de componentes lógicos.A maneira mais facil de ver isto em ação é dar uma olhada na estrutura de pastas.Abaixo está o mesmo projeto de exemplo,rearranjado pra usar “INLINE AREAS”:

AREAS permitem aos projetos MVC manter a estrutura de pastas de controllers,models e views,enquanto separa os componentes lógicos uns dos outros;a implementação do“coração” do projeto está separado da AREA Organizations.AREAS de uma aplicação podem duplicar  nome de classes de controle,nome de classe de models,views,etc.Porém,cada AREA pode também compartilhar recursos na pasta “Shared”.

Você pode ver nos meus 2 exemplos acima,que a “linguistica” da estrutura de pastas mudou um pouco;primeiramente um controle Organization,depois uma organization AREA,com outro nivel de hierarquia no link(o “ManagementController”  se anexa a URL com /management).Agora requisições para /Organizations/Index são roteadas para  /Organizations/Management/Index.

Routing

O mecanismo de routing padrão do MVC entre views é por convenção.Por exemplo,na figura 1,um link para a “action” Manage iria ser gerado através do seguinte comando “Html.ActionLink”,que renderiza um hyperlink para redirecionar  para o controle Organizations no projeto principal:

Html.ActionLink(“Manage this Organization”, “Manage”,

new { controller = “Organizations”, key = 1 })

O primeiro parâmetro especifica o texto do link,os 3 ultimos parametros  especificam o action metódo a ser chamado,e os parametros da “route”,que são passados como querystring.

O conceito de AREAS muda isso um pouco,porque nós precisamos poder diferenciar a area pra qual nós queremos rotear.Isso é simples;adicione um  “key/value pair AREA” para a lista de parametros da “route”.Para rotear para nossa nova “inline area”,nós podemos usar a seguinte sintaxe:

Html.ActionLink(“Manage this Organization”, “Manage”, “Management”,

new { area = “Organizations”, key = 1 })

Informando a area especifica podemos navegar para a area correta;sem isso,o link iria mandar para o ManagementController no projeto principal,que não existe;Adicionando o parametro area=”Organizations”, faz com que as requisições seja corretamente roteadas para os controles dentro daquela area.

Mas há alguns outros passos para que isto aconteça,e requer o uso de um novo objeto chamado “AreaRegistration”.Um processo personalizado de registro deve ser criado para as AREAS,como a seguir:

public class OrganizationsAreaRegistration : AreaRegistration
{
public override string AreaName
{
get
{
return “Organizations”;
}
}
public override void RegisterArea(AreaRegistrationContext context)
{
context.MapRoute(
“Organizations_default”,
“Organizations/{controller}/{action}/{id}”,
new { action = “Index”, id = UrlParameter.Optional }
);
}
}

O método RegisterArea é o componente chave para fazer o registro adicionando outra “route” para a coleção de “routes” de AREA.Note que o nome da AREA “Organizations” está fixado na URL;todas as requisições prefixadas com o nome de areas são tratadas de forma diferente.

Você deve estar pensando: porque nós não podemos especificar   Organizations para a definição de “routes” na aplicação principal?Se nós tivessemos adicionado  para a tabela de “routes” padrão,e não através do contexto da area,nós ainda teríamos que ter todos os arquivos no nosso mesmo projeto,e perderíamos os beneficios da separação de Areas de projeto.

Multi-projects Area

Não suportado diretamente no ASP.NET MVC 2 nem no ASP.NET MVC ,a versão RC e beta,tambem suportam “areas” que são “projetos separados”.Um projeto MVC separado poderia ser referenciado como uma area e funcionar  da mesma maneira que uma “INLINE AREA”.A forma de se fazer é muito parecido com “INLINE AREAS”,com a execeção de algum trabalho de configuração adicional no projeto MVC.

Essas configurações adicionais precisam de uma técnica que copia o conteúdo do projeto e fazem o “deploy” dele no projeto principal,basicamente mesclando a AREA que contem o projeto externo com o projeto principal do ASP.NET MVC.O processo de “deploy” funciona sem emendas para você,e acontece automaticamente através de uma tarefa MSBUILD,como parte de futuros assemblies do ASP.NET MVC.Existe um assembly chamado Microsoft.Web..Mvc.Build.dll que faz esse processo para você.

Isso não é oficialmente suportado pela microsoft;no entanto,se você quiser tentar essa configuração,os seguintes recursos irão ajuda-lo a implementar a tarefa no seu projeto:

http://msdn.microsoft.com/en-us/library/ee307987%28VS.100%29.aspx

http://dotnetslackers.com/articles/aspnet/a-first-look-at-asp-net-mvc-2.aspx

Considerações Finais

Areas são uteis para separar conteudo,mas eu lhe recomendo,não abusar,por varios motivos.Primeiro,areas realmente aumentam o numero de arquivos do projeto.Manter o projeto reduzido dentro do possivel ajuda na manutenção.Eu não estou advogando contra AREAS,eu estou recomendando um balanço entre o tamanho do projeto e a separação lógica de conteudo.

Uma coisa legal com AREAS é que você pode configurar controles com nomes similares para as views e fazer com que o site pareça mais consistente.Por exemplo,as areas account,store, e catalogo podem ter URLS consistentes dando nomes similares aos controles e actions de cada Area.Por exemplo,seu site poderia ter o seguinte:

/Accounts/Search/Index

/Store/Search/Index

/Catalog/Search/Index

Conclusão

Areas ajudam a separar conteudo,e alteram o processo de “routing”.Areas tem suas próprias estruturas de pastas e roteam suas próprias requisições de controles para as views.Routes requerem uma novo parametro de  “AREA de “routing”,que é usado para rotear para a area correta.

Anúncios

Um comentário sobre “ASP.NET MVC 2.0 Areas

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s