No primeiro artigo da série “ASP.NET MVC – Início, Meio e Fim”, nossa preocupação principal foi responder a uma pergunta intrigante: “O que é ASP.NET MVC?”. Nele, apresentamos as linhas gerais que delineiam a tecnologia, bem como alguns aspectos técnicos envolvidos. Falamos um pouco sobre o modelo de desenvolvimento Model-View-Controller e como estas camadas interagem entre sí e entendemos o mecanismo de rotas, um dos pilares deste modelo de desenvolvimento. Portanto, caso não tenha efetuado a leitura do primeiro artigo e não não possua os conhecimentos equivalentes, recomendo forte a leitura do mesmo, que pode ser realizada gratuitamente na íntegra seguindo o link: https://fabriciosanchez.com.br//?p=987.
No artigo de hoje, falaremos um pouco das versões do ASP.NET MVC e a evolução ocorrida de uma versão para outra. Além disso, passaremos pela instalação do framework para quem utiliza o Visual Studio 2008 e, finalmente, criaremos e entenderemos a estrutura de nossa primeira aplicação ASP.NET MVC.
Versões do ASP.NET MVC
A primeira versão do framework ASP.NET MVC foi lançada em 2007. De lá para cá, webdevelopers que não conseguiam aceitar o modelo de programação para web proposto pelos WebForms começaram a estudar e adotar o modelo MVC em seus projetos. Os números chegaram a casa de 1 milhão de downloads para a versão 1. Posteriormente, em meados de 2009 a Microsoft lança a versão 2.0 da framework MVC. O salto de recursos em relação as features da versão 1 foram significativos. Dentre eles podemos citar:
- Helpers fortemente tipados (falaremos especificamente sobre Helpers em um artigo futuro);
- Melhorias em relação a validação de modelos (tanto para server-side quanto para client-side);
- Suporte para a divisão/particionamento de grandes aplicações em “áreas”;
- Auto-Scaffold para Helpers e customização de templates (falaremos especificamente sobre scaffolds em um artigo futuro);
- Simplificação de muitas terminologias, resultando em códigos mais limpos e legíveis;
- Dentre outras;
A versão 2.0 é a versão final, estável e que já vem acoplada ao Visual Studio 2010.
Há alguns meses a Microsoft liberou o preview da versão 3 do ASP.NET MVC para a comunidade técnica. Assim que foi lançado os webdevelopers congestionaram o site da Microsoft baixando a nova versão. Muitas novidades estão por vir, mas, eu destacaria a nova view engine padrão, cujo codinome é Razor, suporte para HTML 5 e o NuPack. Não se preocupe, falaremos de todos esses conceitos especificamente em artigos futuros. Existem rumores que a versão final do ASP.NET MVC 3 deve ser lançada até o final de 2010. Enquanto a versão 3 não vem, vamos aprender na versão 2, que era a versão final, estável, quando este artigo foi escrito.
Instalando o ASP.NET MVC 2 no Visual Studio 2008
A versão 2 do framework ASP.NET MVC pode ser utilizada tanto com o Visual Studio 2008 quanto com o Visual Studio 2010. O fato que confunde alguns desenvolvedores que estão iniciando com a tecnologia é, se você utiliza o Visual Studio 2010, já possui o framework MVC 2 instalado e pronto para utilização. Caso você utilize o Visual Studio 2008, o framework não vem instalado nativamente, portanto, esta instalação deve ser feita manualmente. A seguir descrevo este processo.
- O primeiro passo para instalar o framework é efetuar o download do mesmo. Para isso, basta seguir o link: http://www.microsoft.com/downloads/en/details.aspx?FamilyID=3b537c55-0948-4e6a-bf8c-aa1a78878da0&displaylang=en.
- A instalação do ASP.NET MVC 2 exige que o Visual Studio 2008 esteja com o Service Pack 1 instalado. Se ao tentar executar o instalador mencionado no ítem 1 você não obtiver sucesso, é provável que você necessite instalar o SP1 do Visual Studio. Se este for seu caso, basta seguir o link http://www.microsoft.com/downloads/en/details.aspx?FamilyId=FBEE1648-7106-44A7-9649-6D9F6D58056E&displaylang=en, baixar, instalar e, em seguida, executar novamente o executável apresentado no ítem 1.
A instalação do framework MVC não possui qualquer segredo. Ao contrário, é extremamente simples, bastante seguir os protocolos tradicionais de instalação de aplicativos (aceitar os termos de licença, diretório de instalação, etc.). Se tudo correu bem, ao abrir o Visual Studio 2008 e criar um novo projeto web, você poderá visualizar uma nova opção de aplicação, conforme apresenta a Figura 1.
Figura 1: Escolhendo a opção de projeto (imagem retirada do blog de Fernanda Sallai)
No final deste artigo você encontrará uma vídeo aula que apresenta o processo de instalação da framework do ASP.NET MVC 2 para Visual Studio 2008.
Criando e entendendo nosso primeiro aplicativo ASP.NET MVC 2
Após contextualizar o momento pelo qual está passando o framework ASP.NET MVC e apresentarmos o processo de instalação do mesmo para usuários do Visual Studio 2008, é chegado o momento de criarmos nossa primeira aplicação ASP.NET MVC.
No artigo de hoje, o que faremos é criar nossa aplicação ASP.NET MVC e esmiuçá-la, entendendo a arquitetura de uma aplicação ASP.NET MVC. Para isso, utilizaremos um modelo pronto, fornecido pelo Visual Studio. Este modelo, muito embora simples, nos dará a dimensão exata da arquitetura de uma aplicação MVC. Aproveitaremos este mesmo exemplo para apresentar em artigos futuros, todos os demais conceitos importantes, tais como: helpers, ASP.NET Razor, Validações, etc. Ao final deste artigo, você encontrará uma pequena vídeo aula apresentando os conceitos vistos neste artigo.
Criando o projeto
Com o Visual Studio devidamente aberto e configurado, vamos criar um novo projeto do tipo “Web” > “ASP.NET MVC 2 Web Application” e nomeá-lo para “SitePessoal”. A Figura 2 apresenta este processo.
Figura 2: Selecionando o projeto ASP.NET MVC
Quando clicar em “OK” a tela apresentada pela Figura 3 aparecerá. Conforme mencionamos no primeiro artigo da série, uma das vantagens do modelo ASP.NET MVC é o fato de que este incentiva a escrita de testes unitários. A tela apresentada pela Figura 2 pergunta ao desenvolvedor se ele deseja utilizar o Visual Studio Unit Test (framework de testes embutida no Visual Studio) para escrever testes unitários para a aplicação. Se você selecionar “Yes, create a unit test project” e pressionar o botão “OK”, um projeto específico para testes será adicionado a Solution Explorer e você poderá utilizar a framework de testes do Visual Studio. Se selecionar a opção “No, do not create a unit test project” e pressionar o botão “OK”, o que estará fazendo é dispensar a utilização dos testes unitários do Visual Studio. É perfeitamente possível adicionar um projeto de testes a qualquer momento da vida do projeto, por isso, vamos marcar a segunda opção (dispensar temporariamente os testes) e clicar em “OK”. Falaremos de testes em nossas aplicações ASP.NET MVC em um futuro próximo!
Figura 3: Selecionando a presença/ausência de testes unitários
Se tudo correu conforme o esperado, seu projeto foi criado. Conforme mencionado anteriormente, o que fizemos foi utilizar uma estrutura de aplicação já pronta e fornecida pelo Visual Studio, portanto, ao compilar e executar o projeto, você deverá visualizar algo semelhante ao apresentado pela Figura 4.
Figura 4: Aplicação em execução
Como você pôde constatar nossa aplicação de demonstração está funcionando corretamete. Se você navegou através dela, percebeu que ela já vem munida de duas seções “Home” e “About”, além de incorporar um controle de usuários via “Membership Helper“. No decorrer de nossos exemplos, vamos incrementar e modificar features (características) de nossa aplicação. Mas isto é assunto para o próximo artigo.
Conhecendo e entendendo a estrutura da aplicação
Para que possamos começar a entender a essência de uma aplicação ASP.NET MVC, iniciemos nossas análises pela Solution Explorer de nosso projeto. Conforme apresenta a Figura 5, temos os seguintes elementos constituindo a base de nossa aplicação:
- Pastas/Diretórios
- Properties
- References
- App_Data
- Content
- Controllers
- Models
- Scripts
- Views
- Arquivos
- Global.asax
- Web.config
Iniciemos pelos diretórios. Properties, References e App_Data já são velhas conhecidas dos projetos ASP.NET WebForms. Vou então focar a explicação naquilo que é novo, os diretórios Content, Controllers, Models, Scripts e Views. Os diretórios Content e Scripts são diretórios de apoio de nossa aplicação. São diretórios com nomes sugeridos pelo Visual Studio para estruturar de forma “correta” sua aplicação. Estes nomes podem ser diferentes, de acordo com sua preferência. A idéia é que o diretório Content hospede arquivos e/ou novos diretórios de arquivos de apoio, tais como: folhas de estilos, imagens etc. Já para o diretório Scripts, a idéia é hospedar todos os arquivos de script aos quais a aplicação necessita. Um exemplo clássico destes tipos de arquivos são scripts JavaScript (JQuery, por exemplo). Ao maximizar o diretório Scripts, você poderá perceber que uma gama de arquivos se encontram presentes no mesmo. Isso se deve ao fato de havermos criado uma aplicação baseada em um modelo do Visual Studio, portanto, o próprio VS adicionou as aquivos de script que ele utiliza. Você pode adicionar seus arquivos de script a esta pasta sem qualquer tipo de problema.
Figura 5: Solution Explorer inicial do projeto
O grande diferencial de nossa aplicação (e de todas as aplicações ASP.NET MVC) são proporcionados pelas três pastas que ainda não mencionamos na explicação: Models, Views e Controllers. Na verdade, não são as pastas que oferecem o diferencial e sim, o que elas representam, a separação das responsabilidades.
- Models: este diretório agrupa os arquivos relacionados ao acesso aos dados. Sejam classes de acesso utilizando o ADO.NET ou o ORM de sua preferência, os arquivos de acesso e manipulação dos dados são agrupados nesta pasta. Portanto, o nome do diretório – Models (Modelos) vem justamente do fato de os arquivos do “modelo de dados” estarem agrupados nele.
- Views: em português “visão” ou também “visualização”, esta pasta agrupa os arquivos resutantes do processamento das actions, conforme veremos mais adiante neste artigo. Dentro desta pasta agrupam-se sub diretórios que possuem o mesmo nome dos controllers (controladores) e, dentro destes, os arquivos com a extensão ASPX ou CSHTML (para o caso do Razor).
- Controllers: este diretório, como o próprio nome sugere, agrupa os arquivos controladores (classes). Se você leu o primeiro artigo da série, deve estar lembrado que as requisições feitas no browser não são enviadas diretamente para uma página como no modelo WebForms e sim, para um elemento chamado controller que, ao receber a requisição seleciona a action correta e executa o processamento.
Finalmente, temos os arquivos “Global.asax” e “Web.config“. O Web.config é um velho conhecido dos programadores WebForms. Neste arquivo são setadas configurações gerais da aplicação, como: strings de conexão, informações de helpers, segurança, etc. Já no arquivo Global.asax temos configurações específicas da framework para a aplicação, como a configuração das rotas por exemplo.
Entendendo a arquitetura da aplicação
A Figura 6 apresenta a Solution Explorer do projeto com todas as pastas maximizadas. Vamos utilizar frequentemente esta figura para explicarmos a interação entre os módulos da aplicação.
Figura 6: Solution Explorer expandida
Para que entendamos nossa aplicação, vamos utilizar como referência também a imagem utilizada no primeiro artigo da série. A Figura 7 a reproduz novamente.
Figura 7: Estrutura conceitual de uma aplicação ASP.NET MVC
Daqui por diante utilizaremos a nomenclatura em inglês para os elementos por ser o padrão utilizado por autores e pela comunidade técnica.
Como é possível observar na Figura 7, quando um evento ocorre (entenda-se por evento neste momento a chamada de uma url) o primeiro elemento a ser chamado é o controller. Para começarmos a entender como as rotas (mencionadas no primeiro artigo da série) determinam o tráfego das informações pelos módulos, executemos nossa aplicação. Se tudo correu bem, você deve estar visualizando uma url semelhante a esta: http://localhost:1379/. Como é possível notar, não temos a chamada explícita de qualquer controller, action e value e mesmo assim nossa aplicação está funcionando corretamente. Isto somente é possível em função do código implementado por padrão pela framework no arquivo Global.asax, conforme apresenta a Listagem 1.
[csharp]
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute(“{resource}.axd/{*pathInfo}”);
routes.MapRoute(
“Default”, // Route name
“{controller}/{action}/{id}”, // URL with parameters
new { controller = “Home”, action = “Index”, id = UrlParameter.Optional } // Parameter defaults
);
}
protected void Application_Start()
{
AreaRegistration.RegisterAllAreas();
RegisterRoutes(RouteTable.Routes);
}
[/csharp]
Listagem 1: Definições padrão de rotas da aplicação
Note que já estão definidos um controller padrão, uma action padrão e um value padrão e estes elementos já estão registrados na framework desta forma. Assim, teriamos a exibição da mesma tela (view) se passássemos as seguintes url’s na barra de endereços do browser: http://localhost:1379/Home ou http://localhost:1379/Home/Index. Neste caso, “Home” é o controller e “Index” é a action. A Figura 8 apresenta o resultado de ambas as chamadas.
Figura 8: Realizando requisições com formatos diferentes de url
Para completarmos o raciocínio e entendermos exatamente o que está ocorrendo, voltemos a Solution Explorer. Olhando para o diretório “Controllers” encontramos o arquivo “HomeController.cs“. Este arquivo é o controlador chamado por default quando chamamos as url’s acima. Dando um duplo clique sobre este arquivo e analisando-o, você verificará a existência de um método, chamado “Index“. Este método é chamado Action e representa uma das operações que o controlador é capaz de realizar diante de determinado evento (chamada de url). A Listagem 2 apresenta o código da classe (controller) HomeController.cs.
[csharp]
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Mvc;
namespace SitePessoalMVC.Controllers
{
[HandleError]
public class HomeController : Controller
{
public ActionResult Index()
{
ViewData[“Message”] = “Welcome to ASP.NET MVC!”;
return View();
}
public ActionResult About()
{
return View();
}
}
}
[/csharp]
Listagem 2: Actions do controller “Home”
Você deve estar se perguntando: e as views? Onde entram nesta história? Note, olhando para o código apresentado pela Listagem 2 fica fácil notar um aspecto: views não podem ser resultantes de controllers. O motivo de realizar esta afirmação é simples: como é possível gerar uma única tela para conteúdos diferentes? Não é possível. Portanto, views são telas que exibem conteúdos resultantes do processamento de actions e não de controllers. Assim, em nosso exemplo, a action “Index” do controller “Home” exibe apenas a mensagem “Welcome to ASP.NET MVC“.
Alguns aspectos são de fundamental importância no código da Listagem 2. O primeiro deles é que a action “Index” retorna um ActionResult, ou seja, a action deve retornar um objeto específico que a view reconheça e possibilite transitar valores entre os módulos (controllers e views). Neste caso, o que a action “Index” retorna é um objeto ViewData chamado “Message” que contém a mensagem “Welcome to ASP.NET MVC“. Views que retornam ViewData são muito comuns nas aplicações ASP.NET MVC, mas não são uma regra. É perfeitamente possível, por exemplo, construir uma action que retorne uma string etc. Veremos todos estes casos em nossos exemplos futuros.
Olhando novamente a Solution Explorer, desta vez o diretório “Views“, fica fácil encontrarmos um sub diretório chamado “Home” e dentro dele dois arquivos com a extensão ASPX: Index e About. Evidentemente que o sub diretório possui o nome do controller e os arquivos possuem os nomes das actions do mesmo, conforme pode ser constatado na Listagem 2. Como estamos utilizando o exemplo do controller “Home” e da action “Index“, a Listagem 3 apresenta o código da view “Index“.
[html]
<%@ Page Language=”C#” MasterPageFile=”~/Views/Shared/Site.Master” Inherits=”System.Web.Mvc.ViewPage” %>
<asp:Content ID=”Content1″ ContentPlaceHolderID=”TitleContent” runat=”server”>
Home Page
</asp:Content>
<asp:Content ID=”Content2″ ContentPlaceHolderID=”MainContent” runat=”server”>
<h2><%: ViewData[“Message”] %></h2>
<p>
To learn more about ASP.NET MVC visit <a href=”http://asp.net/mvc” title=”ASP.NET MVC Website”>http://asp.net/mvc</a>.
</p>
</asp:Content>
[/html]
Listagem 3: Código da view “Index“
Como você pode perceber, o código da view é extremamente simples. O aspecto a ser ressaltado na Listagem 3 é a utilização das tag’s <% %> para escrevermos os valores provenientes das actions, como pode ser constatado na linha 8. Aqui, o que estamos fazendo é escrever entre as tag’s <h2></h2> o ViewData retornado pela action.
Conclusão
Após a leitura deste segundo artigo, o que você deve ter em mente é: requisições são tratadas pelos controllers através de actions, que geram views. A seleção da action adequada por parte do controller depende diretamente da url invocada pelo usuário através do browser, que segue o seguinte formato: http://dominio/controller/action/valor.
Outro aspecto que você deve ter em mente é que, um controller é pode ter várias actions, tantas quantas necessárias e que, view são resultantes de actions e não de controllers.
Por enquanto, não estamos trabalhando com models, mas em um futuro próximo trabalharemos e você entenderá como é realizado o acesso a dados.
Vídeo aula
Para reafirmar os conceitos apresentados neste artigo, recomendo fortemente a visualização da primeira vídeo aula da série: “ASP.NET MVC – Início, Meio e Fim – Parte 2 – Entendendo a estrutura de uma aplicação ASP.NET MVC”. Bom aprendizado e não deixe de enviar seus comentários, eles são de fundamental importância para nós. 🙂 .
Facebook
Twitter
Instagram
LinkedIn
RSS