Introduo ao ASP.

NET MVC 4 C# + Entity Framework + Razor Engine

Viso Geral ASP.NET MVC ............................................................................................................. 4

Definio ............................................................................................................................................. 4 Models ................................................................................................................................................ 4 Views .................................................................................................................................................. 5 Controllers ........................................................................................................................................... 5 Benefcios ............................................................................................................................................ 5 Decidindo quando criar uma aplicao MVC ............................................................................................ 6 O modelo MVC oferece as seguintes vantagens: ...................................................................................... 6

Introduo ao Razor View Engine ............................................................................................... 7

Benefcios do Razor View Engine: ........................................................................................................ 7 Pontos Negativos do Razor Engine ......................................................................................................... 9

Entity Framework 5.0 ................................................................................................................... 9

Evoluo do Entity Framework .............................................................................................................. 10 Entity Framework Developer Workflows ................................................................................................. 11

Controle de Acesso com SimpleMembershipProvider..................................................................... 12

Estrutura de Dados do SimpleMembershipProvider ................................................................................. 12 O mtodo InitializeDatabaseConnection ................................................................................................. 13 Models, Views e Controllers relacionados ............................................................................................... 14 Regionalizao das Strings e Mensagens do SimpleMembershipProvider ................................................... 15 Cadastrando um Usurio ...................................................................................................................... 17 Cadastrando Grupos de Usurios (Roles) ............................................................................................... 17 Adicionando Usurios aos Grupos.......................................................................................................... 17 Identificando o Usurio Atual ................................................................................................................ 18 Encerrando uma Sesso de Usurio....................................................................................................... 18 Evitando Ataques do Tipo Cross-Site Request Forgery (CSRF) .................................................................. 18 Controlando o Acesso de Usurios e Grupos ........................................................................................... 19 Controle de acesso utilizando Web.config .............................................................................................. 19 Controle de acesso usando Atributos ..................................................................................................... 20 Autenticao Integrada com Redes Sociais ............................................................................................ 21

Conceitos Bsicos....................................................................................................................... 22
Inicializao de Aplicaes MVC ............................................................................................................ 23

Pginas de Erros Customizadas ................................................................................................... 23

Erros gerados pelo HttpRequest ............................................................................................................ 24 Erros gerados pelos Controllers, Actions e Classes .................................................................................. 24

Arquitetura da nossa Aplicao MVC ............................................................................................ 25

O modelo Repository Pattern aplicado ao MVC ....................................................................................... 26 Repositrios, Inversion of Control (IoC) e UnitOfWork na prtica ............................................................. 26 A estrutura do banco de dados de exemplo ......................................................................................... 28 Criando a Interface para nosso Repositrio ......................................................................................... 29 Criando o mecanismo para IoC .......................................................................................................... 30 O Repositrio EFNatRepository ........................................................................................................... 31 Otimizando LINQ Queries .................................................................................................................. 33

Pgina 2

Implementando UnitOfWork .............................................................................................................. 34 Codificando nosso HomeController ..................................................................................................... 34 A View Home.................................................................................................................................... 36 Finalizando a aplicao de exemplo .................................................................................................... 39

Prticas comuns (e recomendadas) para aplicaes MVC .............................................................. 40

Validao com DataAnnotation Classes .................................................................................................. 40 Validando Tipos de Dados especficos ................................................................................................. 40 Validando Campos Requeridos ........................................................................................................... 41 Validao com RegularExpressions ..................................................................................................... 41 O atributo [Display] .......................................................................................................................... 41 Custom ValidationAttributes ............................................................................................................... 41 Mscaras de entrada de dados ........................................................................................................... 42 Exibindo notificaes para o usurio ...................................................................................................... 43 Trabalhando com Controles de Lista ...................................................................................................... 43 Carregando DropDownLists................................................................................................................ 43 DropDownLists em Cascata com JQuery .............................................................................................. 44 Paginao de Registros no MVC ............................................................................................................ 46 Implementando Paginao para o Grid ............................................................................................... 46

Concluso Final .......................................................................................................................... 47 Referncias................................................................................................................................ 48

Pgina 3

Viso Geral ASP.NET MVC

A arquitetura Model-View-Controller (MVC) proporciona a separao da aplicao em trs componentes: Model, View e Controller. O ASP.NET MVC um framework de apresentao altamente testado e integrado aos recursos do ASP.NET, como master-pages e membership-based authentication (da mesma forma como as aplicaes desenvolvidas com ASP.NET Web Forms). O framework MVC definido pelo Namespace System.Web.Mvc, parte fundamental do Namespace System.Web.

Definio
MVC um modelo de design padro, utilizado por muitos desenvolvedores. Algumas aplicaes Web exploraro os novos recursos do MVC framework. Outras continuaro utilizando o modelo tradicional baseado em Web Forms e postbacks. Outras aplicaes combinaro as duas abordagens. Nenhuma das abordagens exclui a outra. O MVC framework inclui os seguintes componentes:

Figura 1: Componentes do ASP.NET MVC

Models
O objeto Model a parte da aplicao que implementa a lgica para a camada de dados da aplicao. Frequentemente, o objeto Model responsvel por recuperar e persistir o estado do modelo no banco de dados. Por exemplo, um objeto Produto pode recuperar informaes do banco de dados, operar com estas informaes, e ento persistir a informao atualizada na tabela de Produtos no SQL Server. Em aplicaes pequenas, o objeto Model frequentemente separado conceitualmente e no fisicamente. Por exemplo, se a aplicao faz apenas a leitura de um conjunto de dados e os exibe utilizando um objeto View, a aplicao no ter necessariamente uma camada de dados fsica. Neste caso, o objeto Model representaria esta camada.

Pgina 4

Views
Views so componentes que exibem a interface de usurio (UI). Tipicamente, esta UI criada a partir do modelo de dados. Um exemplo seria um objeto View para editar a tabela de Produtos. Este objeto View exibe controles como caixas de texto (TextBox), caixas de listagem (DropDownList), e caixas de verificao (CheckBox) com dados que representam o estado atual do objeto Produto.

Controllers
Os objetos Controllers so componentes que gerenciam a interao do usurio, operam o objeto Model, e por ltimo selecionam um objeto View para exibir os dados na camada do usurio (UI). Numa aplicao MVC, o objeto View apenas exibe informaes, o objeto Controller gerencia e responde s entradas e interaes do usurio. Por exemplo, o Controller gerencia os valores passados atravs de query-string, e passa esses valores para o objeto Model, que por sua vez consulta o banco de dados utilizando os valores recebidos.

Benefcios
A arquitetura MVC facilita a separao das diferentes camadas da aplicao (lgica de entrada de dados, lgica de negcios e lgica de apresentao), alm de prover o conceito loose coupling entre esses componentes. Isto significa que cada componente tem ou usa, pouco ou nenhum conhecimento, sobre a implementao do outro. Esta arquitetura determina onde cada camada dever ser implementada na aplicao. A camada de apresentao (UI) pertence aos objetos View. A lgica para gerenciar a entrada de dados e interaes com o usurio pertence aos objetos Controller. As regras de negcio pertencem aos objetos Model. Esta separao auxilia a gerenenciar a complexidade durante a construo da aplicao, porque ela permite que voc se concentre na implementao de uma camada de cada vez. Por exemplo, voc pode focar na construo de um objeto View sem depender ou conhecer a implementao da lgica de negcios implementada no objeto Model. Alm de auxiliar no gerenciamento da complexidade durante o desenvolvimento da aplicao, o modelo MVC facilita o trabalho de testar sua implementao, tornando-o mais fcil se comparado ao modelo Web Forms. Por exemplo, numa aplicao ASP.NET baseada em Web Forms, uma nica classe utilizada para exibir os dados e gerenciar as interaes com o usurio. Escrever testes automatizados para uma aplicao ASP.NET baseada em Web Forms pode ser complexo, porque para testar uma pgina individualmente, voc precisa instanciar a classe da pgina testada, todos os controles e classes dependentes. Como muitas classes podem ser instanciadas para executar uma nica pgina, pode tornar-se difcil a tarefa de testar partes especficas da aplicao. Por isso testar uma aplicao ASP.NET baseada em Web Forms uma tarefa mais difcil do que testar uma aplicao baseada no modelo MVC. Alm disso, para testar uma aplicao ASP.NET baseada em Web Forms necessrio um Web Server. O framework MVC desconecta os componentes e faz uso de Interfaces, o que torna possvel testar componentes individualmente, isolados do resto do framework. A separao entre os principais componentes de uma aplicao MVC tambm promove o desenvolvimento paralelo (parallel development), onde um desenvolvedor pode trabalhar no objeto View, um segundo desenvolvedor pode trabalhar no objeto Controller enquanto um terceiro desenvolvedor se concentra nas regras de negcio implementadas no objeto Model.

Pgina 5

Decidindo quando criar uma aplicao MVC

Voc precisa considerar cuidadosamente quando construir uma aplicao utilizando ASP.NET MVC framework ou o modelo ASP.NET baseado em Web Forms. O framework MVC no substitui o modelo Web Forms; voc pode utilizar qualquer das duas abordagens para desenvolver uma aplicao Web. Antes de decidir pela arquitetura MVC ou Web Forms para um projeto especfico, analise as vantagens e desvantagens de cada abordagem: O modelo baseado em Web Forms oferece as seguintes vantagens: Suporta o modelo de eventos que preserva o estado da pgina atravs do protocolo HTTP, o que beneficia o desenvolvimento de aplicaes LOB (Line-of-Business). O modelo baseado em Web Forms oferece dzias de eventos que so suportados em centenas de server-controls. Utiliza View State e server-based Forms, que facilitam o gerenciamento de estado entre os postbacks. Funciona bem para pequenos times de desenvolvedores e designers que podem explorar um grande nmero de componentes disponveis para o modelo de desenvolvimento RAD (Rapid Application Development). Em geral, apresenta uma complexidade menor, em razo dos componentes (Page Class, controles, modelo de eventos, etc.) bem integrados que exigem menos cdigo quando comparados ao modelo MVC.

O modelo MVC oferece as seguintes vantagens:

Separao das camadas da aplicao, testabilidade e desenvolvimento orientado a testes (TDD) so recursos nativos para o modelo MVC. Todos os contratos no MVC framework so baseados em Interfaces e podem ser testados com uso de objetos mock, que so simulaes de objetos que imitam o comportamento de objetos reais da aplicao. Voc pode utilizar testes unitrios para validar a aplicao sem a necessidade de executar os objetos Controllers dentro de um processo ASP.NET, o que torna o processo de testes unitrios mais rpido e flexvel. Voc pode utilizar qualquer framework de teste unitrio compatvel com .NET Framework. Um framework extensvel e plugvel. Os componentes do MVC framework foram desenhados de forma que possam ser facilmente substitudos ou customizados. Voc pode conectar seu prprio processador de Views, poltica de roteamento de URLs, serializao de parmetros para mtodos, e outros componentes. O framework ASP.NET MVC tambm suporta os modelos de containers para Injeo de Dependncia (Dependency Injection DI) e Inverso de Controle (Inversion of Control IOC). DI permite que voc injete objetos dentro de uma classe, ao invs de utilizar a classe para criar o objeto. IOC especifica que se um objeto requer outro objeto, o primeiro objeto deve obter o segundo objeto de uma fonte externa como um arquivo de configurao. Isto torna o processo de testar a aplicao muito mais simples.

Pgina 6

Um poderoso componente de mapeamento de URL que permite que voc construa aplicaes que tenham URLs compreensveis e pesquisveis. URLs no precisam incluir nomes de arquivos e extenses, e so criadas para suportar modelos de nomenclatura de URLs que funcionam bem com os mecanismos de search engine optimization (SEO) e tambm com endereamento representational state transfer (REST). Suporte para utilizao de linguagem de marcao nas pginas ASP.NET (arquivos *.aspx), nos controles de usurio (arquivos *.ascx), nas master-pages (arquivos *.master) para criar modelos (templates) para objetos View. Voc pode utilizar recursos existentes do ASP.NET combinados com o MVC framework, como master-pages aninhadas, expresses in-line (<%= %>), controles server-based, data-binding, localizao, e outros. Suporte para recursos de segurana. A arquitetura ASP.NET MVC permite a utilizao dos modelos Forms Authentication, Windows Authentication, URL Authorization, Membership, Roles, Profiles, Caching, entre outros.

Introduo ao Razor View Engine

O framework ASP.NET MVC sempre suportou o conceito de View Engines, que so mdulos plugveis que implementam diferentes modelos de sintaxe. O View Engine padro para o ASP.NET MVC atualmente o ASPX baseado no mesmo modelo utilizado pelos Web Forms. Outros View Engines populares para o ASP.NET MVC so Spark e NHaml. O novo View Engine Razor foi otimizado em torno da gerao de cdigo HTML utilizando uma abordagem code-focused.

Benefcios do Razor View Engine:

Compacto, Expressivo e Fluido: O View Engine Razor minimiza o nmero de caracteres e keystrokes requeridos num arquivo, permitindo um fluxo de codificao rpido e conciso. Diferente da maioria dos padres de sintaxe, voc no precisa interromper sua codificao e declarar explicitamente blocos de processamento no servidor dentro do seu cdigo HTML. O interpretador do Razor inteligente o suficiente para inserir isso a partir do seu cdigo. Isto permite uma sintaxe realmente compacta, expressiva, limpa, rpida e fcil de digitar. Fcil de Aprender: A sintaxe do Razor fcil de aprender e permite que voc atinja um bom nvel de produtividade com um mnimo de conceitos. Voc pode utilizar toda sua experincia com sua linguagem .NET e com HTML. No uma Linguagem: O Razor View Engine no uma nova linguagem. Os desenvolvedores continuaro utilizando suas habilidades com C#/VB.NET em conjunto com a sintaxe Razor. Trabalha com qualquer Editor de Texto: No requer uma ferramenta especfica e permite que voc utilize qualquer editor de texto para escrever seu cdigo. O prprio Bloco de Notas pode ser utilizado. Suporte para Intellisense: Embora o Razor no exija uma ferramenta especfica para codificao, o Visual Studio 2010 e 2012 oferece suporte completo para utilizar o Intellisense com o Razor View Engine. Teste Unitrio: O Razor View Engine oferece suporte para testes unitrios com objetos View, sem requerer um objeto Controller ou um Servidor Web. Os testes podem ser armazenados em qualquer projeto de teste, nenhum domnio (app-domain) especial requerido.

Pgina 7

Observe a seguir alguns exemplos das diferenas entre as sintaxes ASPX e Razor. ASPX:

Razor:

ASPX:

Razor:

Pgina 8

Pontos Negativos do Razor Engine

Pessoalmente, sou um defensor do Razor Engine, sua sintaxe concisa facilita a codificao, alm de tornar o cdigo mais limpo e de fcil leitura. Outros desenvolvedores podem ter preferncias diferentes, uma questo de sabor. Mas, no posso deixar de citar um ponto negativo do Razor. O Visual Studio no suporta o Design Mode para visualizao das Views. Um dos motivos est relacionado aos arquivos das Views criadas com o Razor, que possuem extenso *.cshtml, o Visual Studio no permite a exibio em Design Mode para estes arquivos. O desenvolvedor tem duas opes para contornar este problema, a primeira alterar as extenses dos arquivos para *.aspx, e a segunda opo no utilizar o Razor Engine. Oferecer suporte para Design Mode para o Razor Engine no est entre as prioridades da Microsoft. Se voc est habituado a utilizar muito o Design Mode, minha sugesto que utilize o engine padro do ASP.NET (*.aspx), a diferena de sintaxe pode ser compensada pelo uso do Design Mode e o uso do engine padro no afetar sua aplicao, a preferncia pelo Razor Engine est relacionada produtividade que ele proporciona durante o processo de codificao.

Entity Framework 5.0

Entity Framework a ferramenta de Mapeamento Objeto-Relacional (ORM) criada pela Microsoft e agora liberada dentro do modelo de licena Open Source Apache 2.0 conforme divulgado no portal CodePlex (http://entityframework.codeplex.com). Entity Framework permite aos desenvolvedores, que trabalham com dados relacionais, utilizarem objetos (domain-specific objects), eliminando a necessidade do cdigo de acesso a dados que normalmente temos que escrever. Com ADO.NET Providers, o Entity Framework oferece suporte para SQL Server, Oracle, MySQL, PostgreSQL, Sybase, Informix, Firebird, DB2, Cach, e outros bancos de dados disponveis no mercado.

Figura 2: Arquitetura do Entity Framework

Pgina 9

Evoluo do Entity Framework

O EF 5.0, disponvel atravs do NuGet compatvel com o Visual Studio 2010 e Visual Studio 2012 e pode ser utilizado em aplicaes baseadas no .NET Framework 4.0 e 4.5.

Figura 3: Evoluo do Entity Framework

Pgina 10

Entity Framework Developer Workflows

O Entity Framework oferece trs abordagens para desenvolvimento, com objetivo de atender diferentes cenrios e skills da equipe de desenvolvimento. As abordagens so: Database First, Model First e Code First. Veja abaixo qual a abordagem mais adequada para seu projeto. Cenrios Novo Banco de Dados Preferncia por Cdigo Code First Definio das Classes e Mapeamento no Cdigo Cria/Atualiza o Banco de Dados em Runtime Code First Cria Modelo EDMX utilizando o designer; Cria/Atualiza o Banco de Dados a partir do EDMX; Classes geradas automaticamente a partir do EDMX; Preferncia por Designer Model First Cria Modelo EDMX utilizando o designer Cria/Atualiza o Banco de Dados a partir do EDMX Classes geradas automaticamente a partir do EDMX Database First Cria Modelo EDMX utilizando Engenharia Reversa Classes geradas automaticamente a partir do EDMX

Banco de Dados Existente

Cenrios Novo Banco de Dados

Banco de Dados Existente

Figura 4: Developer Workflows para Entity Framework

Pgina 11

Controle de Acesso com SimpleMembershipProvider

O modelo adotado como padro para segurana e controle de acesso das aplicaes ASP.NET MVC o SimpleMembershipProvider. Este modelo uma verso mais enxuta e otimizada do modelo MembershipProvider j conhecido pelos desenvolvedores ASP.NET WebForms. Sua implementao simples.

Estrutura de Dados do SimpleMembershipProvider

Abaixo est o diagrama contendo a estrutura de dados utilizada do SimpleMembershipProvider. Diferente de seu irmo mais velho, nesta verso, as views e stored procedures foram removidas e a estrutura das tabelas foi simplificada. Num primeiro momento, o desenvolvedor poder sentir falta da ferramenta aspnet_regsql.exe que utilizvamos para criar todos os objetos de dados necessrios para o MembershipProvider. Bastava executar este utilitrio, apontar para o banco de dados desejado e ele se encarregava de criar as tabelas, views e stored procedures. Nesta verso mais simplificada e otimizada esta tarefa tambm ficou mais simples, o mtodo InitializeDatabaseConnection se encarrega desta tarefa. A estrutura de dados criada utilizando o novo recurso do SQL Server, o LocalDb.

Figura 5: Diagrama de Dados SimpleMembershipProvider

Pgina 12

A Figura 6 mostra a string de conexo padro criada para o SimpleMembershipProvider.

Figura 6: Connection String (default) para SimpleMembershipProvider

O mtodo InitializeDatabaseConnection
O objeto WebSecurity implementa o mtodo InitializeDataBaseConnection. Este mtodo requer cinco argumentos, descritos na Tabela 1. ConnectionString vlida que indica o servidor e banco de dados onde sero armazenadas as informaes de usurios e grupos. UserProfile String com nome da tabela que contm o perfil de usurios. UserID String com nome da coluna que contm o ID do usurio na tabela de perfil de usurios. UserName String com nome da coluna que contm o Username na tabela de perfil de usurios. autoCreateTables Boolean que determina se o mecanismo do SimpleMembershiProvider dever criar automaticamente as tabelas, caso elas no sejam encontradas no banco de dados especificado na string de conexo. Tabela 1: Agumentos do mtodo InitializeDatabaseConnection DefaultConnection

Este mtodo invocado no construtor da classe SimpleMembershipInitializer que parte da implementao do atributo InitializeSimpleMembershipAttribute. Consulte o arquivo de mesmo nome localizado na pasta Filter da sua soluo. Sempre que sua aplicao consumir um mtodo ou propriedade do objeto WebSecurity, certifique-se de que o atributo InitializeSimpleMembership foi devidamente invocado. Explicando melhor, se voc tem uma classe onde vrios mtodos interagem com o SimpleMembershipProvider, defina este atributo na declarao da classe. Este atributo no pode ser invocado mais de uma vez para a mesma classe, isto provocar uma exceo. Ao criar um novo projeto baseado no template ASP.NET MVC Application, o desenvolvedor no precisa preocupar-se com as referncias, assemblies e namespaces necessrios para implementar o mecanismo de autenticao e controle de acesso de usurios, o Visual Studio se encarrega desta tarefa. Observe a Figura 7. Ela apresenta o atributo InitializeSimpleMembership na declarao da classe AccountController onde a maioria dos mtodos interagem com o SimpleMembershiProvider.

Pgina 13

Figura 7: O Atributo InitializeSimpleMembership

Models, Views e Controllers relacionados

Falando ainda sobre o modelo de autenticao e controle de acesso dos usurios, a soluo baseada no SimpleMembershipProvider, diferente do modelo utilizado por WebForms, em lugar dos user-controls (*.ascx) para os implementar os controles constituintes como o formulrio de Login, Cadastro de Usurios e Recuperao de senhas, no modelo utilizado no ASP.NET MVC, temos um Controller, chamado AccountController, uma classe Model chamada AccountModels, e as Views Login, Manage, ChangePassword, Register entre outras. Ao mesmo tempo que estas Views oferecem uma implementao rpida e prtica do modelo de autenticao e controle de acesso baseado em perfis de usurios, importante lembrar que ser necessrio um pouco de trabalho para a regionalizao das strings contidas nos labels e mensagens deste modelo.

Pgina 14

A Figura 8 apresenta a janela Solution Explorer exibindo os arquivos gerados automaticamente para contemplar as funcionalidades do SimpleMembershipProvider.

Figura 8: Arquivos do SimpleMembershiProvider

Regionalizao das Strings e Mensagens do SimpleMembershipProvider

Alterar as strings apresentadas nos labels e mensagens do mecanismo de autenticao do SimpleMembershipProvider uma tarefa simples. A maior parte destas strings esto localizadas nos atributos da classe AccountModels.cs. Este atributos baseiam-se no modelo Data Annotation Classes implementado pelo Namespace System.ComponentModel.DataAnnotation. Atributos desta categoria sero abordados em outro tpico deste mesmo tutorial. Para mais informaes

Pgina 15

sobre o uso dos Data Annotation Classes Attributes, consulte http://msdn.microsoft.com/enus/library/dd901590%28v=vs.95%29.aspx. A Figura 9 ilustra alguns destes atributos.

Figura 9: Data Annotation Classes Attributes A maioria das strings utilizadas pelas Views do SimpleMembershipProvider baseiam-se no argumento Name do atributo [Display] para alimentar os labels dos controles apresentados em suas pginas e nas mensagens de erros dos atributos de validao. Por exemplo, o atributo Display, possui dois argumentos Name e Description. O primeiro, o texto que ser exibido ao lado do controle como se fosse um label do controle. A leitura deste atributo feita atravs dos mtodos LabelFor ou DisplayFor do objeto Html, usado largamente para a construo das Views. A sintaxe simples, veja o exemplo a seguir:
(na propriedade Address da classe Customer.cs) [Display(Name=Endereo, Description=Endereo/Logradouro do Cliente)] (Na View, CustomerView.cshtml) Html.DisplayFor(model => item.Address)

No exemplo acima, o label para o campo Address da CustomerView exibir o texto Endereo indicado pelo argumento Name do Atributo Display. Ao posicionar o cursor sobre este campo, um ToolTipText ser exibido contendo o texto do argumento Description do mesmo atributo.

Pgina 16

Retomando o ponto inicial deste tpico, para regionalizar as strings utilizadas nos labels e mensagens do mecanismo de autenticao do SimpleMembershipProvider, o desenvolvedor deve substituir estas strings por textos do idioma desejado. A Globalizao de strings para suporte a mltiplos idiomas no objeto de estudo deste tutorial. Para maiores informaes sobre a globalizao de aplicaes ASP.NET MVC consulte este exemplo http://afana.me/post/aspnet-mvc-internationalization.aspx.

Cadastrando um Usurio
A View Register.cshtml encontrada na pasta Views/Account oferece uma alternativa para cadastro de novos usurios. Contudo, o desenvolvedor poder criar outras views ou formulrios para esta finalidade. O Namespace WebMatrix.WebData implementa o objeto WebSecurity que expe o mtodo CreateUserAndAccount(string userName, string Password). Este mtodo cria um novo registro nas tabelas UserProfile e webpages_Membership. As senhas so criptografadas e persistidas na tabela webpages_Membership. A ao Register da classe AccountController apresenta um exemplo de utilizao do mtodo CreateUserAndAccount, abaixo um fragmento de cdigo extrado desta classe.
... WebSecurity.CreateUserAndAccount(model.UserName, model.Password); ...

Cadastrando Grupos de Usurios (Roles)

O template ASP.NET MVC Application no oferece uma View ou formulrio para gerenciar o cadastro de grupos de usurios (Roles). Mas o desenvolvedor pode utilizar a classe Roles (System.Web.Security) para esta tarefa. Esta classe expe os mtodos CreateRole e DeleteRole, ambos requerem um nico parmetro do tipo string contendo o nome da Role que deseja incluir ou excluir. Por tratar-se de uma classe esttica, no h necessidade de instanci-la, basta declarar o Namespace System.Web.Security para invocar os mtodos desejados. Veja o exemplo abaixo:
... using System.Web.Security; ... Roles.CreateRole(Gerentes); ... if (Roles.RoleExists(Gerentes) { Roles.DeleteRole(Gerentes); } ...

Adicionando Usurios aos Grupos

Para adicionar ou remover usurios aos grupos (Roles) o desenvolvedor deve utilizar o mesmo objeto Roles (System.Web.Security). Este objeto oferece oito mtodos (4 mtodos de incluso e 4 mtodos de excluso) que permitem o gerenciamento de usurios e grupos (Roles). A Tabela 2 descreve os mtodos e seus argumentos.

Pgina 17

Mtodo AddUsersToRole

Argumentos string[] Users, string roleName

AddUsersToRoles

string[] Users, string[] Roles

AddUserToRole

string userName, string roleName

AddUserToRoles

string userName, string[] Roles

Descrio Adiciona todos usurios informados no parmetro Users ao grupo informado no argumento roleName. Adiciona todos os usurios informados no parmetro Users todos os grupos informados no parmetro Roles. Adiciona o usurio informado no parmetro userName ao grupo informado no parmetro roleName Adiciona o usurio informado no parmetro userName todos os grupos informados no parmetro Roles.

Tabela 2: Gerenciando Usurios e Grupos

Identificando o Usurio Atual

O objeto WebSecurity expe duas propriedades CurrentUserId (int) e CurrentUserName (string) que so alimentadas com o cdigo e o nome de usurio atual, ou seja, o usurio que est autenticado na sesso corrente.

Encerrando uma Sesso de Usurio

O formulrio contido na View _LoginPartial localizada na pasta Views/Shared/ oferece uma alternativa para encerrar a sesso do usurio corrente. Este formulrio invoca a ao (action) LogOff da classe AccountController que se encarrega de finalizar a sesso do usurio. O desenvolvedor pode criar outros formulrios ou views que ofeream um atalho para finalizar a sesso atual. Para isto, necessrio invocar o mtodo Logout() do objeto WebSecurity (WebMatrix.WebData). Este mtodo no requer nenhum parmetro e pode ser chamado de qualquer parte da sua aplicao. Ao ser invocado, a sesso do usurio finalizada e a aplicao direcionada para a pgina de Login ou para a URL redirecionada pela aplicao.

Evitando Ataques do Tipo Cross-Site Request Forgery (CSRF)

Um recurso de segurana das aplicaes ASP.NET MVC para evitar os ataques do tipo Cross-Site Request Forgery o Token AntiForgeryToken. O desenvolvedor pode utilizar este recurso para proteger sua aplicao. Sua sintaxe simples. Veja o exemplo abaixo: Na View, o objeto Html utilizado para gerar o Token utilizando um hidden field para armazenlo no formulrio. Este token enviado para o servidor sempre que o formulrio submetido.
... @Html.AntiForgeryToken() ...

Pgina 18

Uma vez no servidor, o atributo [ValidateAntiForgeryToken] garante que a ao ou mtodo ser executada apenas e somente aps a validao do token recebido. Observe o exemplo a seguir.
... [HttpPost] [ValidateAntiforgeryToken] public ActionResult Disassociate(string provider, string providerUserId) ...

Figura 11: O Atributo ValidateAntiForgeryToken

Controlando o Acesso de Usurios e Grupos

Nas aplicaes ASP.NET WebForms o desenvolvedor est habituado a utilizar os elementos <authentication> , <authorization> e <location> no arquivo de configurao Web.config para definir as permisses de acesso para os usurios da sua aplicao. As aplicaes ASP.NET MVC oferecem os atributos [Authorize] e [AllowAnonymous] para que o desenvolvedor possa gerenciar as permisses de acesso aos controllers e actions da sua aplicao.

Controle de acesso utilizando Web.config

Tenho observado alguns sites que orientam equivocadamente os desenvolvedores a utilizarem o elemento <location> para definir as permisses de acesso para as rotas da sua aplicao MVC. Esta prtica no recomendada uma vez que sua concepo no contempla o modelo de rotas, controllers e aes, e os resultados sero prejudiciais sua aplicao. Contudo, a definio de permisses de acesso no arquivo de configurao uma prtica comum em aplicaes web. Uma alternativa, neste caso, criar novas sesses de configurao em seu arquivo Web.config para esta finalidade. Um bom exemplo desta implementao pode ser encontrado neste endereo: http://www.ryanmwright.com/2010/04/25/dynamiccontrolleraction-authorization-in-asp-net-mvc/.

Pgina 19

Controle de acesso usando Atributos

A prtica recomendada baseia-se nos atributos [Authorize] e [AllowAnonymous], ambos integrantes do namespace System.Web.Mvc. O atributo [Authorize] pode ser definido no escopo de uma classe ou de um mtodo especfico. Quando definido na declarao de uma classe, o atributo [Authorize] exigir um usurio autenticado para acessar qualquer recurso contido nesta classe. O desenvolvedor deve combinar a utilizao dos atributos [Authorize] e [AllowAnonymous] para atingir o objetivo desejado. Tome como exemplo a classe AccountController. A maioria dos mtodos/aes desta classe requerem um usurio autenticado, contudo, os mtodos Login e Register devem permitir o acesso de usurios annimos. A combinao dos atributos [Authorize] e [Anonymous] contemplam este objetivo. A Figura 12 ilustra o exemplo da classe AccountController.cs com os atributos [Authorize] e [AllowAnonymous].

Figura 12: Os atributos [Authorize] e [AllowAnonymous] At agora estamos falando apenas de restringir ou permitir o acesso para usurios autenticados, no nos preocupamos com o perfil deste usurio, por exemplo, a que grupo ou grupos pertence, ou quem este usurio especificamente. Para atingir este objetivo, utilizaremos as variaes do atributo [Authorize].

Pgina 20

Este atributo possui argumentos nomeados que nos permitem informar o nome do usurio ou usurios, bem como o nome do grupo (role) ou grupos (roles) que esto autorizados a acessar o controller ou action associado ao atributo. A Figura 13 ilustra algumas das possveis variaes do atributo [Authorize].

Figura 13: Variaes do Atributo [Authorize]

Autenticao Integrada com Redes Sociais

Um cenrio muito comum nas aplicaes Web atualmente, permitir que o usurio ou visitante do seu website possa autenticar-se utilizando as credenciais de uma rede social, onde ele j est cadastrado, evitando que ele tenha que memorizar novas senhas e proporcionando uma melhor experincia para o usurio da aplicao. Integrar suas aplicaes web com as APIs das redes sociais mais conhecidas, como Facebook, Twitter, Microsoft Live e Google+, apesar dos esforos destas empresas, nem sempre uma tarefa simples. Em algumas situaes, o desenvolvedor no est familiarizado com estes mecanismos e exigir um tempo maior para analisar e entender como consumir estas APIs. Para facilitar esta tarefa, a Microsoft integrou ao .NET Framework 4.0 esses mecanismos de autenticao atravs do Namespace Microsoft.Web.WebPages.OAuth. Este recurso est disponvel no apenas para aplicaes ASP.NET MVC, mas tambm para todos os tipos de aplicaes baseadas no .NET Framework 4 (ou superior) que precisam de autenticao integrada com estas redes sociais. Como padro, os templates de projetos ASP.NET MVC oferecem esta integrao praticamente pronta. Por exemplo, se o desenvolvedor deseja oferecer aos usurios da sua aplicao uma alternativa para autenticar-se atravs do Facebook, basta acessar a rea destinada aos
Pgina 21

desenvolvedores, https://developers.facebook.com/apps, cadastrar sua aplicao, obter as chaves appId e appSecret e editar o arquivo AuthConfig.cs localizado na pasta AppStart. As linhas 25-27 apresentam o mtodo RegisterFacebookClient que solicita estas duas chaves para integrar sua aplicao. Originalmente, estas linhas esto comentadas no arquivo AuthConfig.cs, necessrio remover os caracteres de comentrios para concluir sua integrao. Simples assim, no necessrio nenhuma linha de cdigo adicional, basta informar os atributos solicitados pelo mtodo RegisterFacebookClient (ou o mtodo correspondente rede social desejada) e sua aplicao j estar pronta para permitir que seus usurios utilizem suas credenciais para acessar as reas restritas. A Figura 14 apresenta o arquivo AuthConfig.cs.

Figura 14: Autenticao Integrada com Redes Sociais

Conceitos Bsicos
At este ponto, voc teve uma introduo ao modelo de desenvolvimento de uma aplicao ASP.NET MVC, entendeu o que so Models, Views e Controllers. Teve uma viso geral sobre o Razor Engine e o Entity Framework. Aprendeu como utilizar o SimpleMembershipProvider para autenticar e controlar o acesso dos usurios da sua aplicao, inclusive como integrar sua aplicao com as redes sociais mais conhecidas do mercado. Antes de prosseguirmos com aspectos mais avanados da implementao de uma aplicao MVC gostaria de abordar mais dois pontos bsicos, porm no menos importantes, a inicializao das aplicaes e as pginas de erros personalizadas.

Pgina 22

Inicializao de Aplicaes MVC

Existem algumas formas de inicializarmos as aplicaes MVC. A mais simples e prtica utilizarmos o mtodo RegisterRoute da classe RouteConfig encontrada na pasta App_Start. Este mtodo utiliza a coleo RouteCollection para definir o padro de rotas da aplicao. O mtodo MapRoute expe o argumento nomeado defaults utilizado para informar qual ser a ao (action) e o controller que sero invocados na inicializao da sua aplicao. A Figura 15 ilustra o mtodo MapRoute.

Figura 15: Mtodo MapRoute (RouteCollection) No exemplo ilustrado na Figura 15, se o desenvolvedor desejasse que a aplicao exibisse o formulrio de Login, implementado atravs da View Login.cshtml e gerenciado pela classe AccountController e o mtodo (action) Login, os parmetros sublinhados em amarelo deveriam ser substitudos como demonstrado a seguir:
... defaults: new { controller = Account, action = Login, id = UrlParameter.Optional } ...

Pginas de Erros Customizadas

As aplicaes web, em sua maioria, so utilizadas por um grande nmero de usurios. Cada usurio com ter uma experincia diferente com sua aplicao. Um erro ou exceo gerado durante o processamento de um pedido do usurio no algo que desejamos, mas estamos sempre sujeitos aos diversos fatores internos e externos que podem afetar o funcionamento da nossa aplicao. Exibir pginas de erro personalizadas e com mensagens amigveis para os usurios da sua aplicao uma prtica positiva que minimiza o impacto o erro gerado, proporcionando um melhor experincia para o usurio. Veja a seguir como adotar medidas simples que podem ajudar seu usurio e at voc mesmo a identificar a causa do erro.

Pgina 23

Erros gerados pelo HttpRequest

Os erros mais comuns so aqueles gerados pelo HttpRequest. Para cada erro gerado existe um statusCode correspente. Por exemplo, o erro 404 indica que a pgina ou recurso solicitado no foi localizada no servidor, o erro 403 indicar que o usurio no tem permisso para acessar o recurso que est tentando acessar, o erro 400 indica que um pedido (request) invlido foi enviado para o servidor. Para uma lista completa de erros gerados pelo HttpRequest acesse este endereo http://en.wikipedia.org/wiki/List_of_HTTP_status_codes. Para estes tipos de erros, o desenvolvedor continuar utilizando o elemento customErrors no arquivo de configurao da aplicao para definir o comportamento da aplicao para cada statusCode retornado pelo servidor. A seo customErrors possui o atributo defaultRedirect que deve ser utilizado para indicar a pgina para a qual se deseja redirecionar o browser quando um erro no listado nas propriedades statusCode da mesma seo ocorrer. A Figura 16 apresenta o elemento customErrors no arquivo Web.config.

Figura 16: O elemento customErrors

Erros gerados pelos Controllers, Actions e Classes

Alm dos erros gerados pelo HttpRequest, temos que nos preocupar com os erros de processamento gerados pela nossa aplicao. Por exemplo, erros gerados durante a execuo de um procedimento ou mtodo de um dos controllers ou classes da nossa aplicao. Quando isto ocorre, o HttpRequest retornar para o browser o nosso velho conhecido erro 500 Internal Server Error, que apresenta pouca ou nenhuma informao que possa ajudar o usurio e at mesmo voc a identificar a causa do problema. Para estes casos, o template de projeto ASP.NET MVC Application cria uma View especfica, originalmente denominada Error.cshtml, encontrada na pasta Views/Shared/. O elemento principal desta View a classe System.Web.Mvc.HandleErrorInfo declarada no topo do arquivo. Esta classe expe propriedades fundamentais para auxiliar o desenvolvedor a identificar a origem do erro ou exceo gerado. O desenvolvedor deve personalizar esta View para torn-la adequada ao layout da aplicao, assim como para exibir mensagens mais amigveis para seus usurios. As informaes expostas pelas propriedades da classe HandleErrorInfo podem ser exibidas nesta pgina de erro e/ou persistidas no log de erros da aplicao para anlise futura. A Figura 17 apresenta a View Error.cshtml modificada para exibir as informaes obtidas nas propriedades da classe HandleErrorInfo utilizando uma tabela HTML.

Pgina 24

Figura 17: A View Error.cshtml

Arquitetura da nossa Aplicao MVC

Agora que voc j tem uma boa compreenso dos conceitos e ferramentas bsicas de uma aplicao MVC, vamos nos concentrar nos aspectos mais avanados da arquitetura desta aplicao. Existem diversos modelos de arquitetura para implementarmos uma aplicao MVC. Basta uma rpida pesquisa na Internet para que o desenvolvedor encontre um grande nmero de diferentes sabores de arquitetura para aplicaes ASP.NET MVC. Este grande nmero de opes, frequentemente gera dvidas para os desenvolvedores que esto buscando uma referncia para escolher a arquitetura correta para seu projeto. A escolha correta aquela que se encaixa ao cenrio do seu projeto. Todos os modelos de arquitetura oferecem seus prs e contras. O desenvolvedor deve analisar seu projeto e optar pelo modelo que mais se aproxima das necessidades da sua empresa, do cliente, do time de desenvolvimento. Para o nosso tutorial, optei pelo modelo que combina o uso de repositrios, UnitOfWork e IoC, tambm conhecido como Model 2, uma variao do padro MVC. Este modelo oferece uma implementao relativamente simples e com resultados eficientes. Nos pargrafos seguintes explicarei como adotar este modelo para suas aplicaes MVC.

Pgina 25

O modelo Repository Pattern aplicado ao MVC

O uso de repositrios no uma prtica recente. A princpio o desenvolvedor pode ter a impresso de que ter que escrever uma quantidade maior de cdigo, mas os benefcios desta prtica ficaro claros ao longo do ciclo de vida do projeto. O propsito do uso de repositrios remover a dependncia entre a camada de negcios da sua aplicao e a camada de acesso a dados. Isto permitir que o voc possa substituir a camada de acesso a dados sem afetar o funcionamento da sua aplicao. Por exemplo, o desenvolvedor pode criar falsos repositrios (mocks), utilizando colees ao invs de persistir as informaes diretamente no banco de dados, e utilizar estes falsos repositrios para testar sua aplicao sem se preocupar com o banco de dados.

Camada de Negcios

Repositrios

Camada de Acesso a Dados

Figura 18: Repositrios para isolar as camadas de Negcio e Dados

Repositrios, Inversion of Control (IoC) e UnitOfWork na prtica

Para ilustrar os conceitos acima, utilizaremos uma aplicao simples, chamada Natter (gria do idioma Ingls sinnimo de chatter). Algo similar ao Twitter. Uma aplicao que nos permitir demonstrar operaes CRUD implementadas com repositrios, que tornaro nossos Controllers mais limpos e enxutos (prtica que o desenvolvedor deve adotar para suas aplicaes MVC). Esta aplicao de exemplo, ter uma nica pgina (view) que implementar as operaes de SELECT, INSERT e DELETE. No nos preocuparemos com design ou layout de interfaces, para nos concentrar na codificao desta aplicao. A Figura 19 apresenta a interface da aplicao em tempo de execuo.

Pgina 26

Figura 20: A aplicao de exemplo em tempo de execuo. O primeiro passo para reproduzir esta aplicao criarmos um novo projeto baseado no template ASP.NET MVC 4 Application. Este template oferece algumas opes para o desenvolvedor, exibidas na janela New ASP.NET MVC 4 Project, utilize o modelo Internet Application e o engine Razor como mostra a Figura 21. Denomine o projeto como NatterMvc.

Pgina 27

Figura 21: A janela New ASP.NET MVC 4 Project

A estrutura do banco de dados de exemplo

Para este exemplo, o desenvolvedor pode remover os controllers e views criadas pelo template, utilizaremos apenas a estrutura de pastas para codificar nossa aplicao. O primeiro passo criarmos o banco de dados. A estrutura do nosso banco de dados ser simples, apenas as tabelas de usurios (User), mensagens (Nats) e seguidores (Followers). Esta ltima utilizada para estabelecer um relacionamento de muitos-para-muitos, onde armazenaremos os cdigos de usurios seguidores e seguidos (followers e following). Uma vez definida a estrutura do banco de dados, crie um novo projeto do tipo Class Library que utilizaremos como nossa camada de acesso a dados. Denomine este projeto como NatterModel. Adicione uma referncia para o NatterModel no projeto NatterMvc. Adicione um novo item no projeto NatterModel, e selecione o item Data -> ADO.NET Entity Data Model para criar seu arquivo *.edmx. O Entity Framework se encarregar de criar as classes do nosso modelo. Veja a Figura 22.

Pgina 28

Figura 22: O diagrama do nosso Entity Data Model

Criando a Interface para nosso Repositrio

O prximo passo criarmos a Interface INatRepository. Esta Interface ser simples, dever conter trs mtodos: CreateMessage(int authorId, string text), DeleleMessage(int natId) e GetTimeLine() usados para criar, excluir e recuperar respectivamente as mensagens de texto da nossa aplicao. Isto facilitar a codificao do nosso repositrio. A Figura 23 apresenta o cdigo desta Interface.

Pgina 29

Figura 23: A Interface INatRepository Aps codificar esta Interface, nosso projeto NatterModel, estar completo. Certifique-se referenci-lo no projeto NatterMvc antes de seguirmos para o prximo passo.
Criando o mecanismo para IoC

Uma forma simples de ilustrarmos o conceito de IoC ser demonstrada neste passo. No projeto NatterMvc, na pasta Models, crie uma classe chamada Repositories. Adicione nesta classe o cdigo apresentado na Figura 24. Esta classe permitir ao desenvolvedor, substituir o repositrio sempre que desejar, sem alterar o funcionamento da aplicao. Por exemplo, voc pode utilizar repositrios falsos (mocks) para testar sua aplicao, ou ainda criar repositrios associados outras fontes de dados. Em qualquer caso, basta instanci-los na classe Repositories utilizando o mtodo Get da propriedade Nats. Esta uma forma prtica de implementarmos o conceito de Inversion of Control (IoC). Esta prtica facilita a mantenabilidade do cdigo e a criao de testes unitrios para validar suas regras de negcio.

Pgina 30

Figura 24: A classe Repositories

O Repositrio EFNatRepository

Finalmente vamos implementar nosso repositrio. Dentro da mesma pasta Models, crie uma nova classe denominada EFNatRepository. Este ser nosso repositrio. nesta classe que o desenvolvedor implementar os mtodos para interagir com a camada de acesso a dados. Os dois primeiros mtodos, apresentados na Figura 25, so GetTimeLine() e CreateMessage(). O primeiro responsvel por recuperar todas as mensagens gravadas no banco e exibi-las na linha do tempo da aplicao. O segundo mtodo se encarrega de inserir novas mensagens no banco de dados. Ambos utilizam o objeto DbContext chamado NatterSQLContext. Este objeto representa nosso banco de dados. As classes associadas ao contexto foram criadas automaticamente pelo Entity Framework. Dependendo do cenrio da sua aplicao ou das prticas adotadas pela sua empresa, voc pode mapear stored procedures do banco de dados para realizar estas tarefas utilizando o Entity Framework, ou mesmo criar um repositrio que utilize o classes do ADO.NET para implementar os mesmos mtodos. Lembre-se que seu repositrio precisa apenas respeitar o contrato da Interface INatRepository, dito isto, voc pode implementar os mtodos usando ADO.NET, Oracle ODP.NET, Entity Framework, Collections ou o que voc preferir para persistir os dados da sua aplicao. Este o benefcio de trabalharmos com repositrios.

Pgina 31

Figura 25: Os mtodos GetTimeLine() e CreateMessage() Observe que cada mtodo deste repositrio utiliza um bloco using para executar suas tarefas. Este bloco using, envolvendo as aes, garante que todos os recursos utilizados pelo objeto ctx (NatterSQLContext) sero liberados imediatamente aps concluir seu objetivo. Uma particularidade do mtodo GetTimeLine() refere-se a chamada ao mtodo auxiliar ToArray() para retornar o resultado da consulta. Isto necessrio, porque as consultas LINQ so objetos do tipo lazy evaluated, o que significa que esses objetos representam apenas estruturas de consultas at que um mtodo como ToArray(), ToList() ou ToDictionary() seja invocado para que a consulta seja efetivamente executada contra o banco e os registros recuperados.

Pgina 32

Otimizando LINQ Queries

O mtodo DeleteMessage() demonstra uma forma de otimizao para evitarmos roundtrips desnecessrias at o banco de dados. A Figura 26 que apresenta a primeira verso do mtodo DeleteMessage(). Observe que a linha 46 executa uma consulta ao banco de dados para recuperar o objeto Nat que ser marcado para excluso com o mtodo Remove do DbContext. Isto significa que antes de executar a excluso deste registro, nossa aplicao literalmente vai at o banco de dados para recuperar o objeto que corresponde ao Id que se deseja excluir. Este roundtrip pode ser evitado.

Figura 26: O mtodo DeleteMessage() com um roundtrip desnecessrio Observe agora uma implementao diferente para o mesmo mtodo. O uso do mtodo Attach do objeto DbContext um recurso muito til para este cenrio, e ele evita que a aplicao v at o banco para recuperar o objeto que deseja-se excluir. O prprio mtodo Attach se encarrega de marcar o objeto correto para excluso. A construo simples, mas cabe aqui uma explicao. Observe com ateno que o mtodo DeleteMessage(), desta vez, espera dois argumentos natId e authorId, ambos nmeros inteiros que correspondem ao cdigo da mensagem de texto e cdigo do autor desta mensagem. Mas, o desenvolvedor pode estar perguntando por que vamos passar o cdigo do autor se o j temos o Id da mensagem? O que acontece aqui, que o EntityFramework trata os relacionamentos como objetos de primeira classe, ou seja, para voc excluir um registro de uma entidade, voc deve conhecer as chaves-extrangeiras desta entidade. Quando utilizamos a construo anterior (Figura 26), a aplicao vai at o banco e recupera um objeto Nat, que j contm este relacionamento. Para evitarmos esta viagem at o banco, com o objetivo de melhorar a performance da nossa aplicao, precisamos informar corretamente o objeto que desejamos excluir. Por este motivo que o cdigo do autor da mensagem deve ser includo no mtodo DeleteMessage(). Confira o cdigo na Figura 27.

Pgina 33

Figura 27: O mtodo DeleteMessage() utilizando DbContext.Attach()

Implementando UnitOfWork

O conceito de UnitOfWork est baseado na capacidade da aplicao de isolar aes especficas, como demonstrado nos mtodos do nosso repositrio acima. Quando utilizamos os blocos Using para delimitar o processamento da ao, estamos na verdade criando UnitsOfWork. Neste modelo, o desenvolvedor pode criar vrias UnitsOfWork (aes), process-las isoladamente, e apenas submet-las contra o banco de dados quando desejado. Pense neste modelo de UnitsOfWork como uma transao.
Codificando nosso HomeController

Agora que j implementamos nosso repositrio, interfaces e modelos, precisamos nos preocupar com os objetos HomeController e a View correspondente. Para implementar nosso Controller, v para a pasta Controllers, clique com o boto direito do mouse sobre a pasta. No menu de contexto, selecione a opo Add -> Controller. E escolha o template Empty MVC controller, como mostra a Figura 28.

Pgina 34

Figura 28: A janela Add Controller Modifique o cdigo deste controller para que fique exatamente como apresentado na Figura 29. Observe como o cdigo do nosso controller ficou limpo, temos apenas as chamadas para os mtodos do nosso repositrio. A classe Repositories responsvel por direcionar as chamadas para o repositrio desejado. Nosso controller tem apenas trs aes: Index (utilizada para invocar o mtodo GetTimeLine() e exibir as mensagens na pgina), Create que utiliza o mtodo CreateMessage() para inserir um novo registro de mensagem no banco de dados e a ao Delete que dispara o mtodo DeleteMessage() do nosso repositrio para excluir uma mensagem j cadastrada. Observe que o mtodo Create() possui um atributo [HttpPost] associado a ele. Isto necessrio para que este mtodo aceite posts enviados pela View. Este mesmo atributo poderia ser escrito utilizando a notao [AcceptVerbs(HttpVerbs.Post)], sem alterao em seu comportamento.

Pgina 35

Figura 29: A classe HomeController

A View Home

E como ltima pea da nossa aplicao de exemplo, temos a View/Home. Para criar esta View, v para a pasta Views, crie uma pasta chamada Home (se no existir). Clique com o boto direito do mouse sobre a pasta Home, e no menu de contexto, selecione Add -> View. Na janela que ser exibida informe o nome da view como Index, certifique-se que o View engine est definido como Razor (CSHTML), marque a opo Create a strongly-typed view e selecione a classe Nat (NatterModel.Models) para a propriedade Model Class. A janela Add View, permite ao desenvolvedor escolher entre os scaffold templates Create, Delete, Details, Edit, Empty e List. Cada um oferece um layout diferente para a view. O objetivo aqui apenas de agilizar a tarefa de construo da view.

Pgina 36

Contudo, numa aplicao real, muitas vezes, o desenvolvedor criar uma view vazia (Empty template) para adequar seu layout ao padro criado por designers e aprovado pelo usurio.

Figura 30: A janela Add View Uma vez criada a View Home/Index, modifique seu contedo para que fique exatamente como apresentado na Figura 31.

Pgina 37

Figura 31: A View Home/Index Analisando o cdigo apresentado na Figura 31, o desenvolvedor poder observar a principal vantagem do Razor engine a sintaxe. Simples, limpa e fcil de usar. O caracter @ indica o incio de um bloco de processamento no servidor, e voc pode combinar cdigo HTML com cdigo processado no servidor, como mostra a linha 27 onde o nome da imagem formado pelo Id do Autor concatenado com o path da pasta e a extenso (*.png) do arquivo. Outro exemplo a prpria tabela criada para apresentar as mensagens de texto. O contedo do elemento <table> est envolvido pelo bloco @foreach que inicia na linha 24 e termina na linha 39. Mais um exemplo nesta view o formulrio criado com o mtodo Html.BeginForm na linha 13 que combina um controle TextBox gerado pelo objeto Html.TextBox com um boto criado com o cdigo HTML <input type=submit>. O mtodo Html.BeginForm requer dois parmetros: Ao (Action) e Controller. Ao submeter o formulrio, a aplicao enviar os dados para o controller/ao informados nos parmetros. O controller por sua vez, processar o request.

Pgina 38

Finalizando a aplicao de exemplo

Aps concluir a View Home/Index, nossa aplicao de exemplo estar pronta para ser executada. Sua aparncia deve ser semelhante a Figura 20 deste tutorial. Neste exemplo simples, apresentamos o funcionamento de uma aplicao MVC, aplicamos os conceitos baseados no Model 2 (uma variao do padro MVC), incluindo o uso de repositrios, Inversion of Control (IoC) e UnitOfWork.

Figura 20: A aplicao de exemplo em tempo de execuo.

Pgina 39

Prticas comuns (e recomendadas) para aplicaes MVC

Nos prximos pargrafos, vamos demonstrar algumas das prticas mais comuns nos cenrios de aplicaes web, e como elas se diferenciam quando adotamos o padro MVC. Por exemplo, a forma como adicionamos um controle do tipo DropDownList numa aplicao MVC diferente da forma utilizada quando trabalhamos com ASP.NET WebForms. So tarefas comuns, que utilizamos com frequncia no dia-a-dia, como validao de entrada de dados, paginao de registros, controles do tipo lista em cascata, exibir notificaes para o usurio, que se diferenciam no modelo MVC e preciso entende-las antes de implement-las em sua aplicao.

Validao com DataAnnotation Classes

No tpico Regionalizao das Strings e Mensagens do SimpleMembershipProvider , na pgina 13 deste tutorial, voc j teve uma introduo ao mecanismo de validao disponvel atravs do namespace System.ComponentModel.DataAnnotationClasses. Este recurso gera automaticamente a regra de validao na UI, ou seja, voc no precisa se preocupar com client scripts para este tipo de validao, o framework se encarrega disso. A seguir, vamos abordar alguns aspectos especficos deste recurso.
Validando Tipos de Dados especficos

Uma forma simples de validar tipos de dados especficos utilizarmos o atributo de validao [DataType], que nos permite definir dois argumentos nomeados, o tipo de dados (propriedade DataType) que o campo espera receber, e a mensagem de erro (ErrorMessage) que ser exibida para o usurio caso ele informe um tipo invlido para este campo. Os tipos de dados disponveis neste atributo esto apresentados na Tabela 3. Tipos de Dados Currency Custom Date DateTime Duration EmailAddress Html ImageUrl MultilineText Password PhoneNumber Text Time Url Tabela 3: Tipos de Dados do Atributo de Validao [DataType] Obviamente, os formatos para Data e Nmero de Telefone esto, por padro, no formato americano e devem ser customizados para atender nossas necessidades. A Figura 32 mostra o atributo DataType sendo utilizado para a propriedade Email de uma classe. Atributo DataType

Pgina 40

Figura 32: O Atributo de Validao DataType

Validando Campos Requeridos

A validao para campos requeridos simples. Basta adicionarmos o atributo de validao [Required] sobre a propriedade que desejamos tornar obrigatria. Assim como todos os atributos de validao, o desenvolvedor pode utilizar o argumento nomeado ErrorMessage para definir a mensagem que ser exibida para o usurio quando esta regra no for atendida. A Figura 32, na linha 64 temos o exemplo do atributo de validao [Required].
Validao com RegularExpressions

Tambm possvel implementar a validao utilizando RegularExpressions. A Figura 33 apresenta um exemplo de validao da mesma propriedade Email utilizando uma RegularExpression.

Figura 33: Validao com Regular Expressions

O atributo [Display]

Este sem dvida o atributo mais utilizado. O atributo [Display] oferece dois argumentos nomeados, Name e Description. O primeiro define o texto que ser exibido como label do controle associado propriedade ao qual o atributo est vinculado. Por exemplo, para uma propriedade denominada AuthorId, o desenvolvedor pode definir o argumento Name como Cdigo do Autor, quando o engine do MVC processar a View correspondente, o texto exibido ao lado do controle associado propriedade AuthorId ser Cdigo do Autor. O segundo argumento nomeado, Description, pode ser utilizado como complemento, a informao colocada neste argumento ser exibida como ToolTip no controle associado propriedade.
Custom ValidationAttributes

No podemos esquecer da validao de propriedades como CNPJ e CPF. Para casos como estes, podemos implementar atributos de validao customizados. Os validadores customizados devem herdar a classe ValidationAttribute e o contrato da Interface IClientValidatable. Esta Interface requer o mtodo GetClientValidationRules. Uma informao importante, refere-se ao nome do atributo. Os atributos de validao devero sempre apresentar o sufixo Attribute imediatamente aps sua denominao. Por exemplo, o atributo CPF dever chamar-se CPFAttribute, para CNPJ o mesmo CNPJAttribute. Por outro lado, a notao com DataAnnotationClasses suprime o sufixo Attribute, permitindo que o desenvolvedor adicione seu atributo apenas com o [CPF] ou [CNPJ].

Pgina 41

A Figura 34 apresenta a estrutura para o atributo de validao de CPF. A classe completa deste validador, pode ser encontrada nos arquivos do projeto de exemplo que esto disponveis junto com este tutorial.

Figura 34: Atributo de Validao para CPF (apenas estrutura)

Mscaras de entrada de dados

Outra necessidade comum no desenvolvimento de aplicaes o uso de mscaras para entrada de dados. Neste exemplo no estamos utilizando nenhum componente de terceiros, como Telerik, Infragistics, DevXpress, bastante conhecidos no mercado. Esses componentes, em sua maioria, oferecem vrios recursos que facilitam a vida do desenvolvedor. Desta forma, precisamos recorrer a outros mecanismos que proporcionem resultados similares. Uma prtica comum, neste caso, o uso de scripts JQuery para aplicar as mscaras de entrada. Sem muito esforo, o desenvolvedor pode concluir esta tarefa. A Figura 35 apresenta o cdigo JQuery utilizado para aplicar mscaras de Telefone, CPF, Data e CEP. Para que este script funcione corretamente, o desenvolvedor deve certificar-se de ter adicionado o arquivo jquery.maskedinput-1.3.min.js ao projeto.

Pgina 42

Figura 35: Funo JQuery para aplicar mscaras de entrada de dados

Exibindo notificaes para o usurio

Manter seu usurio informado sobre o processamento da sua aplicao fundamental. Para no estendermos este tutorial demasiadamente, gostaria de compartilhar o modelo de notificao que tenho adotado para aplicaes MVC. Voc pode testar este modelo, na prtica, acessando este endereo: http://demo.taiga.nl/notification/. Este modelo de autoria do Holands Martijn Boland, e est disponvel para download no GitHub. Para maiores informaes, acesse o este endereo: http://blogs.taiga.nl/martijn/2011/05/03/keep-your-users-informed-with-asp-netmvc/.

Trabalhando com Controles de Lista

Carregar controles do tipo lista, como DropDownLists ou ListBoxes uma tarefa simples e comum, mas tambm diferente para as aplicaes MVC quando comparamos com WebForms.
Carregando DropDownLists

Considere o cenrio de uma aplicao comercial, onde voc precisa exibir DropDownLists para selecionar Estado e Cidade. Os dados j esto armazenados no banco de dados, e as entidades expostas pelo DbContext criado pelo EntityFramework. Como podemos carregar esses controles numa aplicao MVC? Na verdade, existem diversas formas para alimentarmos controles do tipo lista em aplicaes MVC. A forma apresentada neste tutorial prtica e apresenta uma implementao muito simples. O primeiro passo criarmos uma View que encapsular o controle de lista. V para pasta Views, Shared e crie uma pasta chamada EditorTemplates (se no existir). Dentro desta pasta, crie uma View utilizando o Empty Template (vazio). No arquivo criado, modifique o cdigo para que fique exatamente como apresentado na Figura 36. Este arquivo ser responsvel por informar a UI que o editor para a propriedade EstadoId ser um controle DropDownList que exibir todos as unidades da federao e estados gravados no banco de dados.

Pgina 43

Figura 36: O EditorTemplate para propriedade EstadoId Uma vez criado este template, com a ajuda do atributo [UIHint] associado propriedade EstadoID, e o engine do ASP.NET MVC se encarregar de exibir o controle DropDownList devidamente carregado. Observe a Figura 37 que utiliza o atributo [UIHint] para associar o EditorTemplate s propriedades CidadeID e EstadoID.

Figura 37: Utilizando o Atributo [UIHint]

DropDownLists em Cascata com JQuery

Outra tarefa comum neste mesmo cenrio, refere-se a capacidade de filtrarmos os registros apresentados em um controle DropDownList com base no registro selecionado pelo usurio em outro controle do mesmo tipo. Por exemplo, quando o usurio selecionar o Estado desejado no controle explicado no tpico anterior, nossa aplicao dever carregar o controle de lista associado propriedade CidadeID com as cidades pertencentes ao estado selecionado. Com algumas linhas de cdigo adicionais, um pouco de JQuery + JSON, e esta tarefa ser facilmente concluda. Observe a ao GetCidades() adicionada classe ConsumidorController. Esta ao ser invocada a partir de uma funo JQuery publicada na View Consumidor/Create. A Figura 38 apresenta o cdigo que implementa a ao GetCidades().

Pgina 44

Figura 38: A ao GetCidades da classe ConsumidorController A funo JQuery, para implementar a carga em cascata do controle DropDownList CidadeID, tambm simples. A Figura 39 apresenta o cdigo necessrio para esta funo.

Figura 39: A funo JQuery para carregar o controle DropDownList CidadeID

Pgina 45

Paginao de Registros no MVC

A paginao de registros tambm uma tarefa muito comum e necessria para aplicaes web. No caso das aplicaes MVC, temos uma alternativa disponvel atravs do NuGet Gallery, que o controle PagedList, encontrado neste endereo: http://nuget.org/packages/PagedList.Mvc.
Implementando Paginao para o Grid

Para utilizarmos o controle PagedList em nosso projeto, em primeiro lugar, preciso instalar este controle a partir do Package Manager Console. O comando para instalao simples, basta digitar Install-Package PagedList.Mvc na linha de comando do Package Manager Console (Menu Tools -> Library Package Manager. No topo classe Controller, onde utilizaremos o PagedList, necessrio acrescentar a declarao: using PagedList. Uma vez adicionada esta declarao, vamos modificar o contedo da nossa ao Index para acrescentarmos os parmetros necessrios para o controle PagedList. Ao final deste processo, o cdigo da nossa ao Index dever apresentar construo semelhante apresentada na Figura 40.

Figura 40: A ao Index modificada para o controle PagedList. Observe na Figura 40, a linha em destaque, o mtodo ToPagedList(pageNumber, pageSize), este o mtodo responsvel por implementar efetivamente a paginao dos registros. No exemplo acima, o tamanho da pgina (pageSize) definido do arquivo Web.config e recuperado com o auxlio do objeto ConfigurationManager. A View que apresentar os registros paginados, tambm deve sofrer as alteraes necessrias. A primeira delas a declarao da classe Model que deve que deve ser derivada da Interface IPagedList, como mostra a Figura 41.

Pgina 46

Figura 41: A declarao da classe Model E finalmente, acrescentamos o cdigo que exibir os links para navegao atravs das pginas. Este cdigo, deve ser colocado logo abaixo do bloco foreach utilizado para listar os registros. O cdigo na ntegra est disponvel com a aplicao de exemplo distribuda junto com este tutorial. A Figura 42 apresenta o fragmento do cdigo necessrio para o PagedList.

Figura 42: O cdigo para os links de navegao do PagedList.

Concluso Final
H muitos e diferentes modelos para construirmos uma aplicao MVC. O modelo apresentado neste tutorial baseia-se em prticas recomendadas para o mercado. Sugiro que o desenvolvedor aprofunde seus conhecimentos visitando o portal www.asp.net/mvc.

Pgina 47

Referncias
Adam Tulipers Blog http://completedevelopment.blogspot.com.br/ Alex James Blog http://blogs.msdn.com/b/alexj/ Channel 9 http://channel9.msdn.com/ Entity Framework Developer Center http://msdn.com/ef Portal ASP.NET MVC http://www.asp.net/mvc/ NuGet Gallery PagedList http://nuget.org/packages/PagedList.Mvc Martijn Bolands Blog http://blogs.taiga.nl/martijn/

Pgina 48