Andre Baltieri - ASP.NET MVC

ASP.NET MVC–Globalizando aplicações

2012-10-09T17:03:46Z

Introdução

O ASP.NET MVC, assim como boa parte dos produtos da Microsoft, foi criado em Inglês (Novidade hein), e sendo assim, as vezes nos deparamos com mensagens que para nossos usuários (PT-BR) não são interessantes.

As validações com DataAnnotations são fáceis e simples de utilizar, mas na outra mão, temos suas mensagens de retorno, como “The field {1} is required.” e assim por diante.

Neste post, abordarei algumas soluções para globalizar aplicações ASP.NET MVC sem muito esforço.

Tudo começa no Web.Config

Globalizar uma aplicação na plataforma .NET começa pela adição da TAG Globalization no arquivo de configuração Web.Config.

Esta tag possui conhecidos parâmetros:

Culture – Cultura da aplicação (PT, EU, US)
uiCulture – Cultura da interface (PT-BR, EU, US)
EnableClientBasedCulture - Obtém ou define um valor indicando se as propriedades Culture e UICulture devem se basear no valor do AcceptLanguage, que é enviado pelo cabeçalho do browser.

Esta propriedade deve ser definida entre as tags System.Web no arquivo Web.Config, conforme imagem abaixo.

Existem vários tutorias sobre como globalizar aplicações ASP.NET Web Forms, este é um bom exemplo: http://msdn.microsoft.com/en-us/library/bz9tc508.aspx.

Globalizando decimais

Nosso primeiro desafio é globalizar números decimais, que neste caso aceitam somente ponto “.” como casa decimal, e necessitamos de vírgula “,”.

A figura abaixo mostra o erro, onde é exibida uma mensagem mesmo o número estando correto (Para o padrão Brasileiro).

Este erro pode ser contornado ao adicionar um JavaScript que extende os validation methods do jQuery, permitindo o uso de vírgula “,” ao invés de ponto “.”.

Infelizmente, o site de plugins do jQuery está fora, impossibilitando o download deste script: http://archive.plugins.jquery.com/node/8/release

Fique à vontade em baixar o arquivo do source no fim deste artigo.

Com o arquivo “methods_pt.js” incluso na pasta Scripts da aplicação, é só fazer referência ao mesmo sempre que utilizar o jQuery Unnobstrutive, como nas páginas Create e Edit.

Deste modo, já podemos utilizar decimais “abrasileirados”.

Mas ainda temos o problema da mensagem em inglês, caso um valor com “.” seja digitado.

Infelizmente, a única forma que encontrei para resolver este problema, foi mediante um regular expression, que só permite números.

Deste modo, agora temos a mensagem agora está em portugês, como definida nas anotações da propriedade.

Pronto, decimais globalizados!

Utilizando Resources com DataAnnotations

Em alguns casos, você pode querer utilizar os bones e velhos Resources, que são arquivos onde mapeamos mensagens a serem substituidas em tempo de execução, justamente para globalização de aplicações.

Para este exemplo criei um arquivo chamado DataAnnotations.resx na pasta App_GlobalResources da aplicação, e nele adicionei duas strings.

A primeira chave, o “LidoDoResource” é uma palavra não reservada, que utilizarei para leitura nas anotações.

Já a palavra PropertyValueInvalid é uma palavra reservada, que toda vez que um valor inválido, para uma data por exemplo, for inserido, esta mensagem será retornada.

Então, no arquivo Global.asax, definimos um binder para que as requisições utilizem o Resource que criamos.

Para utilizar os resources criados nas anotações, basta utilizar as propriedades ErrorMessageResourceName e ErrorMessageResourceType.

O resultado é que agora ele lê a mensagem direto do Resource.

No caso do resource PropertyValueInvalid, este processo ocorre automaticamente.

Conclusão

Globalizar aplicações sempre desprenderá um esforço extra, porém temos alguns meios de minimizar isto, como mostrado neste post.

A questão dos decimais no ASP.NET MVC também é algo que irrita um pouco, mas como vimos pode ser facilmente contornado com um JavaScript.

Downloads

Comecei este projeto como alguns testes para o IE7, então, por favor, desconsiderem o nome do projeto.

http://files.insidedotnet.com.br/IE7Tests.zip

Referências

Using MVC 3 with non-English Locales
http://blogs.msdn.com/b/rickandy/archive/2011/02/17/using-mvc-3-with-non-english-locales.aspx

How to: Set the Culture and UI Culture for ASP.NET Web Page Globalization
http://msdn.microsoft.com/en-us/library/bz9tc508.aspx

André Baltieri
MTAC – Microsoft Technical Audience Contributor
MSN: andrebaltieri@hotmail.com
Twitter: @andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

ASP.NET MVC 3 Global Filters

2012-10-09T17:02:10Z

Introdução

Na versão 2 do MVC temos os Filters, que são aplicados aos controllers e actions dos controllers para modificar a forma como o qual é executado. Os filtros mais conhecidos são o HandleError e o Authorize, que manipulam erros ocorridos no controller/action ou restringem acesso aos mesmos respectivamente.

Nesta nova versão do MVC, teremos uma atualização que permitirá criar estes filtros de forma global, ou seja, para toda a aplicação, dentro do arquivo Global.asax.

Como tudo funcionava

Antes, para o Controller ou Action teríamos algo como no código abaixo:

// Manipula os erros
[HandleError]
public class HomeController : Controller
{
    // Restringe o acesso somente à usuários autenticados
    [Authorize]
    public ActionResult Index()
    {
        ViewData["Message"] = "Welcome to ASP.NET MVC!";            
        return View();
    }
  
// Manipula os erros
    [HandleError]
    public ActionResult About()
    {
        return View();
    }
}

Global Filters

Agora, no ASP.NET MVC 3, podemos globalizar estes filtros no arquivo Global.asax. Este filtro então será aplicado para TODOS os controllers e actions. O código abaixo mostra o novo método (RegisterGlobalFilters) adicionado no arquivo Global.asax de uma aplicação ASP.NET MVC 3.

Podemos pensar no contexto em que temos uma aplicação onde o usuário é autenticado via Single Sign On por exemplo, e tem que acessar a aplicação já com o token de autenticação. Ou seja, a aplicação toda (Global) requer autenticação. Poderíamos adicionar no método RegisterGlobalFilters() um filtro para que somente usuários autenticados acesse esta aplicação (Utilizando o AuthorizeAttribute()).

public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
    filters.Add(new HandleErrorAttribute());
    filters.Add(new AuthorizeAttribute());            
}
  
protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();
  
    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
}

Neste caso a autenticação é externa à aplicação, pois nem mesmo o login interno estaria acessível, pois globalmente esta aplicação está protegida contra usuário não autenticados, e sendo assim, nem mesmo a URL http://localhost:/Account/LogOn?ReturnUrl=%2f funcionaria.

Podemos também criar casos específicos para estes filtros, como por exemplo, criar um filtro global para manipular erros somente quando o Debug estive habilitado e etc.. Também podemos utilizar estes filtros globais com DI (Injeção de dependência).

Conclusão

O novo recurso de filtros Globais permite-nos aplicar filtros para a aplicação toda de uma só vez, de forma fácil e simples, através do arquivo Global.asax. Podemos também criar casos específicos para a adição de um filtro ou até mesmo manipula-lós através de Dependency Injection.

Referências

Scott Gu
http://weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx

André Baltieri
MTAC – Microsoft Technical Audience Contributor
MSN: andrebaltieri@hotmail.com
Twitter: @andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

Boas práticas na WEB (Parte 1 - DTD, META-TAG e FAVICON)

2012-10-09T16:59:57Z

O atual mercado da Web

Hoje em dia, não é tão difícil se fazer um site, qualquer um com um pouco de dedicação e com as mágicas da tecnologia abre um editor WYSIWYG (What you see is What you Get – O que você vê, é o que você tem) e consegue fazer mil maravilhas.

Um ponto fraco disso tudo, é que nós, profissionais da Web sofremos com isso. Quem já não perdeu um trabalho para um “cara” que cobrava R$ 100,00 para desenvolver um Web Site?

Bom, chega de choro, vamos ao que interessa.

DTDs, DOCTYPES

O Fato é que em muitos dos casos, quando se desenvolvem sites, esquecem, ou nem mesmo sabem que existe um padrão por trás disso tudo. De fato, isso não é obrigatório, mas ajuda na depuração de erros de design no seu site.

Ter um site “validado” não é difícil, existem apenas algumas regras a serem seguidas, tais como:

DTD – Document Type Definition: Por padrão, o Adobe Dreamweaver, Microsoft Expression Web e outros editores WYSIWYG já trazem no topo quando você cria um documento HTML. Exemplo:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">

Nota-se que não há somente um tipo de HTML, existem vário, tais como HTML 4.01 Strict e Transitional, XHTML 1.0 Transitional entre outros.

Estes tipos de HTML seguem um padrão da W3C (World Wide Web Consortium)

Uma maior descrição dos tipos de DTD, pode ser encontrado aqui http://www.alistapart.com/stories/doctype/

As ferramentas que processam HTML (Browsers por exemplo), precisão saber qual tipo de definição ele está usando. Então é por isso que um HTML precisa especificar um DTD em seu topo.

Especificar um DOCTYPE, também implica em informar ao Browser ou outras ferramentas de renderização de arquivos HTML, qual a versão do HTML está sendo utilizada, e esta é uma parte muito importante do documento.

Seguindo a risca os critérios acima, teríamos como início, o seguinte modelo:

<!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>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>Untitled 1</title>
</head>
    <body>
    </body>
</html>

Nota-se que já na primeira linha do documento, definimos nosso DOCTYPE.

Na segunda linha (<html xmlns="http://www.w3.org/1999/xhtml">), informamos o XMLNS.

O XMLNS é um Namespace da própria W3C Schools, e deve sempre conter este valor.

http://www.w3.org/TR/REC-xml-names/

Em seguida vem o resto do documento.

META-TAGs

Outra coisa pouco usada são as META-TAGs, que servem como base para busca, identificação da página e do autor, entre outros.

Veja abaixo as respectivas descrições:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /><meta name="author" content="Andre Baltieri - andrebaltieri@hotmail.com" />
  
<meta name="description" content="Descrição do Documento" />
  
<meta name="keywords" content="Palavra Chave 1, Palavra Chave 2 " />

Na linha 1, informamos que o conteúdo descrito em nosso documento é do tipo texto/HTML, e que o tipo de caractere utilizado em nosso documento é UTF-8 (Conjunto de caracteres que possui “Ç”, “~” entre outros.)

Na linha 2, definimos o atributo “Author”, que nada mais é do que o autor do documento, coisa muito importante e pouco utilizada.

Na linha 3, definimos uma breve descrição do documento, e na linha 4, adicionamos “Palavras-Chaves” ao nosso documento, item de suma importância para futuras buscas em seu web site.

Sendo assim, nosso documento já foi um pouco modificado, agora ele está mais robusto e seguindo já alguns padrões.

FAVICON

Para complementar, só por curiosidade, podemos adicionar um ícone ao nosso documento, é o chamado “favicon”, ou “favorite icon”. Este ícone irá representar o documento, sendo exibido na barra de endereços do Browser, antes do endereço, ou nas abas dos navegadores, antes do título do documento.

   1: <link rel="shortcut icon" href="Imagens/favicon.ico" mce_href="Imagens/favicon.ico" type="image/x-icon" />
   2:  

Rapare que usamos a tag LINK, e na propriedade REL, dizemos que ele é do tipo “SHORTCUT ICON”, algo referente aos favoritos em português.

Em seguida, o atributo HREF se encarrega de informar onde o ícone se encontra, e por fim, informamos o TYPE(Tipo) do arquivo, que é uma imagem, por isso usa-se “image/x-icon”.

Bom, neste exato momento, temos o seguinte modelo:

<!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>
<title>Minha Página</title>
    <link href="CSS/Estilos.css" mce_href="CSS/Estilos.css" rel="stylesheet" type="text/css" />
    <link rel="shortcut icon" href="Imagens/favicon.ico" mce_href="Imagens/favicon.ico" type="image/x-icon" />
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <meta name="author" content="Andre Baltieri - andrebaltieri@hotmail.com" />
    <meta name="description" content="Breve Descrição da Página" />
    <meta name="keywords" content="Algumas palavras chaves para buscas" />
</head>

VALIDANDO SEU HTML

Uma aplicação interessante, é o validador de HTML da W3C. Ele valida todo o HTM, e aponta se existem TAGs erradas ou que não seguem os padrões.

Alguns editores WYSIWYG já possuem um validar, que em tempo de execução apontam falhas em seu código HTML. Por via de dúvidas, aqui fica o LINK:

http://validator.w3.org/check

Só é preciso enviar o HTML, ou informar a URL do mesmo para que seja validado.

André Baltieri
MTAC – Microsoft Technical Audience Contributor
MSN: andrebaltieri@hotmail.com | Twitter:
@andrebaltieri
Blog: http://andrebaltieri.net

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

MTAC - Microsoft Technical Audience Contributor

2011-10-25T16:21:18Z

Durante o Community Zone passado (01 de Outubro). havia sido discutido e comentado sobre um novo título a nível nacional para os influenciadores (Não MSP/MVP) Microsoft.

Hoje recebi o convite do Fabio Hara para me juntar ao programa como um MTAC, e fiquei feliz pela oportunidade/reconhecimento.

Para quem quiser saber mais sobre o programa, aqui vai o link: http://www.fabiohara.com.br/2011/10/25/mtac-microsoft-technical-audience-contributor-perguntas-e-respostas/

Abraços!

André Baltieri
MTAC - Microsoft Technical Audience Contributor
MSN: andrebaltieri@hotmail.com | Twitter:
@andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

Learn MVC
http://learn-mvc.net/

Community Zone 2011

2011-09-26T02:16:20Z

Introdução

O Community Zone é um evento fechado, realizado pela Microsoft especialmente para MVPs, MSPs e principais influenciadores.

Este ano o evento será na sede da Microsoft Brasil, em São Paulo, um dia depois do TechEd, maior evento da Microsoft na américa latina.

Ano passado já tive o prazer de participar deste evento (Vide post antigo) e este ano novamente, a convite do Fabio Hara, estarei presente =D.

O que isto importa?

Durante este evento, temos contato direto com os gerentes de produto da Microsoft e ficamos por dentro das futuras novidades e tendências.

Como sou líder da Inside .NET, com certeza irei repassar essa visão para comunidade, e espero ter boas novidades.

O que mais vem por ai?

Ahh, ainda é surpresa, mas estou preparando um evento focado em Mobile para região de Piracicaba, não um simples evento, um … bom… surpresa né.

Abraços!

André Baltieri
@andrebaltieri

Profissionais Sênior

2011-09-16T03:22:57Z

Introdução

Senioridade é algo complexo. Quando se fala que é Sênior em alguma tecnologia ou assunto, a expectativa sempre é alta, esperando que o candidato nos surpreenda, que nos dê respostas mais exatas, ou até cite pontos que não conseguimos pensar antes.

O fato é que hoje temos muitos falso sêniors! Curriculos recheados de tecnologias, palavras bonitas que as empresas sempre focam como ”trabalho em equipe”, “pró-atividade”, mas será que o candidato é mesmo sênior?

Aqui descreverei alguns pontos que devemos refletir antes de colocar a palavra “Sênior” no currículo.

O que esperamos de um sênior

Primeiramente, não é por que você é programador que não deve pensar nos itens abaixo. Muita gente acha que só o gerente do projeto deve ser lider, responsável e etc. Este pensamento é errado, estes são responsabilidades de todos!

Responsabilidade
Um profissional sênior deve saber quando a responsabilidade é sua, e mesmo que não seja, se pode direcionar para alguém que possa ajudar (O famoso não sei fazer, mas sei quem sabe).

Se for pensar em responsabilidade, imagina que o servidor da sua aplicação caiu. É responsabilidade sua ou do time de infraestrutura?
SUA! a aplicação é sua, você que toma conta, então você faz a ponte com o time de infra, para o usuário isto deve ser transparente!

Este é só um dos varios exemplos que podemos citar. Delegar SUAS responsabilidades é algo “feio”.
Flexibilidade
Um sênior não pode ser “mocinha”! Você deve sim se especializar em alguma tecnologia, mas se precisar fazer um serviço pra acessar uma tabela no SAP, ou um Job (Console Application) você também tem que estar preparado.

Se precisar viajar, ficar até mais tarde (Este é um ponto delicado que em alguns casos até entendo a impossibilidade devido a problemas pessoais, familia e etc) você fica. Missão dada é missão cumprida!
Ownership
Você aceitou? Então faça! Fale com quem for preciso, não fique esperando as coisas acontecerem, vá atrás de resolver a situação, se você não sabe (Ninguém sabe tudo) peça ajuda a quem saiba, mas tenha esse comprometimento. Isso muda tudo!
Pró-atividade
Palavrinha chave que sempre vejo nos curriculos, e quando peço um exemplo, não conseguem me dar.

Ser pró-ativo é tentar ao maximo resolver as coisas sem “engavetá-las”, sem deixar os problemas de lado, assumindo as responsabilidades. Em alguns casos você consegue até prever algumas situações e amenizá-las antes que elas aconteçam.

Um profissional pró-ativo é aquele que sempre corre atrás para resolver situaçòes e conseguir trabalhar sussegado!
Liderança
Há um tempo atrás lí um livro interessante que chama-se “Você não precisa ser chefe para ser líder”. Mudou minha vida!

Um bom líder é aquele que consegue criar todo o ambiente necessário para que sua equipe possa trabalhar sem impecílios e quase sem imprevistos.

Um bom líder nunca precisa lembrar as pessoas que ele é o líder, todos veem isto!

Um bom líder trata todos iguais mas de forma que cada um se sinta diferenciado e motivado na equipe.

Um bom líder conduz todos ao ideal e aos objetivos definidos, removendo os obstáculos para que o time prossiga.

Um bom líde SABE OUVIR, e assim (Somente assim) pode tomar a decisão certa.
Espírito de Equipe
Muitas cabeças junto geram idéias diferentes! Não leve para o pessoal quando alguém discorda das suas idéias, ou quando sua idéia não foi aceita. Um sênior faz este meio campo com facilidade.

Não me venha com chorumelas!

Deu tudo errado, e agora? De quem é a culpa?
Um sênior sabe assumir a sua parte da culpa e o mais importante, sabe corrigir os erros cometidos, ou apontá-los para que não se repitam no futuro.

Um sênior não deve ficar culpando itens como “falha no servidor que impediu a publicação da aplicação a tempo”, pois um bom sênior teria previsto isto, quem trabalha com TI sabe que temos muitas coisas instáveis, e é melhor ter um tempo a mais no seu cronograma, entregar antes e surpreender o usuário, do que ter um cronograma justo e passar estes riscos.

Show me the code!

Do meu ponto de vista (Meu), nem adianta mostrar diploma da UNICAMP, USP e etc, nem milhões de certificações.

Quando você diz que você é um programador C# sênior, ou um dev ASP.NET Sênior, o que espero ouvir de você são problemas grandes que você solucionou, experiências que passou, desafios.

Você pode ter vários títulos no papel, mas se você nunca viveu os dramas de um projeto grande, com soluções complexas e vários casos que deram errado (Errando se aprende até mais), me desculpa, mas você não é sênior.

Certificações te dão alguns pontos extra, mas não garantem sua senioridade!

Conclusão

Baltieri você é chato, arrogante, metido e etc. Talvez, mas gosto das coisas certas! Se você vai participar de um processo seletivo, seja sincero! Quanto mais “senioridade” seu currículo tiver, mais que os entrevistadores vão te perturbar para tirar essas informações de você, e acredite, é muito fácil saber se um profissional de TI é sênior ou não!

André Baltieri
MSN: andrebaltieri@hotmail.com | Twitter:
@andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

Learn MVC
http://learn-mvc.net/

Repositório Genérico com EF 4.1

2011-08-07T23:49:19Z

Introdução
Domain
DataContexts
Unit of Work
Repositório Genérico
Outros repositórios
Camada de serviços
Integrando com ASP.NET MVC
Conclusão
Source
Referências

1. Introdução

O Repository Pattern é um padrão conhecido e que consiste em persistir o estado das entidades no banco de dados (Repositório).

Como há uma certa similaridade entre as ações das entidades (Por exemplo os métodos CRUD), a ideia é ter um repositório genérico, que sirva como base para todas as entidades da aplicação.

Talvez alguns pontos possam ser melhorados, fiquem à vontade em sugerir melhorias =)

2. Domain

Não vou explicar a criação do domínio para não perder tempo, mas é somente a criação das três classes abaixo:

   1:  using System.ComponentModel.DataAnnotations;

   2:  using System.Web.Mvc;

3:

   4:  namespace SampleApp.Domain.Entities

   5:  {

   6:      public class User

   7:      {

   8:          public int Id { get; set; }

9:

  10:          [Required(ErrorMessage="Campo obrigatório.")]

  11:          [Display(Name = "Usuário")]

  12:          public string UserName { get; set; }

13:

  14:          [Required(ErrorMessage = "Campo obrigatório.")]

  15:          [DataType(DataType.EmailAddress)]

  16:          [Display(Name = "E-mail")]

  17:          public string Email { get; set; }

18:

  19:          [Required(ErrorMessage = "Campo obrigatório.")]

  20:          [DataType(DataType.Password)]

  21:          [Display(Name = "Senha")]

  22:          public string Password { get; set; }

23:

  24:          [DataType(DataType.Password)]

  25:          [Display(Name = "Confirmar senha")]

  26:          [Compare("Password", ErrorMessage = "As senhas digitadas não conferem.")]

  27:          public string ConfirmPassword { get; set; }

  28:      }

  29:  }

Classe User.cs

   1:  using System.Collections.Generic;

   2:  using System.ComponentModel.DataAnnotations;

3:

   4:  namespace SampleApp.Domain.Entities

   5:  {

   6:      public class Role

   7:      {

   8:          public int Id { get; set; }

9:

  10:          [Required(ErrorMessage = "Campo obrigatório.")]

  11:          [Display(Name = "Perfil")]

  12:          public string Name { get; set; }

13:

  14:          [Required(ErrorMessage = "Campo obrigatório.")]

  15:          [Display(Name = "Aplicação")]

  16:          public int ApplicationId { get; set; }

  17:          public virtual Application Application { get; set; }

18:

  19:          public virtual ICollection<User> Users { get; set; }

  20:      }

  21:  }

Classe Role.cs

   1:  using System.Collections.Generic;

   2:  using System.ComponentModel.DataAnnotations;

3:

   4:  namespace SampleApp.Domain.Entities

   5:  {

   6:      public class Application

   7:      {

   8:          public int Id { get; set; }

9:

  10:          [Required(ErrorMessage = "Campo obrigatório.")]

  11:          [Display(Name = "Aplicação")]

  12:          public string Name { get; set; }

13:

  14:          public virtual ICollection<Role> Roles { get; set; }

  15:      }

  16:  }

Classe Application.cs

3. DataContext

O contexto é o responsável por gerenciar os estados das entidades e seus grupos. Desta forma, o contexto fica da seguinte maneira (Por hora):

   1:  using System.Data.Entity;

   2:  using SampleApp.Domain.Entities;

3:

   4:  namespace SampleApp.Data.Contexts

   5:  {

   6:      public class SampleDataContext : DbContext

   7:      {

   8:          public DbSet<User> Users { get; set; }

   9:          public DbSet<Role> Roles { get; set; }

  10:          public DbSet<Application> Applications { get; set; }

  11:      }

  12:  }

Data/Contexts/SampleDataContext.cs

4. Unit of Work

Se utilizarmos o contexto do jeito que ele está, quando precisarmos abrir duas ou mais requisições em um mesmo contexto, teremos problemas. Na aplicação web por exemplo, trabalharemos com o famoso “Session Per Request” onde abrimos uma sessão quando a página inicia e já fechamos a mesma quando a página termina de ser renderizada, mantendo a aplicação sempre desconectada do banco de dados.

Para fazer este gerenciamento utilizaremos o Unit Of Work (Referência 1), que manterá a lista de objetos modificados, excluídos e incluídos (Tracker) na sessão. Com estes itens na sessão, nós decidiremos quando “comitar” estas modificações ou não.

Sua implementação é simples, bastando criar uma interface como na Listagem 1 e implementa-lá no contexto, como na Listagem 2.

   1:  namespace SampleApp.Data.Contexts.Interfaces

   2:  {

   3:      public interface IUnitOfWork

   4:      {

   5:          void Save();

   6:      }

   7:  }

Listagem 1 – Unit of Work

   1:  using System.Data.Entity;

   2:  using SampleApp.Data.Contexts.Interfaces;

   3:  using SampleApp.Domain.Entities;

4:

   5:  namespace SampleApp.Data.Contexts

   6:  {

   7:      public class SampleDataContext : DbContext, IUnitOfWork

   8:      {

   9:          public DbSet<User> Users { get; set; }

  10:          public DbSet<Role> Roles { get; set; }

  11:          public DbSet<Application> Applications { get; set; }

12:

  13:          public void Save()

  14:          {

  15:              base.SaveChanges();

  16:          }

  17:      }

  18:  }

Listagem 2 – Versão final do contexto

5. Repositório Genérico

O repositório genérico conterá os métodos comuns entre todos os repositórios da aplicação, fique à vontade em incluir outros métodos que julgue comum em sua aplicação na interface e classe.

Deste modo, criaremos a interface determinando quais métodos serão expostos e uma classe que implementará esta interface.

   1:  using System.Linq;

2:

   3:  namespace SampleApp.Data.Repositories.Interfaces

   4:  {

   5:      public interface IBaseRepository<T> where T : class

   6:      {

   7:          T Find(int id);

   8:          IQueryable<T> List();

   9:          void Add(T item);

  10:          void Remove(T item);

  11:          void Edit(T item);

  12:      }

  13:  }

Data/Repositories/Interfaces/IBaseRepository.cs

   1:  using System;

   2:  using System.Data;

   3:  using System.Linq;

   4:  using SampleApp.Data.Contexts;

   5:  using SampleApp.Data.Contexts.Interfaces;

   6:  using SampleApp.Data.Repositories.Interfaces;

7:

   8:  namespace SampleApp.Data.Repositories

   9:  {

  10:      public class BaseRepository<T>

  11:          : IDisposable, IBaseRepository<T> where T : class

  12:      {

  13:          private SampleDataContext _context;

14:

  15:          #region Ctor

  16:          public BaseRepository(IUnitOfWork unitOfWork)

  17:          {

  18:              if (unitOfWork == null)

  19:                  throw new ArgumentNullException("unitOfWork");

20:

  21:              _context = unitOfWork as SampleDataContext;

  22:          }

  23:          #endregion

24:

  25:          public T Find(int id)

  26:          {

  27:              return _context.Set<T>().Find(id);

  28:          }

29:

  30:          public IQueryable<T> List()

  31:          {

  32:              return _context.Set<T>();

  33:          }

34:

  35:          public void Add(T item)

  36:          {

  37:              _context.Set<T>().Add(item);

  38:          }

39:

  40:          public void Remove(T item)

  41:          {

  42:              _context.Set<T>().Remove(item);

  43:          }

44:

  45:          public void Edit(T item)

  46:          {

  47:              _context.Entry(item).State = EntityState.Modified;

  48:          }

49:

  50:          public void Dispose()

  51:          {

  52:              _context.Dispose();

  53:          }

  54:      }

  55:  }

Data/Repositories/BaseRepository.cs

A única observação é que o repositório recebe em seu construtor o “Unit of Work” que se refere a sessão atual onde as entidades serão gerenciadas.

6. Outros repositórios

Com o repositório genérico criado, vamos criar os outros repositórios, e para cada repositório sua interface, para que possam ser injetadas futuramente.

Aqui listarei somente o repositório da classe Role, para ver o resto consulte o código disponibilizado na sessão 10 deste artigo.

   1:  using System;

   2:  using SampleApp.Domain.Entities;

3:

   4:  namespace SampleApp.Data.Repositories.Interfaces

   5:  {

   6:      public interface IRoleRepository : IBaseRepository<Role>, IDisposable

   7:      {

   8:      }

   9:  }

Data/Repositories/Interfaces/IRoleRepository.cs

   1:  using SampleApp.Data.Contexts;

   2:  using SampleApp.Data.Contexts.Interfaces;

   3:  using SampleApp.Data.Repositories.Interfaces;

   4:  using SampleApp.Domain.Entities;

5:

   6:  namespace SampleApp.Data.Repositories

   7:  {

   8:      public class RoleRepository: BaseRepository<Role>, IRoleRepository

   9:      {

  10:          IUnitOfWork unitOfWork = new SampleDataContext();

11:

  12:          public RoleRepository(IUnitOfWork unitOfWork)

  13:              : base(unitOfWork)

  14:          {

15:

  16:          }

  17:      }

  18:  }

Data/Repositories/RoleRepository.cs

Como existem várias formas de gerenciar contexto com Unit of Work, aqui eu instancio ele na classe internamente, mas ele poderia ser recebido pelo construtor e passado adiante.

7. Camada de serviços

Com os repositórios criados, é hora de ver como utiliza-los, e para este caso utilizarei a camada de serviços.

A camada de serviços acumula toda burocracia que ficaria nos controllers, e como a ideia é ter os controllers limpos, podemos trazer o código para cá para ajudar.

Assim como os repositórios tem suas operações em comum, os serviços também tem.`

Nota: Para utilizar o ModelStateDictionary é preciso adicionar referência ao namespace System.Web.Mvc.

   1:  using System.Linq;

2:

   3:  namespace SampleApp.Service.Interfaces

   4:  {

   5:      public interface IBaseService<T> where T : class

   6:      {

   7:          T Find(int id);

   8:          IQueryable<T> List();

   9:          void Add(T item);

  10:          void Remove(T item);

  11:          void Edit(T item);

  12:      }

  13:  }

IBaseService.cs

   1:  using System.Linq;

   2:  using SampleApp.Data.Contexts;

   3:  using SampleApp.Data.Contexts.Interfaces;

   4:  using SampleApp.Data.Repositories;

   5:  using SampleApp.Data.Repositories.Interfaces;

   6:  using SampleApp.Service.Interfaces;

7:

   8:  namespace SampleApp.Service

   9:  {

  10:      public class BaseService<T> : IBaseService<T> where T : class

  11:      {

  12:          IUnitOfWork unitOfWork = new SampleDataContext();

  13:          IBaseRepository<T> _repository;

14:

  15:          public BaseService()

  16:          {

  17:              _repository = new BaseRepository<T>(unitOfWork);

  18:          }

19:

  20:          public T Find(int id)

  21:          {

  22:              return _repository.Find(id);

  23:          }

24:

  25:          public IQueryable<T> List()

  26:          {

  27:              return _repository.List();

  28:          }

29:

  30:          public void Add(T item)

  31:          {

  32:              _repository.Add(item);

  33:              unitOfWork.Save();

  34:          }

35:

  36:          public void Remove(T item)

  37:          {

  38:              _repository.Remove(item);

  39:              unitOfWork.Save();

  40:          }

41:

  42:          public void Edit(T item)

  43:          {

  44:              _repository.Edit(item);

  45:              unitOfWork.Save();

  46:          }

47:

  48:          public void Dispose()

  49:          {

  50:              _repository.Dispose();

  51:          }

  52:      }

  53:  }

BaseService.cs

Com o serviço base criado, basta criar os outros serviços herdando deste serviço base e implementar os métodos adicionais necessários.

Nos exemplos abaixo, criei um método Validate(T item) para exemplificar a criação de métodos adicionais. Na maioria das vezes este método verifica se o item já está cadastrado.

   1:  using System;

   2:  using SampleApp.Domain.Entities;

3:

   4:  namespace SampleApp.Service.Interfaces

   5:  {

   6:      public interface IRoleService : IBaseService<Role>, IDisposable

   7:      {

   8:          bool Validate(Role role);

   9:      }

  10:  }

IRoleService.cs

   1:  using System.Linq;

   2:  using System.Web.Mvc;

   3:  using SampleApp.Domain.Entities;

   4:  using SampleApp.Service.Interfaces;

5:

   6:  namespace SampleApp.Service

   7:  {

   8:      public class RoleService : BaseService<Role>, IRoleService

   9:      {

  10:          private ModelStateDictionary _modelState;

11:

  12:          public RoleService(ModelStateDictionary modelState)

  13:          {

  14:              _modelState = modelState;

  15:          }

16:

  17:          public bool Validate(Role item)

  18:          {

  19:              if (item.Id == 0)

  20:              {

  21:                  if (this.List().Where(c => c.Name == item.Name).Count() > 0)

  22:                      _modelState.AddModelError("Name", "Perfil já cadastrado");

  23:              }

24:

  25:              return _modelState.IsValid;

  26:          }

  27:      }

  28:  }

RoleService.cs

Os demais serviços podem ser vistos no código fonte, que pode ser baixado no fim do artigos.

8. Integrando com ASP.NET MVC

A integração com o ASP.NET MVC é tranquila, abaixo está o código do controller RoleController.cs. Escolhi este controller pois o Role pertence à uma Application, e sendo assim, será necessário ter um DropDownList para escolher a aplicação, na criação do perfil.

Os outros controllers estão no source.

   1:  using System.Data.Entity;

   2:  using System.Linq;

   3:  using System.Web.Mvc;

   4:  using SampleApp.Domain.Entities;

   5:  using SampleApp.Service;

   6:  using SampleApp.Service.Interfaces;

7:

   8:  namespace SampleApp.Web.Controllers

   9:  {

  10:      public class RoleController : Controller

  11:      {

  12:          IRoleService _service;

  13:          IApplicationService _applicationService;

14:

  15:          public RoleController()

  16:          {

  17:              _service = new RoleService(this.ModelState);

  18:              _applicationService = new ApplicationService(this.ModelState);

  19:          }

20:

  21:          #region Actions

  22:          public ActionResult Index()

  23:          {

  24:              return View(

  25:                  _service.List().Include(r => r.Application));

  26:          }

27:

  28:          public ViewResult Details(int id)

  29:          {

  30:              return View(_service.List()

  31:                  .Include(r => r.Application)

  32:                  .Where(r => r.Id == id).First());

  33:          }

34:

  35:          public ActionResult Create()

  36:          {

  37:              ViewBag.ApplicationId =

  38:                  new SelectList(_applicationService.List(), "Id", "Name");

  39:              return View();

  40:          }

41:

  42:          [HttpPost]

  43:          public ActionResult Create(Role role)

  44:          {

  45:              if (_service.Validate(role))

  46:              {

  47:                  _service.Add(role);

  48:                  return RedirectToAction("Index");

  49:              }

50:

  51:              ViewBag.ApplicationId =

  52:                  new SelectList(_applicationService.List(), "Id", "Name");

  53:              return View(role);

  54:          }

55:

  56:          public ActionResult Edit(int id)

  57:          {

  58:              var role = _service.Find(id);

  59:              ViewBag.ApplicationId = new SelectList(

  60:                  _applicationService.List(), "Id", "Name", role.ApplicationId);

  61:              return View(_service.Find(id));

  62:          }

63:

  64:          [HttpPost]

  65:          public ActionResult Edit(Role role)

  66:          {

  67:              if (_service.Validate(role))

  68:              {

  69:                  _service.Edit(role);

  70:                  return RedirectToAction("Index");

  71:              }

72:

  73:              ViewBag.ApplicationId = new SelectList(

  74:                  _applicationService.List(), "Id", "Name", role.ApplicationId);

  75:              return View(role);

  76:          }

  77:          #endregion

78:

  79:          protected override void Dispose(bool disposing)

  80:          {

  81:              _service.Dispose();

  82:              base.Dispose(disposing);

  83:          }

84:

  85:      }

  86:  }

RoleController.cs

9. Conclusão

OK, eu concordo que escrevi um bocado de código, mas que isto irá salvar muitas linhas de código posteriormente.

Generalizando os repositórios e os serviços, economizamos boa parte do tempo de desenvolvimento e teste, já que a maioria das entidades possuem métodos CRUD e para muitas os métodos CRUD são tudo que elas possuem.

10. Source

EF 4.1 Generic Repository

11. Referências

Using Repository and Unit of Work patterns with Entity Framework 4.0
http://blogs.msdn.com/b/adonet/archive/2009/06/16/using-repository-and-unit-of-work-patterns-with-entity-framework-4-0.aspx
ASP.NET MVC–Validação de dados [Camada de Serviço]
http://weblogs.asp.net/andrebaltieri/archive/2011/01/08/asp-net-mvc-valida-231-227-o-de-dados-camada-de-servi-231-o.aspx

Primeiras informações sobre o ASP.NET MVC 4

2011-07-15T00:30:35Z

Introdução

Ontem foi anunciado um roadmap com as possíveis novas funcionalidades do ASP.NET MVC 4. O que acontece é que novamente o time do ASP.NET MVC quer o nosso feedback para melhorar ainda mais a ferramenta, e eu acho isto fantástico.

O roadmap completo pode ser encontrado neste endereço: http://aspnet.codeplex.com/wikipage?title=ASP.NET%20MVC%204%20RoadMap e como o próprio Phil Hack diz, nada é confirmado ainda!

Themes

Os times de ASP.NET e ASP.NET MVC conversaram e o time de ASP.NET tinha um conjunto de temas, que por sua vez não eram específicos para o ASP.NET MVC, que ocorreu na dificuldade da implementação dos temas no ASP.NET MVC. Eles estão agora trabalhando com parceiros fora da Microsoft para alcançar este objetivo.

Desenvolvimento e Deploy: A idéia é que o desenvolvimento e implantação destes temas sejam simples e fáceis.
Melhorias nas View Engines: A engine Razor e alguns Helpers do ASP.NET MVC sairam de páginas ASP.NET Web Forms. Eles pretendem continuar investindo em recursos que podem ser compartilhados entre ambas plataformas.
Ajax: Eles tem idéias para melhorar a utilização do Ajax no ASP.NET MVC. Eles já tem várias ideias em fase de desenvolvimeno para melhorar o uso do Ajax, principalmente em pontos críticos.
HTML 5, tablet e Mobile: Com o aumento da produção de aplicações web, o ASP.NET MVC não pode ficar de fora, e a idéia é que o ASP.NET MVC torne isto fácil.
Cloud ready: Possibilidade de templates prontos para o Windows Azure.

Recipes (Extensible Task-Based Tooling)

Recipes é uma novidade interessante do ASP.NET MVC 4 (Inclusive o Phil comentou isto no Blog). Algumas tarefas requerem modificações em várias sessões de uma aplicação, como por exemplo adicionar Ajax a uma Grid. Primeiro você tem que gerar as views e depois adicionar o Ajax. É exatamente aqui que os Recipes vão atuar.

O Recipe é uma caixa de diálogo (?) entregue via NuGet associada com uma UI e código para automatizar uma task específica.

Exemplos:

Ajax Grid
Implementação de autenticação baseada no OAuth
Suporte a autenticações baseadas em Claims, fornecidas pelo WIF.

Criando, Publicando e Instalando um Recipe:

Para criar um Recipe tudo que necessitaremos será uma dialog box utilizando uma API do Recipe.

Por exemplo, para aficionar um controller para uma area em um projeto ASP.NET MVC usanto um DTE, pode tomar muito tempo e exigir várias chamadas a métodos, mas com a API do recipe será concentrado e simples de usar.

A idéia é novamente trabalhar com componentização e distribuir estes pacotes sempre via NuGet.

Recipe Mockups

Abaixo um exemplo da janela de seleção dos Recipes.

Built In Recipes

Built-in recipes serão Recipes que já virão inclusos no ASP.NET MVC 4 e entre eles estão os candidatos OAuth support, Ajax grid e WIF.

Mudanças nos templates Mobile

Como comentei acima, parece que teremos suporte a aplicações Mobile no ASP.NET MVC 4. Abaixo as duas telas mostram as diferenças entre aplicações Web e Mobile rodando no browser de um dispositivo móvel.

Pelo que me parece eles utilizaram o jQuery Mobile (Biblioteca jQuery para dispositivos móveis) e incluirão um template exclusivo para este tipo de aplicação, parecido com o abaixo.

Device-Specific Views

As views agora podem ser específicas para um determinado dispositvo. Isto é legal pois imaginem um cenário onde minha aplicação web atende também meus clientes via SmartPhone, não precisaremos mais replicar a aplicação, recriando os controllers e etc, podemos definir isto nas views apenas, como mostrado abaixo:

Para isto, um novo dialog para criação de Views/Controller deve ser entregue, tendo opção de criar Views para dispositivos móveis com jQuery Mobile.

Device Switcher

O device switcher permite que o usuário seja direcionado para uma aplicação Web ou Mobile de acordo com seu browser. De nada adiantaria todos aqueles templates com jQuery se este switcher não existisse.

Neste caso não precisaremos nos preocupar, se o usuário acessar a aplicação de um dispositivo móvel, será automaticamente direcionado a area móvel do site.

Razor Helpers Support

Hoje conseguimos escrever códigos com Razor e armazenál-los em arquivos .cshtml ou .vbhtml. A idéia é que possamos criar class libraries desses códigos para reutilizá-los nas páginas.

Task e Task<T>

Chamadas assíncronas estão presentes em quase todas aplicações, já deixaram de ser novidade e passaram a ser obrigatoriedade.

As melhorias no ASP.NET MVC 4 em relação a chamadas assíncronas deve-se a implementação da funcionalidade Task (Task e Task<T>), que trazem uma boa redução de código na escrita de chamadas assíncronas.

O código abaixo é escrito em uma aplicação ASP.NET MVC 3:

   1:  public void IndexAsync(string city) {

   2:      AsyncManager.OutstandingOperations.Increment(2);

3:

   4:      NewsService newsService = new NewsService();

   5:      newsService.GetHeadlinesCompleted += (sender, e) =>

   6:      {

   7:          AsyncManager.Parameters["headlines"] = e.Value;

   8:          AsyncManager.OutstandingOperations.Decrement();

   9:      };

  10:      newsService.GetHeadlinesAsync();

11:

  12:      SportsService sportsService = new SportsService();

  13:      sportsService.GetScoresCompleted += (sender, e) =>

  14:      {

  15:          AsyncManager.Parameters["scores"] = e.Value;

  16:          AsyncManager.OutstandingOperations.Decrement();

  17:      };

  18:      sportsService.GetScoresAsync();

  19:  }

20:

  21:  public ActionResult IndexCompleted(string[] headlines, string[] scores, string[] forecast) {

  22:      return View("Common", new PortalViewModel  {

  23:          NewsHeadlines = headlines,

  24:          SportsScores = scores,

  25:      });

  26:  }

E o abaixo em um ASP.NET MVC 4:

   1:  public async Task<ActionResult> Index(string city) {

   2:      var newsService = new NewsService();

   3:      var sportsService = new SportsService();

4:

   5:      return View("Common",

   6:          new PortalViewModel {

   7:          NewsHeadlines = await newsService.GetHeadlinesAsync(),

   8:          SportsScores = await sportsService.GetScoresAsync()

   9:      });

  10:  }

Muito mais simples =)

Para isto, foi necessária a utilização do Visual Studio Async CTP.

CSS and JavaScript Bundling Integration

Esta funcionalidade combinará arquivos .css e .js em um só, reduzindo o tamanho dos mesmos, cortando espaços em branco e comentátios (minification).

Outras funcionalidades

EF Code First Data Migration – Permite mudança de versão do seu banco de dados sem perder todos os dados. (Esta é uma funcionalidade que espero com carinho)
Melhor suporte para testes funcionáis e de integração.
API baseada em WCF.
Melhorias no trabalho com Ajax =D
Suporte ao HTML 5.
Melhorias na segurança durante utilização de áreas.

Conclusão

O time do ASP.NET MVC sempre me surpreende e mais uma vez traz novidades incríveis. Mesmo sabendo que nada é oficial ainda, já fico empolgado e pensando onde implementar (Ou o que melhorar) com estas novas funcionalidades.

Podemos aguardar muito mais coisas desta plataforma que fica mais madura a cada dia que passa.

André Baltieri
MSN: andrebaltieri@hotmail.com | Twitter: @andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

ASP.NET MVC – Utilizando areas para organizar a aplicação

2011-06-15T22:32:00Z

Introdução

No post anterior (ASP.NET MVC 3 – Desenvolver ficou fácil) eu comentei sobre o uso de áreas para melhor organizar a aplicação Web (Não a solução), porém não apliquei na prática o conceito.

Um cenário comum para as áreas é um e-Commerce por exemplo, onde temos uma área para os usuários, que podem ver ou comprar os produtos e outra área administrativa, para que os funcionários cadastrem os produtos.

Não temos um limite de áreas a serem criadas, e cada área pode possuir seus próprios controllers, views, css, scripts e etc. É como se fosse uma nova aplicação, porém, reaproveitando o domínio e outras coisas compartilhadas entre os projetos.

Criando áreas

Como era de se esperar, o Visual Studio novamente dá uma “mãozinha” e permite a criação de uma nova área com poucos cliques (E claro, todo código gerado pode ser editado).

Para não tomar muito tempo, utilizarei o projeto anterior, que pode ser encontrado neste link:

Código Fonte

Com a solução carregada, clique com o botão direito do mouse sobre o projeto MvcFakeStore.Web e selecione a opção Add –> Area, como mostrado na Figura 1.

Figura 1 – Adicionando uma nova área.

Uma nova janela se abrirá, para que esta área seja nomeada. No meu exemplo utilizei o nome “Administrativo”.

Neste ponto, uma nova estrutura de pastas foi criada na aplicação, como mostrado na Figura 2.

Figura 2 – Estrutura de pastas criado para a nova área.

É importante notar que temos a mesma estrutura da pasta raiz da aplicação dentro desta área, incluindo as pastas model, Views, Shared e etc, ou seja, é como se fosse outra aplicação.

Em extra será criado um arquivo com o nome <SuaArea>AreaRegistration.cs que se encarregará de registrar a área na aplicação e fazer o mapeamento das URLs também para sua área.

Com a área criada, criarei os dois controllers (ProductController e CategoryController) novamente nesta área, e posteriormente, deixarei somente os metodos Index e Details (Listar e ver detalhes dos produtos/categoria) nos controllers da raiz da aplicação, e os métodos de criação, edição e exclusão, dentro da área administrativa.

Antes de começar, copie o arquivo _Layout.cshtml da pastas /Views/Shared para a pasta Areas/Administrativo/Views/Shared, como mostrado na Figura 3.

Figura 3 – Copia do arquivo _Layout.cshtml

Aproveite para abrir o arquivo e alterar seu cabeçalho, como mostrado na Figura 4, apenas para diferenciar as áreas.

Figura 4 – Alterando o cabeçalho da página inicial.

Feito isso, na nova área criada, repita os passos do artigo “ASP.NET MVC 3 – Desenvolver ficou fácil”, sessão “Criando os Controllers e Views com Scaffolding Templates”, porém utilizando a pasta Controllers da área “Administrativo” que acabamos de criar e também alterando o template padrão, para usar este Layout que acabamos de criar, como na Figura 5.

Figura 5 – Selecionando o template das Views.

Ao fim a estrutura do projeto deve estar similar a apresentada na Figura 6.

Figura 6 – Estrutura do projeto ao fim da criação dos controllers e views.

Decorando as Classes

Assim como fizemos no artigo anterior “ASP.NET MVC 3 – Desenvolver ficou fácil”, redecoraremos as classes, agora de acordo com suas áreas, como mostrado nas imagens abaixo:

ProductController.cs

CategoryController.cs

Voltando ao projeto inicial, removeremos os métodos de criação, exclusão e edição dos controllers, e suas respectivas Views, como mostrado nas imagens abaixo:

CategoryController.cs (Raiz do site)

ProductController.cs (Raiz do site)

Views removidas, restando apenas as necessárias.

ActionLinks para áreas diferentes

Até este ponto temos a aplicação dividida entre site e setor administrativo, para demonstrar a criação de ActionLinks entre areas, criaremos um link no _Layout.cshtml do site ligando-o com a área administrativa, como mostrado na Figura 7.

Figura 7 – ActionLink parametrizado para direcionar para um controller/action de uma área específica.

Note que simplesmente definimos um parâmetro “area” e informamo a qual área o usuário será redirecionado. Por fim como a sobrecarga do método exige um parâmetro para os Html Objects, informamos null para dar um by pass.

Controllers iguais em áreas diferentes

Em alguns casos, pode acontecer um conflito entre controllers (Caso do controller Home – Se criar outro controller Home na área Administrativa ocorrerá o erro da Figura 8.)

Figura 8 – Erro de controllers duplicados.

Para corrigir este problemas precisamos informar qual namespace do controller home principal nas definições das rotas, no arquivo Global.asax.

A Figura 9 mostra a solução para este problema.

Figura 9 – Adicionando namespaces para definir o controller a ser mapeado.

Conclusão

As áreas nos permitem uma divisão dentro das aplicações MVC, é como se tivessemos dois sites dentro de apenas um. Além disso contamos com o compartilhamento das informações entre os sites, o domínio e até o layout.

Downloads

Código Fonte

Espero que o artigo seja útil.

Até o próximo artigo!

André Baltieri
MSN: andrebaltieri@hotmail.com | Twitter: @andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET Users Group Leader
http://www.insidedotnet.com.br/

ASP.NET MVC 3 – Desenvolver ficou fácil

2011-06-14T21:58:00Z

Primeiramente, gostaria dizer que após um tempo ausente da comunidade devido a trabalho e projetos pessoais, estou de volta.

Introdução

O intúito deste post é criar uma aplicação completa com o ASP.NET MVC 3, tendo como base várias dúvidas que recebo sobre a tecnologia e também mostrar que desenvolver utilizando o ASP.NET MVC também é fácil.

Desta forma, este post exemplificará os principais pontos no desenvolvimento de uma aplicação com ASP.NET MVC 3 (Incluindo o Tools Update) e o ADO.NET Entity Framework 4.1.

Cenário de uso deste caso

Durante o desenvolvimento da aplicação, recursos de produtividade como Scaffold Templates serão apresentados, e em cenários mais complexos com repositório de dados, injeção de dependência e etc, este exemplo não funcionará 100%, tornando-se necessária a edição do código gerado pelas ferramentas.

Sendo assim, este cenário se aplicaca para casos onde temos um domínio mais simples, e não necessitamos de recursos como DI, IoC e etc.

Estruturando a aplicação

A organização de uma aplicação é indispensável, seja ela na fase de desenvolvimento ou na fase de suporte. Se tens uma aplicação bem estruturada e organizada, pode-se identificar e resolver problemas isoladamente e mais facilmente, e o mesmo vale para o desenvolvimento.

Toda esta organização começa já na criação da solução (Solution) e organização dos projetos dentro da mesma.

Particurlarmente organizo a aplicação como descrito na Figura 1 e Figura 2 abaixo, e isto varia de pessoa a pessoal e empresa a empresa.

Figura 1 – Criando uma solução em branco.

Deste modo, a solution conterá 3 projetos, sendo eles:

MvcFakeStore.Data (Adicionar pasta “Contexts”)– Class Library
MvcFakeStore.Domain (Adicionar pasta “Entities”) – Class Library
MvcFakeStore.Web – ASP.NET MVC 3 Web Application (Configurado como na Figura 3)

Ao término das adições, a solução fica como mostrado na Figura 2.

Figura 2 – Solução com projetos criados.

Figura 3 – Configurações do projeto MvcFakeStore.Web.

Uma aplicação tem várias responsabilidades e divisões. Por exemplo, o acesso à dados é uma área de responsabilidade, as regras de negócio outra, e sendo assim, possuir um projeto separado para cada uma destas áreas pode facilitar o desenvolvimento e manutenção da aplicação.

Desta forma, temos as seguintes separações:

Acesso à Dados: Representado pelo projeto MvcFakeStore.Data, que terá os contextos, inicializadores e etc.
Domínio: Representado pelo projeto MvcFakeStore.Domain, que terá as classes representando as regras de negócio da aplicação.
Interface: Representada pelo projeto MvcFakeStore.Web, que será a aplicação criada com ASP.NET MVC que o usuário acessará para manipular os dados.

Criando o Contexto

O contexto (Ou Data Context) será responsável pelo gerenciamento das sessões no banco de dados, mapeamento das tabelas para as classes e operações como leitura, escrita, alteração e exclusão de dados (Famos CRUD).

Atualmente fala-se muito sobre orientação à objetos, DDD, ORMs, mas qual a grande vantagem disso? Antes usavamos DataSets e tudo era mais simples. De fato talvez fosse mais simples, mas junto aos dados do DataSet existia um XML que descrevia o que cada campo fazia, seu tamanho e outras informações, ou seja, era um banco de dados replicado na aplicação.

Se temos todas estas definições já em nossas classes, não há esta necessidade, tornando assim objetos algo muito mais leve para se trafegar entre as camadas da aplicação. Existem outras enúmeras vantagens no uso de trafego de objetos ao invés de DataSet (ou DataTable) entre camadas, mas extenderia muito este post.

Outro ponto é a constante mudança de escopo que sofremos durante o andamento do projeto, tornando mudanças no código algo frequente, resultado de falhas na análise de requisitos.

Pensando em uma solução para este problema (Ninguém faz uma análise de requisitos perfeita), o correto é primeiramente ter um ponto único de atualização das regras de negócio no sistema, e isto é feito no domínio (Domnain), onde as classes que refletem o mundo real serão criadas. Partindo desta linha de racioncínio, temos o DDD, onde o desenvolvimento começa sempre pelo domínio (Criação das classes), e mantém o foco sempre nas regras de negócio.

Para operações no banco de dados, o uso de Stored Procedures é comum, porém as Stored Procedures também contém regras de negócio, e se dissemos que criar um único ponto de atualização (Princípio DRY), fica inviável ter que atualizar as classes da aplicação e também as Stored Procedures.

O uso de ORM se encaixa justamente neste ponto, onde teremos o mapeamento de cada tabela do banco para uma classe na aplicação e as operações CRUD sendo criadas em tempo de execução e de acordo com as regras de negócio definidas no domínio da aplicação, poupando assim tempo de desenvolvimento e foco no domínio.

Dentro deste contexto apresentado, algo que sempre preocupa um time é o “custo de desenvolvimento” (Tempo) que algo leva para ser construído. Não adiantaria também colocar todos estes pontos acima citados em prática se os mesmos tomassem um tempo que a equipe não possúi.

Mapear todas as tabelas para as classes por exemplo seria algo trabalhoso (E chato), pois teria que criar um script para gerar o banco de dados e posteriormente as classes.

Por estes motivos que temos os Frameworks ORM, que já fazem tudo isto sozinho (Mapeamento, criação de banco de dados, operações CRUS e etc.). Para este post utilizarei o Framework ORM da Microsoft, o ADO.NET Entity Framework, que se encontra na versão 4.1.

O ADO.NET Entity Framework 4.1 já se encontra disponível no gerenciador de pacotes NuGet porém se estiver utilizando o ASP.NET MVC 3 já encontrará a opção “Add Package Library Reference” no projeto.

Como descrito previamente, o contexto será alocado no projeto MvcFakeStore.Data, na pasta Contexts, então será necessário adicionar as referências ao mesmo, como na Figura 4.

Figura 4 – Adicionando um novo pacote ao projeto MvcFakeStore.Data.

Quando a janela de pacotes abrir, realize as operações como na Figura 5.

Figura 5 – Instalando o pacote Entity Framework.

Nota: É importante sempre verificar a versão do pacote que está sendo instalada, como mostrado na Figura 5.

Nota: O gerenciador de pacotes utiliza o PowerShell 2.0, caso não possua (Meu caso com Windows XP SP3), baixe-o aqui.

Windows Power Shell 2.0

O erro recebido ao instalar o pacote quando não tem o Power Shell instalado está na Figura 6.

Figura 6 –Erro ao instalar pacotes devido a falta do Windows Power Shell 2.0.

Com as referências adicionadas, criaremos duas classes:

MvcFakeStoreContext – Gerenciará o contexto da aplicação.
MvcFakeStoreContextInitializer – Gerenciará o inicio deste contexto e refletirá as atualizações do contexto no banco de dados.

A Figura 7 ilustra a classe MvcFakeStoreContext.cs.

Figura 7 – Classe MvcFakeStoreContext.cs.

Nesta classe, importamos o namespace System.Data.Entity, responsável por manipular e mapear as futuras entidades do contexto, e em seguida herdamos do objeto DbContexto, que possui por exemplo os métodos CRUD.

Precisamos agora de um inicializador, que aplicará as mudanças do contexto no banco de dados (Não queremos ficar criando scripts SQL para tudo que alterarmos no domínio).

A Figura 8 ilustra a esta classe.

Figura 8 – Classe MvcFakeStoreContextInitializer.cs.

Note que temos a herança de um objeto chamado “DropCreateDatabaseIfModelChanges” (Refazer o banco de dados se o domínio mudar), e poderiamos ter também o “DropCreateDatabaseAlways”, que re-criaria o banco toda vez que a aplicação rodasse.

Além disso, ainda podemos sobrescrever alguns métodos nesta classe, mas faremos isto depois.

Criando o Domínio

O domínio é responsável pelas regras de negócio da aplicação, que serão representadas por objetos (Classes), e farão uso dos contextos para persistirem seus estados no banco de dados.

Para simplificar este exemplo, criarei duas classes, sendo uma para persistir os produtos e outra para as categorias.

As Figuras 9 e 10 exemplificam as classes mencionadas.

Figura 9 – Classe Product.cs.

Figura 10 – Classe Category.cs.

Até o momento somente classes simples foram criadas, e por hora elas não possuem relacionamento, validação e também não estão sendo mapeadas a nenhuma tabela do banco de dados (Que não foi criado ainda).

Relacionando as classes

O próximo passo é relacionar estas classes, aplicando assim regras de negócio à elas. Exemplo:

Uma categoria pode conter muitos produtos;
Um produto possúi apenas uma categoria;

Poderiamos criar relacionamentos mais complexos, de NxN, como mostrado aqui neste post: ASP.NET MVC e EF–Relacionamento N–> N.

Para realizar estes relacionamentos é simples. Na classe Product.cs, criaremos uma propriedade do tipo inteiro, que representará o Id de uma categoria, e também criaremos um objeto do tipo Category, que representa a categoria cujo Id foi preenchido que que irá conter todos os dados (Não somente o Id) da categoria.

Da mesma forma, na categoria, teremos uma lista de produtos, que serão os produtos que pertencem a esta categoria.

Estas ligações (Objeto categoria na classe produto e lista de produtos na classe categoria) são feitas para facilitar ocarregamento e manipulação de dados no domínio, tornando possível a navegação também nos objetos filhos.

Dúvida: “Se eu tenho um objeto Nota Fiscal, que possúi 10 mil itens e cada item possúi uma composição de 10 ou mais peças, isto quer dizer que estarei carregando por volta de 100.000 objetos na memória ao carregar uma Nota Fiscal?”

Resposta: Não necessáriamente. O Entity Framework possúi métodos inteligentes para carregar dados, onde um objeto filho só é carregado quando invocado. É o que chamamos de Lazy Load. Há um tempo atrás escrevi um artigo bem robusto sobre EF para o Linha de Código, acesse-o aqui: Descubra o ADO.NET Entity Framework.

Deste modo, as classes serão modificadas como nas Figuras 11 e 12.

Figura 11 – Classe Product.cs com relacionamento para classe Category.cs.

Figura 12 – Classe Category.cs com referência a classe Product.cs.

Em adicional temos o modificador Virtual em ambas propriedades que são de tipos complexos, isto permite que o EF sobrescreva estas propridades em tempo de execução e as preencha.

Decorando as classes

No início do post falei sobre DRY (Don’t Repeate Yourself) e as validações se encaixam bem neste princípio. Quando temos a regra de negócio toda no domínio, o ideal é que a validação dos dados também esteja lá. As validações também são regras de negócio, e se estamos concetrando as regras de negócio no domínio, criá-las na interface quebraria este escopo.

O .NET Framework 4 conta com um recurso interessante, chamado de Data Annotations, que eu mostrei neste post: ASP.NET MVC–Validação de dados [Modelo].

O ato de “decorar” as classes é a aplicação de atributos que tornam as classes mais ricas, fugindo do padrão ânemico de criação de classes como quando trabalhavamos com stored procedures.

Os DataAnnotations possúem vários marcadores, porém não abordarei todos aqui. Para lista dos marcadores, consulte este post: MSDN Namespace System.ComponentModel.DataAnnotations.

Por padrão não temos referência aos DataAnnotations, então será preciso adicionar a referência ao System.ComponentModel.DataAnnotations no projeto MvcFakeStore.Domain, como mostrado na Figura 13.

Figura 13 – Adicionando referência aos DataAnnotations.

Com a referência adicionada, decore as classes como abaixo:

Figura 14 – Classe Product.cs decorada.

Figura 15 – Classe Category.cs decorada.

Note que para os campos Virtual não coloquei como requerido, pois os mesmo serão preenchidos dinamicamente e sendo assim nunca seriam válidos.

Mapeamento das classes

Com os relacionamentos feitos e as classes decoradas, precisamos “mapear” as classes, que seria relacionar cada campo dela com um campo de uma tabela no banco de dados. Mas nem banco de dados temos ainda!!!

Então deixa que o Entity Framework faz todo trabalho pra gente. Tudo que precisamos fazer é voltar ao contexto e criar os DbSets (Conjuntos de entidades) referente a cada classe que queremos persistir no banco. Simples né =)

Para isso, modifique a classe MvcFakeStoreContext.cs (Não se esqueça de adicionar a referência ao projeto MvcFakeStore.Domain, pois as entidades estão lá) como indicado na Figura 16.

Figura 16 – Adicionando os DbSets para as classes do domínio.

Por fim, para nossa classe MvcFakeStoreContextInitializer.cs (Nome pequeno né) não ficar vazia e até mesmo para exemplificar seu uso mais afundo, vamos sobrescrever o método Seed, que será resposável por alimentar a base de dados com alguma informação sempre que o banco fore recriado.

Figura 17 – Método Seed do inicializador de contextos.

Criando os Controllers e Views com Scaffolding Templates

Com o contexto e domínio criado, chega a hora de criar a interface (#TODOSCHORA). O ASP.NET MVC 3 Tools Update trouxe uma atualização incrível, onde todo código do controller e das views são criados automaticamente pelo Visual Studio, e para quem diz que tudo gerado veria uma “caixa-preta”, todo o código gerado pelos templates pode ser editado, desde o C# até o HTML com Razor;

Antes de criar os controllers e views, não se esqueça de adicionar ao projeto MvcFakeStore.Web referências aos projetos MvcFakeStore.Domain e MvcFakeStore.Data. Também será necessário dar um build na aplicação.

Com as referências adicionadas, clique com o botão direito sobre a pasta Controllers e selecione a opção Add -> Controller. A tela da Figura 18 se abrirá.

Figura 18 – Configurando o template para criação do Controller e Views do produto.

Após clicar em Add, note que vários arquivos foram gerados, sendo eles um Controller (ProductController.cs e uma view para cada Action do controller, como mostrado na Figura 19.

Figura 19 – Arquivos gerados pelo template.

Repita o passo com a classe Category, como mostrado na Figura 20.

Figura 20 – Configurando o template para a categoria.

Controller Name: Nome do controller, sempre no formato <prefixo> + Controller;
Template: Temos três opções de template, sendo elas, vazio, com métodos CRUD já feitos e baseados no Entity Framework e com os métodos CRUD vazios.
Model Class: Classe na qual as views irão se basear.
Data Context: Contexto que criamos no projeto MvcFakeStore.Data.
Views: Razor ou ASPX.

Nota: A validação já está toda feita =D

Rodando a aplicação

Antes de rodar a aplicação temos que acertar alguns pontos:

ConnectionString: Que indicará qual servidor a aplicação se conectará e criará o banco de dados (Sim, o banco será criado automaticamente).
Global.asax: É o responsável por gerenciar o ciclo de vida da aplicação, então ao iniciar a aplicação informaremos o nosso inicializador de contextos (MvcFakeStoreContextInitializer).
Links para a sessão de produtos e categorias.
Setar o projeto Web como projeto inicial.

Para adicionar a connection string, abra o arquivo Web.Config da raiz do projeto MvcFakeStore.Web (Cuidado pois temos vários arquivos web.config em outras pastas como a pasta Views. Atente-se para abrir o da raiz), e adicione a connection string abaixo:

Figura 21 – Adicionando a connection string ao arquivo Web.Config.

Note que a connection string deve ter o mesmo nome do contexto que criamos (MvcFakeStoreContext).

Para o Global.asax, adicione as referèncias aos namespaces System.Data.Entity e MvcFakeStore.Data.Contexts e no método Application_Start atribua o inicializador, como na Figura 22.

Figura 22 – Atribuindo o inicializador de contextos no Global.asax.

Para “dar um tapa” no visual, altere o título da página e crie mais dois links (Um para produto e outro para categoria) na página inicial (_Layout.cshtml), como mostrado na Figura 23.

Figura 23 – Alterando o layout inicial da aplicação.

Por fim, torne o projeto MvcFakeStore.Web como o projeto inicial da solução, como mostrado na Figura 24.

Figura 24 – Tornando o projeto MvcFakeStore.Web o projeto inicial da solução.

Depois deste passo, é só rodar a aplicação que terá este resultado:

Na página inicial temos o nome que alteramos, os links que criamos e um indicador marcando que não estmos logados na aplicação, como mostrado na Figura 25.

Figura 25 – Tela inicial.
Na página de produtos não temos nenhum produto.
Na página de categorias já temos uma categoria cadastrada, que é aquela adicionada no método Seed da classe MvcFakeStoreContextInitializer, como mostrado na Figura 26.

Figura 26 – Tela de categorias.

Autenticação e Autorização

Para finalizar com chave de ouro, como notamos, já possúimos um certo vínculo com o esquema de autenticação e autorização padrão do ASP.NET (Vide o identificador na Figura 25).

Deste modo, utilizaremos o membership do ASP.NET para autenticar e autorizar usuários na aplicação.

O primeiro passo é executar o configurador do ASP.NET, como mostrado no Figura 27.

Figura 27 – Executando o configurador do ASP.NET.

Quando o site de configuração abrir, na aba Security, clique na opção Enable Roles. Deste modo poderemos criar perfis de usuários, e é isto que faremos, criando os três perfis abaixo:

Usuário – Acesso de leitura
Funcionário – Leitura, Edição e Escrita.
Administrador – Leitura, Edição, Escrita e Exclusão.

Adicione então os três roles clicando dobre o link “Create or Manage Role”, como mostrado na Figura 28.

Figura 28 – Criação dos roles.

De volta a aba Security, criaremos três usuários para testar, como mostrado na Figura 29.

Figura 29 – Criando os usuários e atrelando-os aos perfis.

Autorizando as ações dos Controllers

Após os usuários criados, aplicaremos as ações nos controllers, tudo através de notações, legível e simples, como mostrado nas Figuras 30 e 31.

Figura 30 – Decorando o controller ProductController.cs

Note que informamos no método Authorize, os Roles separados por virgula que podem acessar aquela ação. Como o método index lista todos os produtos, não requeri nenhum tipo de autorização/autenticação á ele, permitindo que qualquer usuário o acesse.

Já para o método Delete, eu informo que somente administradores podem exlcuir um produto.

O mesmo vale para a Figura 31, que exemplifica o controller CategoryController.cs.

Figura 31 – CategoryController.cs decorado com autorizações.

Ufa, e assim termina a aplicação. Ainda tem rotas e areas, mas fica para um próximo artigo. Espero que este seja útil.

Conclusão

Em pouco tempo e com pouco conhecimento podemos criar aplicações simples e até arriscar algumas aplicações mais complexas. O ASP.NET MVC junto com o EF são muito produtivos e apesar do ASP.NET MVC gerar boa parte (Para não dizer todo) do código, temos total liberdade para alterá-lo.

Por fim, temos recursos como Membership, herdado do ASP.NET que facilitam ainda mais a nossa vida.

Downloads

Código Fonte

André Baltieri
MSN: andrebaltieri@hotmail.com | Twitter: @andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET User Group Leader
http://www.insidedotnet.com.br/

Learn MVC
http://learn-mvc.net/

ASP.NET MVC Error 404 Handling

2011-05-21T21:35:05Z

Introdução

Neste vídeo eu mostro rapidamente como podemos configurar uma aplicação para redirecionar um usuário para uma tela de erros personalizada.

Para este caso, utilizei o erro 404, mas outros erros como 505 seguem o mesmo caminho.

Acesse o vídeo no site do Learn MVC: http://learn-mvc.net/Watch/10

André Baltieri
MSN: andrebaltieri@hotmail.com | Twitter: @andrebaltieri
Blog: http://weblogs.asp.net/andrebaltieri

Inside .NET User Group Leader
http://www.insidedotnet.com.br/

Learn MVC
http://learn-mvc.net/

ASP.NET MVC e EF–Relacionamento N–> N

2011-04-23T21:20:00Z

Várias pessoas vem me perguntando sobre relacionamentos do tipo N para N com o ORM ADO.NET Entity Framework e resolvi fazer este post exemplificando dois cenários básicos de relacionamentos N para N. Criei dois cenários simples, mas a medida que dúvidas forem aparecendo, podem comentar aqui mesmo....(read more)

Deploy de aplicações ASP.NET MVC 3 (Final)

2011-04-17T19:27:00Z

Há um tempo atrás escrevi este post sobre como publicar aplicações ASP.NET MVC 3 (http://weblogs.asp.net/andrebaltieri/archive/2010/11/18/publishing-asp-net-mvc-3-rc1-applications.aspx – em inglês), e neste pequeno post irei abordar o que mudou no deploy das aplicações ASP.NET MVC 3 nesta versão final....(read more)

ASP.NET MVC Custom Binders

2011-03-29T23:40:00Z

Durante discussões com o @felipeoriani e com o @joseroberto sobre a questão de manter os controllers mais limpos (Que também foi muito bem abordada pelo @pedroreys no MVC Summit 2011), resolvi criar este post para mostrar a utilidade/utilização dos Custom Binders. Os binders são os responsáveis por preencher uma entidade apartir de uma View, e sendo assim, podemos extendê-los e criar binders customizados. Um exemplo interessante foi o que o Phil Haack fez durante o Webcamp aqui no Brasil, onde ele criou um binder customizado para valores decimais: http://haacked.com/archive/2011/03/19/fixing-binding-to-decimals.aspx ...(read more)

ASP.NET MVC Summit 2011

2011-03-27T17:35:00Z

Ontem (Sábado, 25 de Março de 2011) aconteceu o ASP.NET MVC Summit 2001, evento online que reuniu grandes feras do ASP.NET MVC para palestrar. O evento foi organizado pelo @vquaiato e pelo @vcavalcante e contou com mais de 1800 inscrições. Durante as palestras houveram picos de 200 pessoas online em cada trilha. ...(read more)