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 4, versão essa lançada em 2012.

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!