Há alguns anos a web era um ambiente lúdico. O que quero dizer com
esta afimação é que o interesse dos usuários ao abrir um website para
navegar era: “entreter”. Era muito comum ouvir afirmações do tipo:
“Internet? Isso é coisa de desocupado que não tem o que fazer!”.
Evidentemente que, o que faz algo acontecer de fato no mercado é a
demanda e, para a demanda daquele momento, as tecnologias disponíveis
(HTML, JavaScript e uma linguagem de programação do server-side) eram suficientes. Na época, destacavam-se como linguagens server-side: PHP, ASP, CGI, Java (Servlets e Applets) e outras.

O tempo passou e a internet deixou de ser um ambiente estritamente de
entretenimento e passou a ser um ambiente também de negócios.
Evidentemente que o perfil do usuário também sofreu alterações. O
usuário que antes acessava um site apenas para ler notícias, agora
acessava um site também para consultar preços de produtos, reservar
passagens aéreas, etc. É desnecessário mencionar que uma nova demanda
havia sido criada e, os sites passaram a ter traços de aplicações.

Falando especificamente da Microsoft, com esta nova demanda do
mercado por “aplicações web”, eis que surge em 2002 o ASP.NET, trazendo
consigo o modelo WebForms de programar. Sim, naquela época os WebForms
causaram um espanto. Com o desenvolvimento das aplicações totalmente
voltado para a manipulação de componentes do lado servidor (textbox,
gridview, dropdownlist, etc.) e a facilidade de injeção de
comportamentos destes através de seus eventos proporcionada pelo Visual Studio
(arrasta o componente, duplo clique no mesmo e inserção de código no
evento), a Microsoft arrebanhou uma grande fatia de desenvolvedores,
principalmente aqueles já acostumados com esse modelo (“Delphistas” e
“VBistas”). Assim, as aplicações web tornaram-se corporativistas, fato
este que agradou o mercado e resultou em uma grande adoção da
tecnologia.

Já para os desenvolvedores web tradicionais, acostumados com o a manipulação direta dos elementos HTML, JavaScript e linguagens server side,
o ASP.NET WebForms apresentou-se como um ser completamente estranho,
principalmente pelo fato de “tirar” do desenvolvedor o controle total
dos elementos citados acima. Ganhava-se em produtividade e
familiaridade, entretanto, perdia-se em essência. Na verdade, para
estes, a impressão que os WebForms causavam era: “isso não é web”.

Olhando por este lado e olhando um antigo e funcional modelo de desenvolvimento (proposto para utilização com a linguagem Smalltalk), o modelo MVC (Model-View-Controller), a Microsoft lançou em 2007 um preview para a comunidade de sua novíssima framework para desenvolvimento de aplicações web, o ASP.NET MVC. Atualmente o framework está na versão 2, entrentanto, já temos o preview
da versão 3, que segundo rumores, deve sair ainda em 2010 com algunas
novidades interessantes. Mas isso, é assunto para outro artigo.

Conhecendo o ASP.NET MVC

O ASP.NET MVC não é um pattern de desenvolvimento mas é quase isso. A sigla MVC vem do inglês Model, View e Controller,
que traduzido quer dizer “Modelo, Visão/Visualização e Controlador”. É
um modelo de programação que possui como objetivos principais:

• Separar as responsabilidades: A idéia principal da framework MVC
  é separar as diferentes responsabilidades do código, ou seja,
  “controladores” somente processam as requisições realizadas pelo browser;
  “modelo” é responsável isoladamente pelo controle de acesso aos dados;
  “visões/visualizações” responsáveis apenas pela exibição das
  informações. Cada camada pode trabalhar de forma isolada da outra (baixo
  acoplamento), característica extremamente desejável no desenvolvimento
  de sistemas.
• Incentiva boas práticas: O modelo MVC tem como uma de suas
  principais características incentivar a utilização de boas práticas. Um
  exemplo claro disso é a escrita de testes unitários. Se você utilizar o
  Visual Studio para escrever suas aplicações ASP.NET MVC (e isto não é
  requisito para escrever aplicações ASP.NET MVC), perceberá que no
  momento da criação de um projeto, a IDE o perguntará se deseja escrever
  testes unitários com ela. Assim, é possível afirmar que a testabilitade
  da aplicação resulta no baixo acoplamento.
• Exige conhecimentos de (X)HTML, JavaScript e CSS: Quando
  trabalhamos com ASP.NET MVC temos as tarefas separadas. Isto é
  interessante principalmente pelo fato de tornar o código legível, com
  boa manutenibilidade e deixar a aplicação totalmente nas mãos do
  desenvolvedor. Entretanto, essa característica exige um certo domínio
  por parte do desenvolvedor.
• Fácil manutenibilidade: Como as aplicações trabalham com
  diversas visualizações para um mesmo controlador, torna-se fácil a
  tarefa de adicionar ou remover features (características) das mesmas, ou seja, é fácil dar manutenção em um código ASP.NET MVC.

Poderíamos citar ainda: escalabilidade, utilização dos helpers
na construção das visualizações (falaremos deles especificamente em um
artigo), visualizações fortemente tipadas, facilidade de trabalho com
ORM’s, dentre outras. A Figura 1 apresenta o modelo conceitual do
ASP.NET MVC.

Figura 1: Arquitetura de uma aplicação MVC (fonte: ASP.NET Nova)

A Figura 1
dispensa maiores comentários, pois já dizia o dito popular: “uma imagem
vale mais que mil palavras”, mas apenas para fins  de contextualização,
segue uma breve explicação do modelo.

O componente verde “Event”
representa qualquer requisição realizada pelo usuário, como por exemplo
a ordem para efetuar uma busca no site. A requisição então
obrigatóriamente é direcionada para o controlador (em azul). Este por
sua vez “decide” se a requisição gerará uma nova visualização (em
amarelo) ou se antes de gerar a visualização de resposta consultará a
fonte de dados (em laranja), por exemplo. Como as visualizações pode ser
fortemente tipadas, elas também podem efetuar consultas ao modelo de
dados.

Esta
arquitetura extremamente eficaz e funcional só pode ocorrer graças as
rotas. A seguir falaremos de forma mais específica sobre elas.

Entendendo o mecanismo de rotas

Quando vamos
realizar uma viagem, uma prática muito comum e recomendável é traçar a
rota da mesma. Isso nos ajuda a saber o caminho exato que deveremos
seguir para que não nos percamos. Como você já pode estar imaginando, o
ASP.NET MVC trabalha com a viagem dos dados e, por consequência, é
fundamental entender que a rota que estes dados deverão seguir para
alcançar seu objetivo final deve estar definida desde o início da
viagem.

Na arquitetura de WebForms, temos uma url (geralmente subdividida em pastas no servidor) que, no final das contas, aponta para um arquivo físico no servidor (.aspx) sendo que neste, estão implementadas todas as ações solicitadas pelo browser.
No ASP.NET MVC o modelo é um pouco diferente, haja vista que a
requisição é tratada por um elemento controlador e este decide como
gerar a visualização, portanto, ao invés de apontarmos para uma página
(física) apontamos para uma ação dentro de um elemento conceitual, o
controlador. Assim, precisamos realmente de uma rota para definir o
caminho final dos dados.

O framework
ASP.MVC traz como sugestão uma rota pré-definida, conforme apresenta a
Listagem 1. Entretanto, o desenvolvedor possui o poder de “customizar”
inclusive a rota do aplicativo. Evidentemente que, para maioria dos
casos, a rota proposta pela framework atende as necessidades, entrentanto é importante frisar: no modelo MVC o desenvolvedor é que manda e não a framework.

routes.MapRoute(
                "Default", // Nome da rota
                "{controller}/{action}/{id}", // Parâmetros da URL
                new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parâmetros da URL
            );

Listagem 1: Definição da rota de uma aplicação ASP.NET MVC

A definição de rotas da aplicação ASP.NET MVC se encontra no arquivo “Global.asax”.
Como é possível perceber além da rota, é preciso especificar valores
padrão para cada elemento da rota. Isso é realizado na linha 4.

Para que
possamos entender e explicar o código da linha 3, imaginemos o exemplo
de controle de “Clientes”. Portanto, em nossa aplicação ASP.NET MVC,
possivelmente teríamos um controlador (para que você possa visualizar,
algo equivalente a uma classe) chamado “Cliente”. Imaginemos agora, que
quiséssemos efetuar uma operação específica para clientes, como por
exemplo atualizar (editar) as informações cadastrais do cliente. Assim,
teríamos dentro do controlador “Cliente” uma ação (um método) “Editar”
e, esta ação precisaria de algum parâmetro que indicasse a ela qual
cliente deve ter suas informações atualizadas. Assim, poderíamos
parametrizar esta ação através do código do cliente, por exemplo. Assim,
poderíamos ter (como exemplo) a url apresentada abaixo para a chamada deste processo:

http://seusite.com.br/Clientes/Atualizar/1854

Na comparação com o modelo tradicional WebForms, o que se entenderia olhando a url
acima é que “Clientes” seria um diretório, “Atualizar” seria outro
diretório e a parte final, o número “1854” seria uma página física no
servidor. Já com ASP.NET MVC “Clientes” seria o controlador (controller), Atualizar seria a ação (action) a ser executada pelo controlador e o número “1854” seria o parâmetro a ser enviado para a ação.

Na linha 4, vale salientar que o parâmetro “id” é opcional, portanto, é possível termos uma url com a ausência deste valor. Algo como: http://seusite.com.br/Clientes/Cadastrar. Além disso, como todo controlador tem uma ação padrão (por default a ação Index), também é comum encontrarmos url’s do tipo: http://seusite.com.br/Clientes. Neste caso, ao chamar o controlador “Clientes” e não passar o nome da ação na url, a framework automaticamente direciona a requisição para a ação padrão.

Bom pessoal,
este é o primeiro artigo de uma série abordando todos os principais
conceitos relacionados ao ASP.NET MVC. Neste primeiro artigo, a idéia é:
posicioná-lo em relação a tecnologia, para saber em que tipo de terreno
está pisando. Nos artigos seguintes, trataremos de aspectos técnicos e,
artigo a artigo, vamos mergulhando cada vez mais no universo das
aplicações ASP.NET MVC.

No próximo
artigo criaremos nossa primeira aplicação ASP.NET MVC e entenderemos
como tudo funciona lá dentro. Você não deve perder. A idéia é que, ao
final de cada artigo, um vídeo esteja disponível apresentando os
conceitos aborados no artigo. É aprender ou aprender. Como este primeiro
artigo é conceitual, não temos o vídeo. Mas a partir do próximo, você
não deve perder!

Se você
gostou ou não da leitura, deixe seu comentário. É a única forma que
temos para evoluir com os conteúdos e escrever textos cada vez melhores
:-). Obrigado e até a próxima!