Em meu artigo anterior, discuti algumas características do ASP.NET MVC Framework, que traz para a plataforma .NET uma nova maneira de se desenvolver aplicações Web, diferente do modelo de WebForms existente até então no ASP.NET. Como na época em que o artigo foi escrito o acesso ao framework não era público, limitei-me a abordar alguns aspectos conceituais. Em meados de dezembro de 2007, a Microsoft lançou a versão CTP - Community Technology Preview – do ASP.NET 3.5 Extensions, que é um pacote contendo novas funcionalidades relativas ao ASP.NET 3.5. Dentre essas novidades, o principal destaque é o ASP.NET MVC Framework. O objetivo deste artigo é apresentar esse novo modelo, suas principais características, as diferenças em relação ao modelo anterior e como utilizá-lo na prática.

Pré-requisitos

Neste artigo, foram utilizados os seguintes recursos:

• Visual Studio 2008 – nesta versão, o template de projeto do ASP.NET MVC Framework não está disponível para o Visual Web Developer 2008 Express. A Microsoft pretende lançar futuramente uma versão que atenda essa ferramenta.
• ASP.NET 3.5 Extensions CTP de dezembro de 2007 – contém o ASP.NET MVC Framework.
• ASP.NET MVC Toolkit – contém algumas funcionalidades adicionadas na última hora ao ASP.NET 3.5 Extensions. Futuramente, será incorporado ao mesmo, não sendo necessária a instalação separada.

Em alguns momentos do artigo, utilizaremos um arquivo XML para armazenar alguns dados. Para fazer o acesso e a manipulação do arquivo XML, será utilizado o LINQ to XML. Apesar de não ser fundamental para o entendimento do exemplo, o conhecimento prévio dessa tecnologia poderá ajudar. O exemplo será desenvolvido na linguagem C# 3.0/.NET Framework 3.5 e utilizará novas funcionalidades dessa versão, como inferência de tipos, propriedades automáticas, tipos anônimos, etc. Caso o leitor não esteja familiarizado com essas funcionalidades, na seção Referências no final do artigo, há links para artigos nos quais podem ser encontrados mais detalhes.

Vale citar que, por ser uma versão CTP, as informações aqui apresentadas estão sujeitas a alterações até o lançamento da versão final. Além disso, apesar dela ter se apresentado bem estável até o momento, recomenda-se que a mesma seja instalada em um computador do qual você não dependa para a realização de seus trabalhos, já que problemas e bugs podem (e provavelmente vão) aparecer. Pode-se, por exemplo, utilizar uma máquina virtual para os testes.

A arquitetura MVC

O MVC - Model-View-Controller -  é uma arquitetura que divide uma aplicação em três partes:

1)     o Model, contém a lógica de negócios e também é responsável pela manutenção do estado dos dados (por exemplo, armazenando os dados em um banco de dados);

2)     a View, responsável pela interface com o usuário e que não deve possuir nenhuma lógica de negócios e nem de acesso a dados;

3)     o Controller, que é o componente mais importante, pois responde pela interação com o usuário, manipula os dados do Model e escolhe a View a ser utilizada. Assim, é o componente que controla as demais partes do sistema.

Entre os benefícios desse padrão, está a clara separação dos papéis de cada componente, o que facilita a manutenção e a execução de testes unitários na aplicação. O ASP.NET MVC Framework implementa essa arquitetura em aplicações ASP.NET.

Você pode estar se perguntando o porquê de se introduzir esse novo modelo, já que até o momento, o ASP.NET gira em torno dos WebForms. Apesar dos WebForms terem apresentado avanços e inovações, como um estilo de desenvolvimento mais parecido com o de aplicações desktop orientado a eventos, abstração de detalhes de implementações de aplicações web (principalmente  HTML e o protocolo HTTP) e maior produtividade, essas vantagens tiveram um preço. Foi introduzido o ciclo de vida de uma página ASP.NET e toda uma série de conceitos (como PostBacks e Viewstate) que, para muitos, acabou tirando um pouco o domínio que o desenvolvedor tinha e adicionando uma complexidade que nem sempre é necessária. Além disso, com o modelo de WebForms, fica muito fácil misturar as responsabilidades de cada componente, como por exemplo, adicionando lógica de negócios diretamente nos eventos das páginas.

Então seria esse o fim dos WebForms? Teremos que esquecer tudo o que aprendemos nesses anos? Definitivamente, “Não” é a resposta para as duas perguntas. A Microsoft tem deixado bem claro que os WebForms continuarão existindo e sofrendo evoluções. O ASP.NET MVC Framework será uma alternativa, mas o seu uso não será obrigatório. Caberá aos responsáveis analisar as vantagens e desvantagens de cada modelo e escolher aquele que atenda melhor os requisitos e necessidades do sistema.

O processo de instalação do ASP.NET 3.5 Extensions CTP não é complicado, bastando seguir o assistente de instalação (o link para download pode ser encontrado na seção Referências). Após ter sido instalado, abra o Visual Studio 2008 e acesse o menu File > New Project para criarmos um novo projeto. Na janela que se abre, escolha a linguagem Visual C# e depois a pasta Web. Você irá notar novos templates de projetos que foram adicionados pelo ASP.NET 3.5 Extensions. Particularmente, veja os templates ASP.NET MVC Web Application e o ASP.NET MVC Web Application and Test. Ambos criam um projeto com a estrutura necessária para uma aplicação do tipo MVC. A diferença entre eles é que o segundo template também adiciona automaticamente um projeto de testes unitários à solution da aplicação MVC. A utilização de testes unitários em uma aplicação ASP.NET MVC está fora do escopo deste artigo. Portanto, escolha o template ASP.NET MVC Web Application e crie-o no local e com o nome que mais lhe agradar.

Figura 1 - Criando um projeto do tipo ASP.NET MVC Web Application

Após a aplicação ter sido criada, no Solution Explorer, você irá perceber uma estrutura diferente da utilizada por uma aplicação ASP.NET tradicional, conforme é mostrado na figura 2. As principais novidades são as pastas Controllers, Models e Views. Como você pode deduzir, são nessas pastas que ficam agrupados os componentes que compõem a arquitetura MVC. Na aplicação de exemplo criada com o projeto, temos um controller (HomeController.cs) e duas views (About.aspx e Index.aspx). Essas duas views estão associadas a uma Master Page (Site.Master), que está dentro da pasta Shared, a qual está sob a pasta Views.

Figura 2 - Estrutura de um projeto ASP.NET MVC

Antes de fazermos qualquer alteração na aplicação, vamos executá-la para ver como ela se comporta. Vá ao menu Debug e escolha Start Without Debugging. O browser será aberto com o resultado da operação. A aplicação não possui nada de especial, somente uma página com dois links, Home e About Us. Entretanto, se analisarmos bem, poderemos notar a primeira diferença de uma aplicação MVC em relação ao modelo WebForms. Na barra de endereços do browser, como é mostrado na figura 3, nenhuma página com extensão .aspx está sendo chamada explicitamente. Isso acontece porque em uma aplicação ASP.NET MVC, a URL é mapeada diretamente para uma classe que faz o papel do controller, e não para uma página física em disco. Neste caso, o controller que está sendo chamado é o HomeController, definido dentro da pasta Controllers do projeto.

Figura 3 - URL de uma aplicação ASP.NET MVC

Esse mapeamento entre a URL e o controller é feito por um mecanismo do próprio ASP.NET MVC Framework, que nos permite definir as regras a serem utilizadas para direcionar cada URL ao controller apropriado. Essas regras ficam definidas no evento Application_Start, do arquivo Global.asax.cs. Ao abrirmos esse arquivo, encontramos o seguinte código:

Figura 4 - Mecanismo de rotas do ASP.NET MVC Framework

Nele, são inseridas duas rotas na coleção Routes do objeto RouteTable, do namespace System.Web.Mvc, responsável pelo mapeamento entre URLs e Controllers. A primeira rota define que as URLs seguirão um padrão do tipo [controller]/[action]/[id]. Isso significa que, após o endereço do site, o primeiro parâmetro é o nome do controller, o segundo é o action (método do controller a ser executado  - um controller pode ter vários actions) e por último, um identificador [id] qualquer, que é um parâmetro passado para o método definido no action. A propriedade Defaults permite que sejam especificados valores padrão para os parâmetros. Caso o action não seja fornecido, seu valor padrão será Index. Para o id, o valor padrão será null. Assim, ao acessarmos a URL http://localhost:64701/Home/About do nosso exemplo, o ASP.NET MVC Framework chama o método About do controller chamado HomeController. Como não foi passado o parâmetro [id], o mesmo assumiu seu valor default, que nesse caso era null.

A segunda rota estabelece que, quando houver uma chamada à página Default.aspx (que normalmente é a página retornada pelo servidor web quando chamamos a raiz da aplicação), o mecanismo de mapeamento do ASP.NET MVC Framework deve chamar o método Index do HomeController. Assim, a URL http://localhost:64701/ será tratada dessa maneira.

Esse mecanismo de mapeamento funciona através de um módulo HTTP, definido no arquivo web.config de uma aplicação ASP.NET MVC:

Figura 5 - Módulo HTTP responsável pelo mecanismo de rotas

Cada requisição feita a uma aplicação passa pelo módulo HTTP UrlRoutingModule, que faz a análise da URL e determina para qual handler passar a requisição. Para aplicações MVC, esse handler é do tipo MvcRouteHandler (veja o parâmetro RouteHandler no código da figura 4), que irá então executar o controller especificado.

Uma informação importante é que as rotas são analisadas na ordem em que são adicionadas ao objeto RouteTable. Quando uma URL atende a um padrão definido de rota, o mecanismo deixa de pesquisar as demais rotas. Assim, a ordem em que as rotas são adicionadas deve ser cuidadosamente avaliada, ficando as rotas mais específicas em primeiro, e as rotas mais genéricas por último. Caso a URL não atenda os requisitos de nenhuma rota cadastrada, a requisição não é tratada pelo MVC Framework e é passada adiante. Isso permite que aplicações MVC e WebForms convivam simultaneamente sem problemas.