Artigo .net Magazine 65 - ASP.NET: WebForms X MVC

Comparando as duas formas de desenvolver aplicações ASP.NET com WebForms e MVC.

Por que eu devo ler este artigo:Entenderemos melhor os benefícios do ASP.NET MVC ao compará-lo com o uso convencional do ASP.NET, que é através dos WebForms. Na comparação deste artigo você verá como fazer no ASP.NET MVC aquilo que já está acostumado a fazer com os WebForms.

Neste artigo veremos como desenvolver uma aplicação ASP.NET da maneira convencional através de WebForms, em comparação com mais nova forma de se criar aplicações no ASP.NET, que é através do ASP.NET MVC Framework.

Guia do artigo:

O ASP.NET MVC Framework é uma nova arquitetura para a construção de aplicações Web que a Microsoft vem desenvolvendo. Este novo framework utiliza os conceitos do padrão MVC (Model-View-Controller), que oferece um novo paradigma no desenvolvimento de aplicações ASP.NET.

O padrão MVC para o de desenvolvimento de aplicações sugere que uma aplicação seja dividia em três partes distintas: Model (Modelo), View (Visão ou Interface) e Controller (Controlador). O ASP.NET MVC Framework que vem sendo desenvolvido pela Microsoft, é a implementação do padrão MVC para a construção de aplicações ASP.NET.

Neste artigo iremos entender em detalhes o que é e como utilizar o ASP.NET MVC. E para fazermos isso de forma bem simples, iremos comparar o desenvolvimento de uma aplicação ASP.NET MVC com uma aplicação ASP.NET convencional, que utiliza os já conhecidos WebForms.

Os Web Forms são o coração e a alma do ASP.NET. Eles são os elementos de Interface de Usuário (UI) que dão a aparência da sua aplicação. Os Web Forms são similares aos Windows Forms, que oferecem propriedades, métodos, e eventos para os controles que são inclusos nele.

Entretanto, nos Web Forms estes elementos UI são renderizados na linguagem de markup apropriada, como o HTML. Se você usa o Microsoft Visual Studio, você ainda terá os familiares recursos de drag-and-drop para a criação da Interface de Usuário da sua aplicação Web.”

Calma, você não está lendo uma edição antiga da .NET Magazine, esse texto foi retirado e traduzido do artigo Introduction to ASP.NET and Web Forms, de autoria de Paul D. Sheriff, publicado no MSDN em Novembro de 2001.

MSDN é a sigla para Microsoft Developers Network, que é como o próprio nome diz, uma rede voltada para os desenvolvedores da plataforma Microsoft. Além de um Web Site onde podemos encontrar um vasto material, ter acesso a blogs e fóruns, o MSDN também se popularizou por ser uma completa biblioteca que vem junto com o Visual Studio. Hoje podemos acessar tudo isso via internet mesmo, através do site: http://msdn.microsoft.com/en-us/default.aspx na versão “gringa”. Ou na versão “brasuca” em: http://msdn.microsoft.com/pt-br/default.aspx.

Felizmente 2001 não foi um ano marcado apenas pelos atentados terroristas às torres gêmeas. Esse foi um ano de muita expectativa no mercado de desenvolvimento de software. A Microsoft já havia anunciado uma nova plataforma de desenvolvimento, que viria a substituir a forma como estávamos desenvolvendo nossas aplicações, com VB6 e ASP na plataforma Microsoft. Aliás, a grande expectativa era exatamente pelo sucessor do ASP, o ASP.NET.

No texto acima podemos notar a importância que foi dada ao assunto na época. E não era por menos, o ASP.NET e Web Forms foram e continuam sendo o maior sucesso. O ASP.NET deu tão certo que esse texto continua publicado há oito anos no MSDN, confira lá: http://msdn.microsoft.com/en-us/library/ms973868.aspx.

Este artigo, apesar de introdutório, é um ótimo resumo do que é e como funciona o Web Form do ASP.NET. O texto é curiosamente concluído com os dizeres: “Migrar para o ASP.NET é tão fácil quanto sair do Visual Basic 6.0 e ir para o desenvolvimento em ASP”. Apesar de haver controvérsias quanto à facilidade dessa migração, muita gente seguiu este caminho, e está muito contente com o resultado.

E eis que passados sete (ou oito) anos do surgimento do ASP.NET, agora em 2008/2009 o pessoal da Microsoft vem com um tal de ASP.NET MVC Framework, que habilita a criação de aplicações ASP.NET no famoso e cultuado padrão MVC (Model-View-Controller).

Tocamos num ponto importante. Uma palavrinha que gera expectativa e receio ao mesmo tempo: Migrar. Aliás esta é uma das frases que eu mais ouvi desde que trabalho com desenvolvimento de software: Vamos Migrar!

Mas calma, se você espera que eu vá pregar aqui a ideia de que você precisa migrar as suas aplicações ASP.NET Web Forms para ASP.NET MVC Framework, está enganado. Essa é justamente uma das características que tornam o ASP.NET MVC Framework interessante.

O ASP.NET não vai ganhar coração e alma novos, o MVC vem pra agregar e não substituir. Ele será uma opção alternativa a ser considerada e ponderada ao criar nossas aplicações Web. Como veremos no decorrer deste artigo, que irá comparar as duas tecnologias (Web Form X MVC), o Web Form continua firme e forte.

O ASP.NET terá agora, dois corações e duas almas!

ASP.NET Web Forms

Antes de entrarmos nos detalhes do padrão MVC e da framework do ASP.NET que o implementa, vamos voltar um pouco no tempo e entender os Web Forms do ASP.NET, que surgiram lá no início dessa história (veja um resumo da história da plataforma .NET na nota do DevMan).

As Versões do .NET Framework e Visual Studio

Visual Studio 2002 / .NET Framework 1.0

O Microsoft .NET Framework e o Visual Studio compõem o que chamamos de plataforma de desenvolvimento da Microsoft. A primeira versão oficial da plataforma surgiu em fevereiro de 2002, com o .NET Framework 1.0 e Visual Studio 2002 (code-nome Rainer). Esse primeiro release da então nova plataforma de desenvolvimento da Microsoft foi pouco conhecido e utilizado, e logo deu lugar ao:

Visual Studio 2003 / .NET Framework 1.1

Um ano depois, em Abril/2003 surgiu mais uma versão da plataforma, esta chamada de .NET Framework 1.1 e Visual Studio 2003 (code-nome Everett). Essa sim foi uma versão amplamente utilizada pela comunidade. (até hoje ainda tem gente que desenvolve ou dá manutenção em aplicativos feitos no VS2003).

Visual Studio 2005 / .NET Framework 2.0

Em Outubro de 2005 a Microsoft lança uma versão mais “madura” da plataforma, é o .NET Framework 2.0 com o Visual Studio 2005 (code-nome Whidbey). Muita coisa foi melhorada nessa versão, tanto que a partir daqui os frameworks passaram a se “complementar” ao invés de se “sobreporem”.

.NET Framework 3.0

No lançamento do Windows VISTA surgiu uma nova versão da Framework, a 3.0. Essa versão foi marcada pela inclusão das tecnologias: Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow Foundation e Windows CardSpace. Apesar de não ter “saído” um novo Visual Studio, foi possível utilizar essas tecnologias através de pacotes que eram instalados na versão 2005.

Visual Studio 2008 / .NET Framework 3.5

Em Novembro de 2007 foi o lançamento do .NET Framework 3.5 e do Visual Studio 2008 (code-nome Orcas). Essa é a versão atual e que a maioria dos desenvolvedores .NET está trabalhando. Ela foi marcada principalmente pela introdução da linguagem LINQ, e por permitir a fácil migração de projetos feitos na versão anterior.

Visual Studio 2010 / .NET Framework 4.0

Em Setembro/2008 a Microsoft publicou a primeira nota a respeito da versão da plataforma que está sendo desenvolvida, e tem previsão de lançamento para o ano de 2010. É o .NET Framework 4.0 e o Visual Studio 2010 (code-nome Hawaii). Apesar de o ASP.NET MVC Framework seguir como um projeto independente, espera-se que ele seja incorporado ao ASP.NET 4.0, que virá junto com o .NET Framework 4.0

Web Forms são arquivos com extensão .aspx que surgiram junto com o ASP.NET lá no início, com a versão 1.0 do framework. Falando apenas do mundo Microsoft, os Web Forms surgiram como forma alternativa às páginas .asp, que usam basicamente HTML e VB script.

As páginas .aspx são escritas em uma linguagem de marcação própria, também chamada de ASP.NET. Um Web Form possui uma tag chamada form no início, com um atributo: runat=’server’. Esse atributo indica que a página é processada no servidor.

A lógica é mais ou menos a seguinte: O usuário digita uma URL no seu browser que aponta para uma página .aspx. Essa página é nada menos do que um arquivo em disco, armazenado lá no servidor. O ASP.NET (que obviamente está instalado no servidor) vai utilizar essa página .aspx como um template, que será interpretado, processado e retornado ao browser do usuário na forma de uma página HTML (com um toque de JavaScript, dependendo da página). De uma forma simplificada é assim que funciona.

Além disso, os Web Forms trouxeram na época, uma abordagem totalmente diferente. Foram introduzidos os Page Handlers, que disparam diversos eventos a partir do Web Form: PreInit, Init, PreLoad, Load etc.

Similar a forma que já estávamos acostumados a trabalhar com os Windows Forms, os eventos foram sugeridos no ASP.NET como a forma correta de fazer chamadas à “lógica de negócio” da aplicação (Regras de Negócio, Acesso a Dados etc).

Estes novos eventos dos Web Forms passaram a nos permitir a utilização de código gerenciado e orientado a objetos. Foi uma mudança e tanto para quem estava acostumado ao HTML e VB Script das páginas .asp.

MVC (Model – View – Controller)

É claro que a arquitetura dos Web Forms não agradou a todos, e com o tempo foram surgindo algumas alternativas, mesmo dentro do ASP.NET. Algumas dessas alternativas propõem adoção de certos padrões, como o MVP (Model – View – Presenter) e o famoso MVC (Model – View – Controller).

O padrão MVC é um padrão muito popular no desenvolvimento de aplicações Web, principalmente no meio do software livre, mas que recentemente vem ganhando espaço na plataforma .NET.

A primeira vez que se falou de MVC foi em 1979, e quem falou foi Trygve Reenskaug, então funcionário da Xerox que trabalhava no projeto do SmallTalk. Mas foi na Web que o MVC se popularizou, principalmente na comunidade do software livre.

O MVC propõe que a aplicação seja dividida em três partes:

Model: é a camada responsável por manter o estado dos dados. No Model temos uma representação em Objetos dos dados do database. Por exemplo, podemos ter no Model uma classe Produtos que irá representar os dados da tabela Produtos do banco de dados.

View: é a camada responsável por exibir os dados ao usuário. É basicamente a interface da aplicação, e em uma aplicação ASP.NET a interface pode ser uma página ou controle de usuário. Como exemplo podemos ter uma página Produtos.aspx que terá os controles necessários para exibir e editar os dados de um objeto da classe Produto.

Controller: esta camada é responsável por gerenciar a interação com o usuário final, manipulando a camada Model, e até definindo qual View será utilizada para exibir a interface ao usuário. Em uma aplicação MVC, a camada View é usada apenas para a exibição dos dados, é o Controller que responde às entradas e interações do usuário.

O MVC foi muito adotado na comunidade Java, mas também vem ganhando grande espaço na plataforma .NET. Não é à toa que o ASP.NET MVC Framework está aí. Mas antes dele, surgiram outras implementações. Um dos projetos mais conhecidos, que além de outras coisas, implementa o MVC em aplicações .NET, é o Ruby on Rails: http://rubyonrails.org.

Nota do DevMan

MVP (Model – View – Presenter) é um padrão para desenvolvimento de software originado no começo dos anos 90 em uma organização chamada Taligent (Joint venture entre Apple, IBM e HP). Originalmente foi criado para ser utilizado em aplicações desenvolvidas em C++, mas logo foi adaptado para Java.

É considerado pelos seus criadores como uma atualização do MVC (Model – View – Controller), e de fato é bem parecido. Sua sigla propõe que o software seja dividido em três partes:

Model ou Model-Business, representa os Business Facades, Services, Data Access Objects (ou qualquer nome que você quiser dar). É a parte da aplicação que lhe permite o acesso aos dados, através de métodos como Add(), Remove(), Update(), etc O View expõe propriedades do seu respectivo Presenter, que por sua vez executa todas as chamadas necessárias no Model. Diferente do MVC, as requisições do usuário são gerenciadas pelos métodos da View. Nestes métodos é que o Presenter é acionado para se comunicar com o Model.

O MVP pode ser utilizado em aplicações .NET, sejam elas ASP.NET, Windows Forms, WPF ou Silverlight. Existem inclusive, vários frameworks que oferecem recursos para facilitar o uso deste padrão. Seguem algumas referências:

  • http://www.codeproject.com/KB/architecture/ModelViewPresenter.aspx
  • http://stormwind-trac.cvsdude.com/NMVP
  • http://www.mvcsharp.org/

ASP.NET MVC Framework

Eis então que a Microsoft oferece um Framework que dá suporte ao desenvolvimento de aplicações ASP.NET no padrão MVC. Essa conversa começou há mais de um ano, quando foi anunciado o desenvolvimento do MVC framework no final de 2007.

Depois de vários CTPs, Previews, Betas, Releases Candidates etc., no último dia 9 de abril (2009) foi lançada a primeira versão do ASP.NET MVC Framework. Você tem acesso ao download através do site principal do ASP.NET MVC: http://www.asp.net/mvc/, que você também confere na Figura 1.

Figura 1. Site principal do ASP.NET MVC Framework.

Na página de download você verá que é possível baixar um arquivo .msi para a instalação do ASP.NET MVC, um arquivo .doc contendo um Release Notes e um arquivo .zip contendo todo o código fonte do ASP.NET MVC.

Voltando na página principal que você vê na Figura 1, temos uma enorme quantidade de material sobre ASP.NET MVC: Tutoriais, Vídeos, Aplicações de Exemplo, Artigos, Blogs etc. Não vai ser por falta de material que não vamos aprender ASP.NET MVC.

Além de todo esse material disponível no site, o Scott Guthrie, vice-presidente da divisão de Desenvolvimento da plataforma .NET na Microsoft, disponibilizou gratuitamente o capítulo de um livro sobre ASP.NET MVC, que ele próprio ajudou a escrever. Confira aqui: http://www.wrox.com/WileyCDA/Section/id-321793.html?cid=0311hottopics3

Neste ponto, se você tem intenção de realizar os exemplos que irei expor a seguir, sugiro que baixe e instale o ASP.NET MVC Framework em seu computador. Lembrando que ele funciona em cima do ASP.NET 3.5 Service Pack 1, e consequentemente necessita do Visual Studio 2008.

Você pode inclusive, utilizar o Visual Web Developer 2008, a versão gratuita do Visual Studio 2008 para o desenvolvimento de aplicações Web. A única restrição em utilizar essa edição é que com ela você não terá os recursos de Testes que temos na versão Professional ou Standard.

A instalação não tem segredo, basta seguir o Wizard que em questão de segundos você terá o ASP.NET MVC instalado.

WebForms X MVC: Criando uma aplicação no Visual Studio

Como disse anteriormente este é um artigo comparativo, e para começar vamos criar um projeto Web Forms e outro MVC, para analisar as diferenças.

Sendo assim abra o seu Visual Studio 2008 e vá até o menu File / New / Project. Como você pode ver na Figura 2, temos vários templates de projetos na seção Web. O primeiro template, o ASP.NET Web Application é o mais comum de todos, e utilizado para criar aplicações ASP.NET na arquitetura de Web Forms.

Figura 2. Templates para criar aplicações ASP.NET WebForms e MVC.

Se você instalou o ASP.NET MVC, e selecionou o .NET Framework 3.5 nessa mesma janela, verá que temos aqui o template ASP.NET MVC Web Application. Esse é o template para a criação de aplicações ASP.NET na arquitetura MVC.

Eu vou criar dois projetos, em solutions distintas. Um com o template ASP.NET Web Application, que se chamará ExemploWebForm. E outro com o template do MVC, que se chamara ExemploMVC. Você pode criar cada um em uma instância diferente do Visual Studio, assim fica mais fácil a comparação entre os dois.

A criação de uma aplicação Web com o template para WebForms não tem segredo. Já ao criarmos o projeto com o template ASP.NET MVC Web Application, já temos uma surpresa logo no início.

Assim que confirmamos a criação do projeto, uma segunda janela é exibida, perguntando se desejamos criar um projeto de testes unitários para nossa aplicação, veja na Figura 3.

Figura 3. Criando um projeto para testes unitários da aplicação ExemploMVC.

Podemos escolher por criar ou não este projeto. A não ser que você esteja utilizando o Visual Web Developer, neste caso a criação do projeto de testes não será uma opção.

Ao optarmos por criar um projeto de teste unitário, podemos definir um nome ou utilizar o nome que Visual Studio sugere, que é bem elucidativo. Além disso, podemos definir qual será a framework de testes que este projeto irá utilizar. A única que temos aqui é a do próprio Visual Studio, mas se você tiver instalado outro framework de testes, poderá utilizá-la sem problemas.

Essa é a primeira diferença que notamos em um projeto feito no ASP.NET MVC. Não que seja impossível criar testes unitários em projetos Web Forms, longe disso. Mas no ASP.NET MVC, o uso de testes unitários já é sugerido logo no início, permitindo de uma maneira muito natural que você aplique as técnicas do TDD (Test Driven Development), que defende um desenvolvimento orientado à Testes.

Nota do DevMan

A utilização do MVC nos possibilita uma outra filosofia de desenvolvimento de aplicações, o TDD. TDD é a sigla para Test Driven Development, que quer dizer: Desenvolvimento Orientado a Testes.

Por mais incrível e impossível que possa parecer, com o TDD nós desenvolvemos nossas aplicações pensando primeiro nos mecanismos de testes. Ou seja, com o TDD você primeiro implementa Unit Tests automatizados, que irão definir e verificar (testar) os requerimentos do seu código. Só depois que você efetivamente irá codificar.

Os Unit-Tests ou testes unitários são uma ótima forma de automatizarmos os testes de nossas aplicações. Os Unit-Tests são classes que criamos para testar os nossos métodos. O código de um Unit-Test deve validar todas as possíveis entradas (parâmetros) e saídas (retornos) de um método, atestando de uma forma automática a eficiência do método.

No Visual Studio Team System 2008 temos uma suíte específica para testes, chamada Visual Studio Team Test (TT). Com ele temos diversas features que nos ajudam a criar e utilizar os Unit-Tests. Algumas dessas principais features compreendem:

  • Geração automática de código dos Unit-Tests, baseado é claro, nos métodos que queremos testar;
  • Execução dos testes pelo própria IDE;
  • Incorporação de teste de leitura de dados de um database;
  • Ferramenta de Analise de Código;

O Conjunto de features relacionadas à Unit-Tests no Visual Studio está no Unit Testing Framework sob o namespace: Microsoft.VisualStudio.TestTools.UnitTesting. Maiores infomações sobre o Unit Testing Framework podem ser encontradas no seguinte link: http://msdn.microsoft.com/en-us/library/ms243147(VS.80).aspx

A .NET Magazine já publicou diversos artigos que abordam o desenvolvimento orientado a testes, inclusive uma série realizada pelo Giovanni Bassi, que vai da edição 53 a 55.

Estrutura dos projetos

Cada template de projetos do Visual Studio, além de definir qual será a interface de usuário da aplicação (Windows Forms, ASP.NET, WPF etc.), possui algumas características peculiares, que podem ser observadas na Solution Explorer.

Dependendo do template que escolhemos, temos alguns arquivos e estrutura de pastas que são criados automaticamente no projeto. Ao compararmos a estrutura de um projeto Web Form com um projeto MVC, notamos várias diferenças. Confira na Figura 4.

Figura 4. Diferença na estrutura dos projetos WebForm X MVC.

Como notamos logo de cara, um projeto Web Forms tem uma estrutura muito mais enxuta do que um projeto MVC. Isso se deve ao fato que em projetos WebForms focamos o desenvolvimento em páginas .aspx, enquanto no MVC temos que obedecer um padrão. Tanto que do lado MVC você pode observar que já temos as pastas: Models, Views e Controller

Além dessas, temos outras três pastas, porém apenas uma dessas pastas existe no projeto Web Forms, a App_Data. Veja na Tabela 1 um resumo do objetivo de cada uma dessas pastas.

Pasta

Objetivo

/App_Data

Onde você pode armazenar arquivos de banco de dados.

/Content

Onde você coloca arquivos .CSS, imagens, ou qualquer outro arquivo de conteúdo estático, e que não seja JavaScript.

/Controllers

Onde você coloca as classes Controllers, que irão gerenciar as requisições de URL.

/Models

Onde você coloca as classes que representam e manipulam os dados.

/Scripts

Onde você coloca arquivos de script em geral (.js).

/Views

Onde você coloca os templates de UI, responsáveis por renderizar a saída.

Tabela 1. Pastas do projeto MVC.

O ASP.NET MVC não força a utilização dessa estrutura. Na verdade, desenvolvedores que trabalham em grandes projetos irão provavelmente dividir a aplicação entre diversos projetos, numa estrutura de camadas, para tornar a solução muito mais gerenciável. Prática essa que já é muito comum nos Web Forms.

Entretanto, esse padrão proposto para o projeto MVC, oferece uma estrutura bem intuitiva, ajudando a manter nossa aplicação organizada, no caso de mantermos todas as camadas no mesmo projeto.

Além da estrutura de diretórios oferecida no projeto MVC, nós também já temos algum conteúdo nessa estrutura. Dentro da pasta Controllers, por exemplo, você já pode notar a existência de duas classes: HomeController e AccountController. Se abrirmos a pasta Views, vamos encontrar três pastas: Account, Home e Shared. Não é por coincidência que os nomes são os mesmos utilizados no Controller.

O que acontece é que para cada Controller vamos ter uma ou mais Views, que estarão em pastas separadas. Por isso temos uma pasta chamada /View/Home, e dentro dela as páginas que são “controladas” pelo HomeController. Na prática essa dinâmica ficará mais clara.

Na pasta Content você irá encontrar um arquivo style.css, que por default vem em todo projeto ASP.NET MVC. É claro que você pode e deve modificá-lo, criando o seu próprio design. Já na pasta Script iremos encontrar uma série de arquivos, que habilitam o uso do AJAX e do JQuery no MVC.

Nota do DevMan

jQuery é uma biblioteca Javascript leve, que enfatiza a interação entre JavaScript e HTML. Ela foi lançada em Janeiro de 2006 por John Resig. jQuery está sob a licença GPL, e portanto é open source.

Tanto a Microsoft quanto a Nokia anunciaram planos para adotar o jQuery em suas plataformas. Inicialmente a Microsoft está adotando o jQuery no Visual Studio, ASP.NET AJAX e no próprio ASP.NET MVC Framework. Enquanto a Nokia irá integrar o jQuery na sua plataforma Web.

Assim como o CSS separa as características visuais do HTML, o jQuery propõe a separação das características de "comportamento" da estrutura HTML. Como exemplo, ao invés de especificarmos o event handler on-click no HTML do Button, uma página com jQuery vai primeiro identificar o elemento Button, e então modificar o seu event handler on-click.

E por fim você pode notar que na Solution Explorer do ExemploMVC, ainda temos o projeto ExemploMVC.Test. Um projeto de testes no ASP.NET MVC vai testar nossa aplicação através das classes Controllers, pois são elas que gerenciam todas as requisições. É por isso que já temos duas classes de testes neste projeto, uma para cada uma das classes Controllers existentes.

Hello World ASP.NET MVC!

Como foi dito lá no início deste artigo a alma do ASP.NET é o Web Form, e a alma do Web For é os Page Handler, que é o que torna o Web Form parecido com o Windows Form: um ambiente controlado basicamente por eventos.

Se eu pudesse resumir o que é o ASP.NET Web Form em uma única imagem, seria a Figura 5. Primeiro nós arrastamos os controles (Button e Label) da ToolBox para a página Default.aspx. Em seguida configuramos o Event Handler onclick do Button, que aponta para o método Button1_Click do code-behind da página (Default.aspx.cs).

Figura 5. Dinâmica dos eventos no ASP.NET Web Form.

Este método executa um código gerenciado e orientado a objetos (C#), que simplesmente modifica a propriedade Text do Label que também está na página. O resultado você pode ver executando o projeto e clicando no Button. É assim que os WebForms funcionam no ASP.NET, e é isso o que muda no MVC.

Para criar nosso primeiro exemplo com o MVC, que irá fazer nada mais nada menos do que um Hello World, vamos prosseguir passo a passo. Clique com o botão direito sobre a pasta Controllers do projeto ExemploMVC, e como você pode conferir na Figura 6, temos uma opção chamada Add / Controller.

Figura 6. Criando um novo Controller no projeto.

Como você pode notar, agora na Figura 7, é exibida uma pequena janela solicitando o nome do nosso Controller. Para manter um bom padrão de nomes, substitua a palavra Default1 por HelloWorld.

Veja que nessa mesma janela temos uma opção que pergunta se queremos criar os métodos para os cenários de Create, Update e Details. Não é o caso agora, mas iremos ver como essa opção é útil adiante. Basta então clicar em Add.

Figura 7. Criando um novo Controller.

Note que a classe HelloWorldController é criada com o mesmo código que você pode ver na Listagem 1. Veja que por padrão já são importados os namespaces System.Web.Mvc e System.Web.Mvc.Ajax, que é onde se encontram os recursos do ASP.NET MVC Framework, e os recursos de AJAX para ele.

Listagem 1. Código da Classe HelloWorldController.
using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; using System.Web.Mvc.Ajax; namespace ExemploMVC.Controllers { public class HelloWorldController : Controller { // // GET: /HelloWorld/ public ActionResult Index() { return View(); } } }

Uma classe de Controller herda da classe do ASP.NET MVC Controller. E além disso, ela implementa o que chamamos de Action Methods, ou métodos de ação. Como você vai entender aos poucos, é através dos Controllers e dos Action Methods que temos as URLs da nossa aplicação.

O resultado da execução de um Action Method é a renderização de uma View. É por isso que um Controller pode ter uma ou mais Views, isso vai depender do que faz cada um dos Action Methods.

Por default, todos os Controllers já ganham um Action Method chamado Index. Porém nosso controle ainda está órfão, ou seja, não tem nenhuma View para ser renderizada. Para criarmos a View que será renderizada pelo Index, basta clicar com o botão direito sobre o método e escolher a opção Add View, conforme mostra a Figura 8.

Figura 8. Criando a View que será renderizada pelo método Index.

Essa opção irá abrir uma janela igual a da Figura 9, e a partir dessa janela definimos algumas características da View que estamos criando. Veja por exemplo, que podemos definir uma partial view (View Parcial), que nada mais é do que um user control, com extensão .ascx.

Figura 9. Criando a View Index do HelloWorldController.

Também podemos definir uma View baseada em um classe de dados, de um modelo predefinido. Como iremos ver adiante isso facilita muito o trabalho com o MVC, tornando um pouco menos assustador nesse começo.

Por fim, ao criar uma View você também pode definir se quer utilizar uma Master Page, recurso que é muito comum e utilizado em Web Forms, e tem papel de igual importância no ASP.NET MVC. Neste exemplo de HelloWorld, não vamos escolher nenhuma dessas opções. E ao clicar em Add, você verá que dentro da pasta Controller será criada outra pasta, chamada HelloWorld, e dentro dela temos uma página Index.aspx.

A primeira coisa a ser notada em uma View do MVC, é que ela não tem code-behind. Veja na Listagem 2 como é simples o código desta página. Note que diferente de um WebForm, também não temos a tag form com o runat=’server’.

Listagem 2. Código da View Index.aspx.
<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>Index</title> </head> <body> <div> </div> </body> </html>

Essa é uma das grandes mudanças no MVC, as páginas não são templates interpretados no servidor, elas são o resultado de um Action Method, processado no Controller. Para quem está acostumado com os Web Forms, no começo pode parecer loucura, mas aos poucos vamos nos acostumando à ideia.

Para o nosso exemplo poder dizer Hello, vamos incluir uma linha de código dentro desse div na Index.aspx, que deverá ficar como mostra a Listagem 3.

Listagem 3. Incluindo um Link que aponta para outro Action Method.
<body> <div> <%= Html.ActionLink("Hello", "SayHello", "HelloWorld")%> </div> </body>

Através dessa classe Html, podemos criar um link que irá apontar para um outro Action Method do HelloWorldController. Veja que este método ActionLink irá criar o link de acordo com os parâmetros passados, que são: o Label do Link, o nome do método e o nome do Controller.

Para que isso funcione, precisamos criar o método SayHello lá no nosso HelloWorldController. Sendo assim, inclua o código da Listagem 4 na classe HelloWorldController.cs.

Listagem 4. Método SayHello.
public ActionResult SayHello() { ViewData["Message"] = "Hello World ASP.NET MVC!"; return View(); }

Note que o método SayHello é igual ao Index, exceto pelo uso do dicionário ViewData, onde estamos gravando uma mensagem com os dizeres do Hello World. De uma forma simplista podemos dizer que este ViewData está para o MVC assim como o ViewState está para o WebForm.

A diferença é que o ViewData não vai ficar trafegando entre os postbacks de página, mesmo porque no MVC não temos PostBack. Lembre-se, todas as requisições são tratadas no Controller, a página .aspx no MVC é só o resultado final, e o ViewData aqui é usado como uma forma de passar dados do Controller para a View.

Precisamos agora criar uma View para exibir essa mensagem. Vamos criá-la da mesma forma que criamos a View Index, com a diferença que essa View se chamará SayHello.aspx, e seu código deverá ficar como mostra a Listagem 5.

Listagem 5. View SayHello.aspx.
<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head runat="server"> <title>SayHello</title> </head> <body> <div> <h2><%= Html.Encode(ViewData["Message"]) %></h2> <%= Html.ActionLink("Back", "Index", "HelloWorld")%> </div> </body></html>

Nesse ponto é importante fazermos um teste. Salve, compile e execute sua aplicação. Você verá que a página que será exibida é o Index do HomeController. Isso acontece, pois esse é Controller de início da aplicação, quando a URL apontar para a raiz. Para acessarmos o nosso HelloWorldController, você deverá digitar na barra de endereços o seguinte:

http://localhost:49594/HelloWorld

Nota: a porta pode variar de acordo com o estado atual do servidor local.

Veja na Figura 10, que a página exibe apenas o Link chamado Hello. Se clicarmos neste link seremos remetidos para o ActionMethod SayHello do Controller, que por usa vez vai renderizar a View SayHello, com a mensagem contida no ViewData. Se você clicar em Back, voltamos a executar o Action Method Index que nos remete a página anterior.

Figura 10. Dinâmica das chamdas do MVC.

Esse deve ser o Hello World mais complicado de toda a história dos Hello Worlds! Mas dá pra entendermos duas coisas importantes aqui. Primeiro é a importância do Controller no MVC, pois é ele quem gerencia todas as chamadas, através de uma lógica de roteamento que entenderemos melhor a seguir. E segundo, é que o ASP.NET MVC não deve ser utilizado para aplicações banais como essa.

Mas um pouco de perspectiva pode minimizar um pouco a estranheza que o modelo MVC causa nesse momento. É só lembrar como foi migrar de ASP para ASP.NET.

Page Handler X Routing Handler

Se eu fosse resumir em poucas palavras o que é o ASP.NET MVC, eu diria que é a substituição do Page Handler que temos no Web Form, por um mecanismos de roteamento. Assim, em primeiro lugar não temos mais um ambiente Web orientado a eventos disparados pelas páginas, e sim um sofisticado gerenciamento de rotas, onde todas as requisições são URLs, mapeadas para Controllers e Action Methods.

É claro que o ASP.NET MVC não é só isso, mas é em cima dessa mudança que temos um enorme leque de novas possibilidades. O mecanismo que faz o controle das rotas das URLs no ASP.NET MVC se chama ASP.NET Routing. É ele que nos permite ter uma lógica de URLs que não apontam para arquivos em disco.

Temos dois ganhos importantes com isso: primeiro que esse modelo nos permite criar um mapeamento entre as URLs e os Controllers, viabilizando uma das premissas básicas do MVC. E segundo que as URLs acabam se tornando mais “amigáveis” para o usuário final, permitindo que ele acesse recursos através de URLs, de forma intuitiva.

O ASP.NET Routing permite que criemos lógicas específicas para as URLs da aplicação, e no caso do ASP.NET MVC, essa lógica já está previamente configurada no arquivo Global.asax, veja na Listagem 6.

Listagem 6. Configuração de rotas do ASP.NET Routing no Global.asax.
using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; using System.Web.Routing; namespace ExemploMVC { // Note: For instructions on enabling IIS6 or IIS7 classic mode, // visit http://go.microsoft.com/?LinkId=9394801 public class MvcApplication : System.Web.HttpApplication { public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute(".axd/{*pathInfo}"); routes.MapRoute( "Default", // Route name "//", // URL with parameters new { controller = "Home", action = "Index", id = "" } // Parameter defaults ); } protected void Application_Start() { RegisterRoutes(RouteTable.Routes); } } }

Note que o seguinte padrão é utilizado no mapeamento das Rotas no MVC:

//

Este padrão indica que a URL é dividida em três partes, que identificam o Controller, o Action Method e uma terceira parte, que se informada, identifica um parâmetro ID, que pode ser utilizado para recuperar o ID de um determinado objeto.

Além disso, nessa mesma chamada do método MapRoute, é onde definimos a rota default, que será utilizada quando a URL apontar para a raiz da aplicação. É por isso que quando executamos a aplicação ela exibe a página Index do HomeController.

Definindo um modelo

Até aqui vimos os conceitos básicos do ASP.NET MVC Framework, vamos agora criar um exemplo mais elaborado, que faça acesso a um modelo. Para facilitar o nosso trabalho vamos utilizar um banco de dados já existente, e nada melhor do que o famoso Northwind.

Nota

O Database Northwind é uma banco de dados do SQL Server para testes e com estrutura definida para uma aplicação de vendas, onde temos Produtos, Clientes, Fornecedores, Pedidos, etc. A Microsoft disponibiliza este database já com dados através do seguinte link: http://www.microsoft.com/downloads/details.aspx?FamilyID=06616212-0356-46A0-8DA2-EEBC53A68034&displaylang=en

Faça o download e execute o arquivo de instalação. Ao término da instalação, os databases de exemplo do SQL Server 2000 serão instalados na pasta C:\SQL Server 2000 Sample Databases. Você pode obviamente movê-los para o local da sua conveniência, e adicioná-los no SQL Server através do comando Attach.

Em seguida precisamos criar um modelo. E como estamos fazendo uma comparação entre WebForms e MVC, vamos criar o mesmo modelo nos dois projetos. É claro que com um pouquinho de esforço poderíamos criar um único modelo e reaproveitá-lo nos dois projetos, mas a criação de um modelo baseado no banco de dados é tão simples que não vale a pena.

No ASP.NET MVC o termo Model se refere aos objetos que representam os dados da aplicação, assim como a lógica correspondente que integra a validação e as regras de negócio que envolvem estes dados. O Modelo pode ser considerado o coração de uma aplicação baseada em MVC, e é ele que irá determinar a maior parte do comportamento da aplicação.

Tanto em WebForms quanto em MVC temos uma série de ferramentas que nos permitem a criação de um modelo para a representação dos dados de um database. Entre elas podemos citar: ADO.NET Entity Framework, LINQ to SQL, NHibernate, LLBLGen Pro, SubSonic, WilsonORM, ou até simplesmente os ADO.NET DataReaders ou DataSets.

Como é possível utilizar qualquer uma dessas ferramentas, vamos pela mais fácil. O objetivo deste artigo não é explicar como criar elaborados Modelos, e sim mostrar as principais diferenças dos Web Forms para o MVC. Sendo assim usaremos o LINQ to SQL, que permite a criação de um modelo simples, apenas arrastando as tabelas do banco de dados.

Nota:

Você vai encontrar uma série de artigos na .NET Magazine ou no site da DevMedia, assim como uma grande quantidade de vídeo-aulas, todas voltadas para a criação de Modelos com ferramentas como o ADO.NET Entity Framework, LINQ to SQL, Datasets Tipados, NHibernate etc.

É importante lembrar que se você pretende fazer os exemplos dos dois lados (WebForms e MVC), vai precisar criar este modelo nos dois projetos. Esse processo de criação do Modelo com o LINQ to SQL, será o mesmo nos dois exemplos.

Para adicionar um modelo LINQ to SQL em um projeto Web Forms, basta clicar com o botão direito sobre o projeto e escolher a opção Add / New Item. Já no MVC é importante que o modelo seja criado dentro da pasta Model. Como mostra a Figura 11, clique com o botão direito sobre essa pasta e escolha a opção Add / New Item.

Figura 11. Adicionando um novo item de Modelo no projeto MVC.

Daí para frente o processo de criação do modelo é o mesmo para ambos os projetos. Na Figura 12 você pode ver como selecionar o template do LINQ to SQL. Veja também que o nome dado ao modelo foi DC_Northwind (em ambos os projetos).

Figura 12. Escolhendo o template LINQ to SQL para o Modelo (igual em ambos os projetos).

Em seguida, a criação do modelo segue a conhecida técnica drag-and-drop. Basta criar uma conexão com o database Northwind na Server Explorer, expandir as tabelas e arrastá-las para o LINQ to SQL, conforme você pode ver na Figura 13. Neste exemplo eu arrastei apenas as tabelas Products e Shippers. Elas já são mais do que o suficiente para o que precisamos.

Figura 13. Criando modelo LINQ to SQL que representará as tabelas Products e Shippers.

Como disse antes, você vai ter que fazer isso nos dois projetos para que seja possível realizar os exemplos dos dois lados. Não vamos entrar nos detalhes de como um modelo LINQ to SQL funciona, basta saber que ele é uma forma de representar em objetos, as tabelas do banco de dados.

Outra vantagem do uso do LINQ to SQL é que com ele não vamos precisar criar nenhum comando SQL para recuperar ou gravar dados no banco, tudo será gerado dinamicamente através da linguagem LINQ. Basta salvar, fechar o modelo e fazer um Build em cada um dos projetos.

CRUD com ASP.NET Web Forms

Este talvez seja um dos exemplos mais feitos e publicados em toda a vida do ASP.NET. Experimente digitar “asp.net crud” no Google. Eu tenho certeza que você já fez um exemplo de Inclusão, Alteração Consulta e Exclusão de registros no ASP.NET.

Mas como essas são as quatro operações básicas de qualquer aplicação que tenha um banco de dados por trás, vamos ter que fazer esse exemplo aqui também. Acredito que ele vai ilustrar bem as diferenças que temos que encarar ao passar de Web Form para MVC.

Existem dezenas de formas diferentes de se fazer o CRUD em ASP.NET Web Forms. Temos até controles desenvolvidos para automatizar isso. Sendo assim, vamos utilizar o que eu acredito que seja o mais fácil e simples de todos, o ListView.

O ListView é um controle do ASP.NET que foi lançado na versão 3.5, e disponível nas versões 2008 do Visual Studio. Ele é um controle que permite a realização do Bind com dados retornados em um determinado DataSource. Tive a oportunidade de escrever um artigo só sobre o ListView, que foi publicado na edição 55 da .NET Magazine.

Para usá-lo é muito simples. Abra a página Defalt.aspx do projeto ExemploWebForm, e vá até a seção Data da ToolBox. Temos dois controles aí que nos interessam: o ListView e o LinqDataSource, que vai nos ajudar a criar um datasource com o nosso modelo feito no LINQ to SQL.

Como você confere na Figura 14, arraste estes dois controles para a página Default.aspx. E em seguida, clique na opção Configure Data Source que está nas Tasks do LinqDataSource.

Figura 14. Incluindo o ListView e o LinqDataSource em um WebForm.

A configuração de um LinqDataSource é muito simples. Na primeira tela basta escolher o modelo, que já vai vir selecionado. Na segunda etapa desse wizard, vamos escolher a tabela Shippers e clicar em Finish. Em seguida, novamente nas Tasks do LinqDataSource, selecione as opções Enable Delete, Insert e Update, como mostra a Figura 15.

Figura 15. Habilitando exclusão, inclusão e alteração no LinqDataSource.

Agora, nas Tasks do ListView, no campo Choose Data Source, selecione o LinqDataSource1. E em seguida clique em Configure ListView. Confira na Figura 16.

Figura 16. Definindo o DataSource do ListView e clicando em Configure ListView.

A tela seguinte é onde configuramos o ListView. Veja na Figura 17 que temos uma série de opções de configuração de layout e estilo, mas que não vem ao caso neste artigo. Para este exemplo o importante é habilitar as opções de Edição, Inclusão e Exclusão de registros.

Figura 17. Configurando o ListView.

E é isso. Clique em Ok, salve, compile e execute o projeto ExemploWebForm. O resultado é uma interface simples, que permite a consulta, inclusão, alteração exclusão de registros. Confira na Figura 18.

Figura 18. Interface CRUD com ListView no ASP.NET Web Form.

É claro que para uma aplicação completa seria necessário certo refinamento. Mas o objetivo aqui é mostrar uma única coisa: essa é a dinâmica que temos disponível no ASP.NET Web Forms para a criação de interfaces que operam com o database.

Além do ListView, você pode observar que há mais uma série de controles na seção Data da ToolBox. Todos, de uma forma ou de outra, oferecem interfaces que interagem com o banco de dados. E a maioria deles vai lhe oferecer ferramentas visuais de configuração, parecidas com a do ListView.

A possibilidade de criar interfaces dessa maneira, através de ferramentas visuais, é uma característica marcante do ASP.NET Web Forms, que vem desde suas primeiras versões. Ferramentas como essa refletem diretamente na produtividade e na simplificação do trabalho, o que tornou o Web Form do ASP.NET um grande competidor no mercado.

CRUD com ASP.NET MVC

Vamos agora ver como realizar as mesmas operações CRUD no ASP.NET MVC. Com o nosso modelo pronto, o que temos que fazer agora é criar um Controller. Assim como fizemos no exemplo do Hello World, clique com o botão direito sobre a pasta Controller no projeto ExemploMVC, e escolha a opção Add / Controller (Figura 6).

Nosso Controller será responsável pelas operações CRUD na tabela Shippers, portanto vamos chamá-lo de ShippersController. E diferente do que fizemos no exemplo do Hello World, aqui vamos selecionar a opção Add action methods for Create, Update and Details scenarios. Confira na Figura 19.

Figura 19. Criando ShippersController com action methods Create, Update e Details.

Com essa opção marcada, ao clicar em Add, nosso Controller será criado com os Action Methods necessários para as operações CRUD, confira na Listagem 7. Veja que temos os métodos Index, Details, Create e Edit. Agora vamos ter que codificar cada um destes métodos para habilitar essas operações.

Listagem 7. Controller com Action Methods para operações CRUD.
using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Mvc; using System.Web.Mvc.Ajax; namespace ExemploMVC.Controllers { public class ShippersController : Controller { // // GET: /Shippers/ public ActionResult Index() { return View(); } // // GET: /Shippers/Details/5 public ActionResult Details(int id) { return View(); } // // GET: /Shippers/Create public ActionResult Create() { return View(); } // // POST: /Shippers/Create [AcceptVerbs(HttpVerbs.Post)] public ActionResult Create(FormCollection collection) { try { // TODO: Add insert logic here return RedirectToAction("Index"); } catch { return View(); } } // // GET: /Shippers/Edit/5 public ActionResult Edit(int id) { return View(); } // // POST: /Shippers/Edit/5 [AcceptVerbs(HttpVerbs.Post)] public ActionResult Edit(int id, FormCollection collection) { try { // TODO: Add update logic here return RedirectToAction("Index"); } catch { return View(); } } } }

Com vimos anteriormente, o método Index() é o método default de um Controller, e ele sempre será executado se a URL omitir o nome do método. Sendo assim, esse é um bom lugar para listarmos todos os registros da tabela. Sempre que o usuário acessar o ShippersController sem definir o método, a aplicação irá retornar uma lista com todos os Shippers cadastrados.

Para isso precisamos criar um private filed no nosso Controller, que será uma instância do nosso modelo, através do qual iremos realizar o acesso ao database. Veja na Listagem 8 como deve ficar esse Field, e também como fica a implementação do método Index.

Listagem 8. Criando instância do DataContext, e passando uma lista dos Shippers para a View.
using ExemploMVC.Models; namespace ExemploMVC.Controllers { public class ShippersController : Controller { private DC_NorthwindDataContext dc = new DC_NorthwindDataContext(); public ActionResult Index() { return View( dc.Shippers.ToList() ); }

A primeira coisa que você deve notar nesta listagem é que estamos importando o namespace ExemploMVC.Models, para que seja possível utilizar o modelo que criamos no LINQ to SQL. Em seguida, criamos um objeto da classe DC_NorthwindDataContext chamado dc. DC_NorthwindDataContext é a classe do LINQ to SQL que nos dá acesso ao modelo.

Veja então, que no método Index passamos como parâmetro para View uma lista que irá conter todos os registros da tabela Shippers, na forma de objetos é claro. É nesse momento que o LINQ to SQL vai criar dinamicamente o comando SQL para recuperar estes dados.

Clique com o botão direito sobre o método Index e escolha a opção Add View, assim como foi feito lá na Figura 8. Em seguida vamos criar uma strognly-typed view, conforme você vê na Figura 20.

Figura 20. Criando uma bly-typed view.

Note que ao marcar essa opção, podemos escolher a classe Shipper do nosso modelo. E ainda definir qual vai ser o View content. No caso estamos escolhendo o tipo List, que vai criar uma lista para a exibição dos Shippers.

Também podemos deixar marcada a opção Select master Page, para que nossa View seja criada com o aspecto visual padrão do ASP.NET MVC. Ao clicar em Add, uma página aspx é criada, com o conteúdo que você pode ver aqui na Listagem 9.

Listagem 9. Página Index.aspx do ShippersController.
<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage <IEnumerable<ExemploMVC.Models.Shipper>>" %> <asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server"> Index </asp:Content> <asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server"> <h2>Index</h2> <table> <tr> <th></th> <th> ShipperID </th> <th> CompanyName </th> <th> Phone </th> </tr> <% foreach (var item in Model) { %> <tr> <td> <%= Html.ActionLink("Edit", "Edit", new { id=item.ShipperID }) %> | <%= Html.ActionLink("Details", "Details", new { id=item.ShipperID })%> </td> <td> <%= Html.Encode(item.ShipperID) %> </td> <td> <%= Html.Encode(item.CompanyName) %> </td> <td> <%= Html.Encode(item.Phone) %> </td> </tr> <% } %> </table> <p> <%= Html.ActionLink("Create New", "Create") %> </p> </asp:Content>

Veja que é uma página muito simples, e que não usa nenhum controle ASP.NET. Tudo aqui é HTML, com exceção dos códigos que se encontram nas tags <% %>. É assim que a View consegue exibir os dados que foram passados via parâmetro pelo Controller.

Toda View recebe um objeto chamado Model, que devemos utilizar para passar um objeto ou coleção de objetos que irá conter os dados que serão utilizados pela View. Neste caso o nosso Model contém uma Lista de objetos da classe Shipper, o que nos permite percorrer esta lista através de um foreach.

Veja que dentro do foreach temos mais HTML, que irá gerar uma linha em uma tabela. Cada linha corresponderá a um objeto da lista. Além das propriedades que são acessadas através do item, também estamos criando dois ActionLinks, que irão chamar os respectivos Action Methods: Edit e Details. Lá no final, depois da tabela, temos mais um Action Link que irá chamar o método Create.

É claro que você pode fazer as alterações que quiser aqui, tanto no Layout quanto no próprio conteúdo que será exibido. Porém, mesmo sem mexer em nada já temos uma View funcionando, que irá listar todos os registros da tabela Shippers. Salve, compile, execute e veja o resultado na Figura 21.

Figura 21. View Index do ShippersController.

Agora já podemos codificar o método Create do Controller, para a inclusão de novos Shippers. Note que na classe ShipperController temos dois métodos Create. O primeiro, que não recebe parâmetro nenhum, é o método que irá exibir a View contendo o HTML necessário para que o usuário preencha os dados do novo Shipper. É esse o método que será chamado no ActionLink criado na View Index.

Neste método não precisamos incluir código nenhum, precisamos apenas criar uma View para ele. Sendo assim, clique com o botão direito sobre ele e escolha a opção Add View.

Essa View se chamará Create, ela também será uma bly-typed view da classe Shippers, e também utilizará a Master Page. Veja na Figura 22.

Figura 22. Criando View Create do ShippersController.

Veja o código HTML da View Create na Listagem 10 (a listagem exibe apenas o código de dentro do Content, que é o que interessa). Aqui temos um típico formulário do ASP.NET MVC. Note que estamos utilizando um método chamado BeginForm(), dentro de uma estrutura using.

Aí dentro, utilizando os recursos do ASP.NET MVC estamos criando os controles do formulário através do método TextBox, e os respectivos controles de Validação através do método ValidationMessage.

Uma alteração que pode ser feita é a retirada do ShipperID. Como ele é um IDENTITY no banco, não há a necessidade de ser informado na inclusão de novos registros, portanto pode ser retirado.

Listagem 10. Código HTML da View Create.
<h2>Create</h2> <%= Html.ValidationSummary("Create was unsuccessful. Please correct the errors and try again.") %> <% using (Html.BeginForm()) {%> <fieldset> <legend>Fields</legend> <p> <label for="ShipperID">ShipperID:</label> <%= Html.TextBox("ShipperID") %> <%= Html.ValidationMessage("ShipperID", "*") %> </p> <p> <label for="CompanyName">CompanyName:</label> <%= Html.TextBox("CompanyName") %> <%= Html.ValidationMessage("CompanyName", "*") %> </p> <p> <label for="Phone">Phone:</label> <%= Html.TextBox("Phone") %> <%= Html.ValidationMessage("Phone", "*") %> </p> <p> <input type="submit" value="Create" /> </p> </fieldset> <% } %> <div> <%=Html.ActionLink("Back to List", "Index") %> </div>

Porém ainda falta algo. Note que nesta View temos um submit. Ao fazermos um submit (ou um POST) na View Create, vamos executar aquele segundo Action Method Create do Controller, que recebe um parâmetro do tipo FormCollection. Esse é o método que deverá gravar no banco, os dados informados na View. Sendo assim, veja na Listagem 11 como este método deve ficar.

Listagem 11. Métodos Create do ShippersController.
[AcceptVerbs(HttpVerbs.Post)] public ActionResult Create(Shipper shipperToCreate) { try { dc.Shippers.InsertOnSubmit(shipperToCreate); dc.SubmitChanges(); return RedirectToAction("Index"); } catch { return View(); } }

Veja que o parâmetro do método foi substituído, assim já recebemos um objeto da classe Shipper, pronto para ser incluso no banco. E é exatamente isso que é feito dentro da estrutura try. O Método InsertOnSubmit e o SubmitChanges se encarregarão de criar o comando INSERT e executá-lo no database.

Com isso temos mais uma rotina pronta na nossa aplicação. Se você compilar e executar novamente, e agora clicar no link Create New, vai ter uma página igual a da Figura 23. Basta informar os dados no novo Shipper e clicar em Create.

Figura 23. Incluindo novo registro na tabela Shippers.

Para finalizar basta codificar os métodos Edit e Details, e criar suas respectivas Views. Quando for criar a View Edit, escolha o Content “Edit”, e quando for criar a View Details, escolha o Content Details. Não tem como errar. O código sugerido para os dois métodos Edit e para o método Details, você encontra na Listagem 12.

Para completar um exemplo contendo todas as operações CRUD, fica faltando o Delete, que pode ser facilmente criado, já que segue uma lógica muito parecida com a do Edit.

Listagem 12. Métodos Details e Edit.
public ActionResult Details(int id) { var shipperToEdit = dc.Shippers.SingleOrDefault(s => s.ShipperID == id); return View(shipperToEdit); } public ActionResult Edit(int id) { var shipperToEdit = dc.Shippers.SingleOrDefault( s => s.ShipperID == id ); return View(shipperToEdit); } [AcceptVerbs(HttpVerbs.Post)] public ActionResult Edit(Shipper shipperToEdit) { try { var shipper = dc.Shippers.SingleOrDefault( s => s.ShipperID == shipperToEdit.ShipperID ); shipper.CompanyName = shipperToEdit.CompanyName; shipper.Phone = shipperToEdit.Phone; dc.SubmitChanges(); return RedirectToAction("Index"); } catch { return View(); } }

Conclusão

Esse é o ASP.NET MVC! Pelo menos uma pequena parte dele. Há muito mais o que ser dito sobre ASP.NET MVC, e com certeza novos artigos surgirão em breve.

Quanto à implementação das rotinas CRUD no ASP.NET MVC, poderíamos ter criado uma camada adicional para evitar o acesso direto do Controller ao LINQ to SQL. Através do conceito de Repositórios, poderíamos ter isolado todo o código de consulta e persistência dos dados.

É uma implementação um pouco mais complexa (e trabalhosa), mas em projetos maiores traria benefícios importantes, como uma maior reutilização de rotinas, e maior facilidade na implementação dos Testes Unitários.

Mas como dito no início deste artigo, o objetivo destes exemplos era o de comparar o ASP.NET MVC com o ASP.NET WebForms. E quando colocamos essas duas plataformas lado a lado, ficam claras as diferenças.

E se agora a Microsoft propõe duas arquiteturas diferentes para se criar aplicações ASP.NET, qual das duas utilizar?

De um lado temos anos de experiência e evolução, com uma vasta quantidade de ferramentas que aumentam consideravelmente a produtividade, tornando o desenvolvimento fácil e rápido nos WebForms.

Já do outro lado temos um framework que visa uma divisão mais organizada, tornando mais fácil o gerenciamento de aplicações grandes e complexas, permitindo melhor suporte ao desenvolvimento orientado a testes e dando ao desenvolvedor o total controle do comportamento da aplicação.

Acredito que a resposta mais adequada para a pergunta lá de cima seja: as duas! Vai depender muito da aplicação que será desenvolvida, dos recursos envolvidos, do prazo, e porque não, do preço. Sabendo das diferenças, dos benefícios e empecilhos de cada uma das arquiteturas, a resposta ficará clara para cada situação.

Grande Abraço e até o próximo!

Confira também

Cursos de .NET

Cursos

Preparando o ambiente para programar em .NET

Curso

Guias de Estudo .NET

Guia

Artigos relacionados