Por que eu devo ler este artigo:O desenvolvimento de aplicações utilizando o ASP.NET MVC é uma realidade. Trata-se de um sistema que ganhou muito espaço devido à utilização do padrão MVC, em especial porque ele facilita a separação dos elementos da aplicação.

Entretanto, o MVC Framework possui uma forma diferente de lidar com a navegação e precisamos entender o seu funcionamento antes de começarmos a desenvolver, para que possamos oferecer a melhor experiência de navegação entre as páginas da aplicação, direcionando o usuário para o destino correto e com URLs amigáveis.

Ao longo desse artigo, veremos como lidar com os elementos de navegação do ASP.NET MVC. Vamos entender como criar e registrar rotas, bem como definir o roteamento padrão da aplicação. Além disso, entenderemos como a aplicação se comporta internamente durante as ações de navegação.

Em muitas tecnologias, o sistema web assume que há uma correlação de “1 para 1” entre as URLs que são requisitadas e os arquivos correspondentes no disco. Nesses casos, só o que o servidor precisava fazer era recuperar o arquivo do disco correspondente à requisição e mostrá-lo para o cliente. Esse esquema começou a ser alterado com a introdução do MVC Framework, que possui uma forma totalmente diferente de organização dos elementos de navegação.

No ASP.NET MVC temos as requisições sendo processadas pelos métodos de ação, ou Action Methods. Esses métodos estão presentes em classes Controller, e não há uma correlação de “1 para 1” entre esses métodos e os arquivos, como anteriormente.

É possível termos vários Action Methods retornando a mesma view, ou um mesmo Action Method retornando várias views (uma por vez, logicamente, sujeito às condições).

Essa forma de funcionamento faz com que o ASP.NET MVC precise delegar a tarefa de encontrar as rotas entre as páginas de nossa aplicação. Isso é realizado através de um sistema de roteamento, que vamos entender em detalhes ao longo desse artigo.

O sistema de roteamento do ASP.NET MVC permite a criação de URLs de uma forma flexível e poderosa, através da definição de um padrão para elas. A ideia é que o leitor tenha, ao final do artigo, um entendimento de como criar as estruturas de roteamento para uma aplicação ASP.NET MVC.

Além disso, também vamos entender em detalhes como funcionam, internamente, os Action Methods e os Controllers, e porque eles são tão importantes nesse sistema de roteamento.

Roteamento em aplicações ASP.NET MVC

O roteamento em aplicações ASP.NET MVC é delegado a um sistema de rotas. Isso ocorre porque o funcionamento interno do framework, baseado em Models, Views e Controllers, não se adapta à condição de que há uma correspondência entre a URL e a View. O sistema de roteamento do MVC tem duas funções básicas:

1. Examinar as URLs e identificar para qual controller e ação a requisição foi visada;

2. Gerar URLs de saída, que estarão renderizadas no HTML das views para que uma ação específica seja invocada, por exemplo, no clique de um link.

Note que isso, de certa forma, tira um peso das costas do desenvolvedor. Com o MVC, não é necessário criarmos uma tela para cada detalhe: podemos utilizar uma mesma view com diferentes parâmetros. Essa é uma das grandes vantagens que esse sistema de roteamento nos fornece.

Existem dois meios para criarmos rotas em uma aplicação ASP.NET MVC: convention-based routing e attribute routing. A primeira delas permite a criação de rotas baseadas em uma convenção básica, como o nome sugere, e está presente em todas as versões do MVC Framework desde o princípio.

Já o roteamento por atributos é uma das novidades introduzidas com a versão 5 do Framework e ainda não está tão difundido no meio do desenvolvimento.

Em mais detalhes, convention-based routing (Roteamento baseado em convenção) corresponde a mapear URLs e métodos de ação. Isso envolve uma série de outros fatores que são importantes e que veremos ao longo desse artigo.

Basicamente, esse tipo de roteamento é baseado em segmentos, onde existe um padrão básico que deve ser seguido por todas as rotas. Por exemplo, temos uma URL padrão das aplicações ASP.NET MVC que possui dois segmentos: <nome_de_domínio>/<1º segmento>/<2º segmento>.

Por padrão, o sistema de roteamento do MVC traz o nome do controller como 1º segmento (Home, no exemplo) e o nome do Action Method como 2º (Index), como em “localhost:56748/Home/Index”. É interessante notarmos que esse padrão pode ser alterado, e veremos como fazer isso.

Já o attribute routing (Roteamento por atributos) diz que as rotas devem ser definidas por atributos do C# que são aplicados diretamente às classes controller.

Como esse não é o meio padrão de roteamento, é preciso que o habilitemos antes da utilização, mas isso é muito simples de ser realizado, requerendo apenas uma linha de código e a utilização do método “MapMvcAttributeRoutes()”, da classe RouteCollection.

Muitos desenvolvedores acham essa forma de roteamento mais complexa que a primeira, mas cabe ao leitor decidir. Isso pode ser apenas um efeito de tratar-se de uma tecnologia nova no MVC, e os desenvolvedores ainda não tiveram tempo para adaptar-se a elas.

A melhor parte é que é possível misturarmos as duas abordagens para a criação das rotas de nossa aplicação sem nenhum problema.

O sistema de roteamento do MVC Framework não é nenhum “bicho de sete cabeças”. Trata-se de um sistema que possui alguma complexidade, mas com o qual é bastante fácil de lidarmos. Ao final do artigo, a ideia é que o leitor tenha uma noção clara do que esperar do sistema de roteamento, bem como das duas formas que ele traz para criarmos a navegação em nossas aplicações ASP.NET MVC.

Por dentro de Controllers e Actions

O sistema de roteamento não é o único conceito que precisamos entender para lidarmos com navegação nas aplicações ASP.NET MVC. As questões que envolvem os controllers e os métodos de ação também são muito importantes para esse entendimento.

É importante notarmos que os controllers, com seus métodos de ação, não podem extrapolar as suas próprias responsabilidades, contendo dados (que pertenceriam aos modelos) ou gerando interfaces de usuário (que seriam responsabilidade das views), por exemplo.

A primeira coisa que precisamos entender é que todas as requisições que chegam para a aplicação passam pelas mãos do controller. Es ...

Quer ler esse conteúdo completo? Tenha acesso completo