ASP.Net MVC 5 – O que há de novo?

O ASP.Net MVC 5 foi anunciado no Microsoft Build Developer Conference 2013 (25/06 -28/06), onde foram também anunciadas ótimas novidades para o ASP.Net em geral em conjunto com o novo Visual Studio 2013.

ASP.Net MVC 5

ASP.NET MVC 5

One ASP.Net
Os templates de projeto ASP.Net MVC 5 integram-se em uma nova experiência de uso chamada One ASP.Net. Agora é possível customizar o template MVC e configurar o tipo de autenticação durante o processo de criação do projeto através do Wizard.
Todo projeto ASP.Net MVC 5 agora é uma Web Application padrão e não possui um próprio project GUID.

ASP.NET Identity
Os templates de projeto ASP.Net MVC 5 foram atualizados para utilizar o ASP.NET Identity para autenticação e gerenciamento das identidades.
Conheça mais sobre o ASP.Net Identity:
Introducing ASP.NET Identity – A membership system for ASP.NET applications

Bootstrap
Os templates de projeto ASP.Net MVC 5 foram atualizados para utilizar o Bootstrap, proporcionando um visual elegante e responsivo.
Conheça o Bootstrap

Authentication Filters
Authentication Filters são um novo tipo de filtro no ASP.NET MVC 5.
São executados antes dos filtros de autorização no pipeline ASP.NET MVC e permitem que você especifique uma lógica de autenticação “per-action”, “per-controller” ou globalmente para todos os controllers.

Authentication Filters processam credenciais durante um request e também podem adicionar “challenges” de autenticação em resposta à solicitações não autorizadas.

Filter Overrides
Agora é possível sobrescrever os filtros que se aplicam a uma determinada action ou controller especificando um conjunto de tipos de filtros que não devem ser executados em um determinado escopo (action ou controller).

Isso permite que sejam configurados os filtros que se aplicam globalmente, porém em seguida excluir determinados filtros globais da aplicação em actions ou controllers específicos.


Assista ao anuncio das novidades do ASP.Net feitas por Scott Hanselman

Resumo

Eu sempre considerei o ASP.Net MVC 4 uma versão excelente e completa, podemos notar que não foram anunciadas muitas novidades para a versão do ASP.Net MVC 5, afinal acredito que é difícil melhorar o que já era ótimo.

As mudanças em conjunto com o Visual Studio 2013 vão proporcionar mais facilidade e velocidade para criação de aplicações ASP.Net, as melhorias desta nova versão atendem diversas necessidades que eram contornadas de outras maneiras.

O Visual Studio 2013 com ASP.Net MVC 5 é um recente lançamento, pretendo abordar separadamente em artigos detalhados cada uma das novidades aqui listadas, continue acompanhado.

Referencias

Gostou do artigo? Compartilhe e deixe seu comentário abaixo 😉

ASP.Net MVC – Cuidado com links de exclusão “Delete” – Pode ser uma falha de segurança

ASP.Net MVC – Ao expor informações de um banco de dados, cuidado com o link do tipo “Delete”, siga essa dica para evitar uma falha de segurança em seu site.

Vamos supor que em nosso site ASP.Net MVC possuímos uma controller “FuncionarioController”, essa controller é responsável pelos métodos de CRUD da sua entidade Funcionario relacionada ao seu banco de dados.

Como o seu ActionResult de exclusão deveria estar escrito? Vamos observar este exemplo:

// GET: /Funcionario/Delete/5

public ActionResult Delete(int id = 0)
{
   Funcionario funcionario = db.Funcionario.Find(id);

   if (funcionario == null)
   {
      return HttpNotFound();
   }

   db.Funcionario.Remove(funcionario);
   db.SaveChanges();

   return RedirectToAction("Index");
}

Algo de estranho?
Teoricamente está tudo certo, o código está validando se o ID existe mesmo e caso não exista o usuário será redirecionando para uma página de erro, assim evitando em exibir mensagens de erro do banco de dados.

Mas nesse código habita uma grande falha de segurança, o ActionResult Delete é um método Get, ou seja, pode ser chamado diretamente de uma URL. O que aconteceria se alguém mal intencionado digitasse no browser a seguinte URL:

www.meusite.com.br/Funcionario/Delete/1

Provavelmente o registro de funcionário com o ID = 1 seria excluído certo?
“Ah, mas minha aplicação requer login e senha para esse tipo de ação.”

Isso não evita de receber um ataque, imagine que um usuário mal intencionado deseja deletar um registro e envia um e-mail para um usuário desse sistema com uma imagem “para parecer inofensivo” e nessa imagem contenha um link para a URL que citamos acima. Se o usuário que recebeu o e-mail e clicou estiver conectado (logado) no sistema naquele momento já seria o suficiente para concretizar a exploração dessa falha.

DICA

Nunca escreva seus métodos Get de exclusão realizando a exclusão direta da base.
A dica completa seria:
Nunca escreva nenhum método Get realizando alteração de informações do sistema.

Como resolver?

Vamos observar uma maneira indicada para evitar a falha citada:

    // GET: /Funcionario/Delete/5

    public ActionResult Delete(int id = 0)
    {
        Funcionario funcionario = db.Funcionario.Find(id);

        if (funcionario == null)
        {
            return HttpNotFound();
        }
        return View(funcionario);
    }

    // POST: /Funcionario/Delete/5

    [HttpPost, ActionName("Delete")]
    public ActionResult DeleteConfirmed(int id)
    {
        Funcionario funcionario = db.Funcionario.Find(id);
        db.Funcionario.Remove(funcionario);
        db.SaveChanges();

        return RedirectToAction("Index");
    }

Repare que existem dois métodos ActionResult para exclusão, o método Get Delete não realiza a exclusão do registro, apenas verifica se ele existe e redireciona o usuário para uma View de visualização e confirmação de exclusão:

ASP.Net MVC Exclusão

Ao realizar a confirmação dos dados e clicar em excluir a página será submetida via Post para o método DeleteConfirmed, que é responsável pela exclusão da base de dados.

Repare no código que um método chama-se Delete (Get) e o outro DeleteConfirmed (Post), repare também que existe um atributo ActionName(“Delete”) decorando o método DeleteConfirmed, isso significa que ele pode ser chamado como Delete, isso é necessário, pois o CLR (common language runtime) do .Net requer que haja apenas um método com a mesma assinatura, como os dois métodos recebem o mesmo tipo de parâmetro não seria possível possuírem o mesmo nome.

Utilizando o atributo ActionName(“Delete”)  faz que o roteamento do site aceite o método DeleteConfirmed como Delete quando uma URL que inclua o /Delete/ for acionada via Post.

Resumo

Essa técnica evita que de forma indesejável um registro seja manipulado e por mais que haja sucesso na tentativa do usuário mal intencionado o site resultará em uma página de confirmação, logo o usuário logado poderá intervir a essa tentativa de burlar o sistema.

Todas as controllers criadas automaticamente em projetos no Visual Studio, seja na criação do projeto ou via scaffolding já preveem essa técnica, caso você esteja criando suas controllers manualmente, lembre-se dessa dica 😉

Referência

Gostou do artigo, teve alguma dúvida? Deixe sua mensagem nos comentários abaixo.

ASP.Net MVC – ViewData, ViewBag e TempData

ASP.Net MVC – ViewData, ViewBag e TempData entenda as diferenças.

Quando usar ViewData, ViewBag e TempData? Essa é uma das primeiras perguntas que qualquer desenvolvedor faz quando inicia nos aprendizados do ASP.Net MVC.

UPDATE – 13/06 – Adicionando detalhes/correções fornecidos pelo @vcavalcante

Vamos basear nossa explicação conforme a ilustração

ViewData, ViewBag, TempData

Similaridades entre ViewData e ViewBag

ViewData e ViewBag são similares nas seguintes características:

  • São utilizadas para persistir dados entre a Controller e a View correspondente.
  • A duração “tempo de vida” é apenas entre o envio através da Controller e a exibição na View, depois disso tornam-se nulas novamente.
  • No caso de um redirect se tornam nulas.

Diferenças entre ViewData e ViewBag

ViewData ViewBag
É um dicionário de objetos derivado de ViewDataDictionary e é acessível utilizando strings como chaves. É uma propriedade dinâmica baseada na funcionalidade “dynamic” do C# 4.0
Requer typecasting (conversão) quando associada a tipos complexos. Não necessida de conversão para tipos complexos.

Exemplos de aplicação

Controller

public class HomeController : Controller
{
    public ActionResult Index()
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = "Eduardo Pires",
                            Idade = 31
                        };

        // Propriedades "Dinâmicas"
        ViewBag.Funcionario = func;

        // Modo tradicional
        ViewData["Funcionario"] = func;

        return View();
    }
}

View

@model ProjetoModelo.Models.Funcionario;

@{
    ViewBag.Title = "Exemplo ViewData ViewBag";

    // Necessita de TypeCasting
    var viewDataVariavel = ViewData["Funcionario"] as Funcionario;

    // Não necessita de TypeCasting
    var viewBagVariavel = ViewBag.Funcionario;
}

Resumindo, ViewData e ViewBag possuem a mesma proposta, porém o ViewBag está disponível a partir do ASP.Net MVC 3, enquanto o ViewData existe desde a primeira versão.

OBS: O ViewData é um wrapper, uma implementação do ViewBag, pois utiliza o ViewBag internamente, portanto:

// Criar o ViewBag:
ViewBag.Teste = "Eduardo";

// É o mesmo que criar um ViewData["Teste"],
// pois o ViewData é utilizado internamente. Se chamarmos:

var teste = ViewData["Teste"]; // Teremos teste = "Eduardo";

Por este motivo ViewData é mais rápido que o ViewBag, porém essa diferença de velocidade é mínima, não é necessário deixar de usar o ViewBag por este motivo.

Eu preferencialmente sempre utilizo ViewBag

TempData

  • TempData assemelha-se mais a uma sessão de servidor, porém de curta duração.
  • Possui um tempo de vida maior que o ViewBag e ViewData, o TempData perdura desde sua criação até que seja chamado, ou seja, quando houver um request da informação do TempData, ele se tornará nulo novamente.
  • Uma informação em TempData criada em um Controller persiste após um redirect entre actions (apenas um) e pode ser exibido em sequência em uma View (muito usado em tratamento de erros).
  • Caso não seja chamado o TempData pode manter o estado de seus dados até que a sessão do usuário se encerre.
  • É utilizado para compartilhar informações entre Controllers.
  • O TempData salva suas informações no SessionState do servidor.
  • Após a leitura os dados do TempData são marcados para deleção, ou seja, no final do request todos os dados marcados serão deletados.
  • É um benefício quando necessário transmitir um volume de informações entre as Controllers sem se preocupar em zerar os valores, pois o TempData automaticamente faz isso.

Exemplo de aplicação

Controller

public class HomeController : Controller
{
    [HttpPost]
    public ActionResult CriarFuncionario(Candidato cd)
    {
        // Meu dado de tipo complexo
        var func = new Funcionario
                        {
                            Nome = cd.Nome,
                            Idade = cd.Idade
                        };

        // Pertistir dados até o próximo request.
        TempData["Funcionario"] = func;

        // Redirect entre Controllers
        return RedirectToAction("CriarBeneficiosFuncionario");
    }

    [HttpGet]
    public ActionResult CriarBeneficiosFuncionario()
    {
        // Validando se está vazio
        if (TempData["Funcionario"] != null)
        {
            // Necessário TypeCasting para tipos complexos.
            var func = TempData["Funcionario"] as Funcionario;
        }

        return View();
    }
}

Neste exemplo pudermos entender que o propósito do TempData é compartilhar dados entre Controllers, portanto sua duração persiste até que a informação seja lida.
Outro detalhe é sempre checar se o TempData não está nulo.

Caso você queira manter o dado de um TempData mesmo após a leitura, basta chamar o método Keep(), assim o dado será persistido novamente até a próxima requisição.

// Mantendo o dado do TempData até a próxima leitura (requisição).
TempData.Keep("Funcionario");

// Removendo o dado do TempData desta e da próxima requisição.
TempData.Remove("Funcionario");

Recomenda-se utilizar sempre ViewBag e ViewData para transferência de dados entre Controller e View. O TempData em Views é recomendado no caso de um dado necessitar ser redirecionado entre Actions e posteriormente ser exibido numa View (ViewBag e ViewData são anulados em redirects).
Um caso comum dessa aplicação é no tratamento de erros, veja aqui um exemplo.

Espero ter esclarecido as diferenças e características de ViewData, ViewBag e TempData. Caso tenha alguma dúvida ou queira comentar algo, deixe seu recado logo abaixo 😉

Referências

ASP.Net MVC – Validando e-mail com DataAnnotations

Olá pessoal,

Recentemente passei por um problema e gostaria de compartilhar a solução neste artigo.

Irei utilizar um projeto padrão do tipo MVC 4 – Internet Application do Visual Studio, este projeto já vem por padrão com o registro de usuários e controle do login com FormsAuthentication implementado.

Neste projeto temos uma área de registro de novos usuários e irei customizar para que o nome de usuário seja um e-mail, para isso é necessário que haja a validação no momento da criação do novo usuário.

Aqui está a Model AccountModels.cs original:

using System.ComponentModel.DataAnnotations;

public class RegisterModel
{
    [Required]
    [Display(Name = "User name")]
    public string UserName { get; set; }

    [Required]
    [StringLength(100, ErrorMessage = "The {0} must be at least {2} characters long.", MinimumLength = 6)]
    [DataType(DataType.Password)]
    [Display(Name = "Password")]
    public string Password { get; set; }

    [DataType(DataType.Password)]
    [Display(Name = "Confirm password")]
    [Compare("Password", ErrorMessage = "The password and confirmation password do not match.")]
    public string ConfirmPassword { get; set; }
}

Para que haja a validação é necessário decorar a propriedade do campo usuário (UserName), caso você pesquise na internet irá encontrar várias referências orientando a fazer a validação desta forma:

    [Required]
    [Display(Name = "User name")]
    [DataType(DataType.EmailAddress, ErrorMessage = "E-mail em formato inválido.")]
    public string UserName { get; set; }

No momento do registro não irá funcionar a validação do formato de e-mail, ou seja, um usuário com nome “Teste” será registrado sem ser barrado pela validação.

Explicação:
Aparentemente seria essa a proposta do atributo DataType, mas não, o atributo DataType é usado apenas para formatação e não validação.

No .Net Framework 4.5 há um novo atributo System.ComponentModel.DataAnnotations.EmailAddressAttribute, que é um tipo de atributo utilizado justamente para validação, sua aplicação inclusive é mais fácil:

    [Required]
    [Display(Name = "User name")]
    [EmailAddress(ErrorMessage = "E-mail em formato inválido.")]
    public string UserName { get; set; }

Utilizei o parâmetro ErrorMessage para definir a frase de erro a ser exibida, em outros casos basta usar o parâmetro [EmailAddress] que a validação será feita:

Lembrando que ainda existe a possibilidade de fazer a validação utilizando expressões regulares:

    [Required]
    [Display(Name = "User name")]
    [RegularExpression(@"b[A-Z0-9._%-]+@[A-Z0-9.-]+.[A-Z]{2,4}b", ErrorMessage = "E-mail em formato inválido.")]
    public string UserName { get; set; }

É isso pessoal, uma dica simples mas que pode salvar algum tempo do seu trabalho 🙂

Até a próxima.

Exame para Certificação Microsoft Grátis.

Olá pessoal, boas novas – Exame para Certificação Microsoft Grátis.

A Microsoft liberou alguns PromoCodes para a realização de exames de certificação, tratam-se dos Beta Exam Process, ou seja, os novo exames de certificação que em breve serão lançados.

A categoria é Visual Studio 2012, segue abaixo a lista dos exames:

Exame
PromoCode
Expiração
71-481 – Essentials of Developing Windows Metro style Apps using HTML5 and JavaScript
FYT481
20/Agosto
71-482 – Advanced Metro style App Development using HTML5 and JavaScript
GXZ482
17/Agosto
71-483 – Programming in C#
JOK483
21/Agosto
71-484 – Essentials of Developing Windows Metro style Apps using C#
FTT484
05/Setembro
71-485 – Advanced Metro style App Development using C#
FTT485
07/Setembro
71-486 – Developing ASP.NET 4.5 MVC Web Applications
WWW486
17/Agosto
71-487 – Developing Windows Azure and Web Services
WWW487
04/Setembro

Os Exames Beta são um pouco diferentes, pois o resultado não sai na hora como um exame de certificação tradicional, normalmente a Microsoft divulga seu resultado em no máximo 30 dias.

Se passar no exame, ou seja, atingir 700 pontos ou mais, não é necessário realizar novamente o exame tradicional a certificação é dada pelos Exames Beta também.

Mais informações sobre Exames Beta em:
http://www.microsoft.com/learning/pt/br/certification/exam-dev.aspx#tab2 

É uma ótima oportunidade de colocar os novos conhecimentos em dia, dá tempo de estudar e fazer as provas.

Para agendar sua prova vá até o site http://www.register.prometric.com/ e escolha o centro de teste mais próximo a você. No momento do pagamento não precisa preencher os dados do cartão de crédito, basta clicar no botão Voucher / PromoCode e informar o código da prova escolhida.

A prova tem que ser agendada antes da data de expiração e a quantidade de exames é limitada, então corra e agende já o seu 🙂

Conselho:

  • Não marque a prova apenas para testar seu conhecimento. Estude! Como os exames são limitados dê a oportunidade de quem estudou realizar a prova.

Se você quer saber em primeira mão quando estas provas são liberadas acesse regularmente o site http://borntolearn.mslearn.net/

Boa sorte pessoal e espero que obtenham as novas certificações.

Desenvolvimento Web com .Net – MVC x WebForms

Olá pessoal, o debate MVC x WebForms se tornou muito popular e pretendo abordar o tema aqui também.

Ambas tecnologias são para desenvolvimento Web.

ASP.Net WebForms:

  • Existe desde 2001 (foi o primeiro modelo de desenvolvimento Web com .Net)
  • Tomou o lugar do ASP3 (a maioria dos sites migraram de ASP para ASP.Net)
  • É até hoje o modelo mais utilizado em desenvolvimento ASP.Net.

O WebForms facilitou muito a vida de quem trabalhava com WindowsForms ou VB6, segue o conceito de “drag and drop”, controles muito ricos como o GridView por exemplo com um simples arrastar e soltar.

O WebForms faz sozinho boa parte do trabalho de desenvolver para Web:

  • Gera HTML e JavaScript sozinho.
  • Controla o estado dos controles (postback / viewstate)
  • Os controles fazem praticamente tudo que precisa sem programação extra.

Com tudo isso temos uma boa lista de prós para o WebForms:

  • É RAD (Muito rápido de desenvolver).
  • Controles ricos.
  • HTML e JavaScript automático. “sem necessidade de programar”.
  • Gerenciamento do estado abstraído.
  • Designer Visual.

Mas também temos os contras:

  • Não se tem muito controle do HTML e JavaScript gerado.
  • Alguns controles não estão em conformidades com o W3C.
  • Difícil integração com frameworks JavaScript.
  • A UI (user interface) é quase impossível de se testar.
  • Problemas para utilizar SEO
* Muitas melhorias ocorreram na versão 4.0 do WebForms.

Para entendermos melhor as diferenças vamos fazer uma comparação.

ASP.Net MVC:

  • Segue o padrão arquitetônico de Model View Controller.
  • Faz separação de responsabilidades (cada letra de MVC com a sua).

Para esclarecer, o conceito do MVC não foi criado pela Microsoft (foi pela Xerox em meados de 70), porém foi muito bem adotado e revitalizado.

Quais os prós de se usar MVC:

  • Separação de responsabilidades (cada camada com a sua).
  • Testabilidade.
  • Reusabilidade.
  • Escalabilidade.
  • Manutenção facilitada.
  • Total controle do HTML e JavaScript gerado.
  • Suporta TDD em todos os apectos.

Muito bom né? Agora vamos aos contras:

  • Não é tão RAD quanto o WebForms.
  • Não disponibiliza controle prontos “drag and drop” (mas existem muitos free).
  • A curva de aprendizado é maior, há mais coisas para aprender.
  • Mais coisas para controlar, por ex, sessão de usuário.
  • É necessário desenvolver mais código.

Certo, já deu para balancear?
O que o MVC tem em comum com WebForms:

  • Ambos são ASP.Net (rodam sob o mesmo runtime).
  • Geram páginas ASPX.
  • Rodam no IIS.
  • Acessam dados livremente (ADO.Net, LINQ, Entity Framework).
  • São desenvolvidos no Visual Studio (para MVC é necessário baixar um complemento dependendo da versão do Visual Studio).

Acredito que com base nesses conceitos e diferenças já dá para ter uma ideia de qual abordagem é mais indicada para determinados projetos.

Muitos estão afirmando que o WebForms virou o ASP3 (clássico) ou seja está caindo em desuso. “Quando muitos gurus da tecnologia começam a fazer esse tipo de afirmação a tendência é que se torne uma verdade.”

Afinal qual dos dois escolher para meu próximo sistema Web?

Desenvolver um sistema Web, ASP.Net, desenvolvido em WebForms, na maioria das vezes pode (e vai) atender meu cliente, o que me motiva escolher MVC já que o esforço de desenvolvimento é maior?

As maiores vantagens são:

  • Controle total do HTML e JavaScript gerado.
    Seu site não vai ter o CSS quebrado ou uma função JS desconhecida gerada pelo   ASP.Net. Além de facilitar a compatibilidade com os browsers.
  • Possibilidade de testar a UI
    No WebForms isso é quase impossível, uma vez que não conhecemos o código que ele irá gerar. Para quem usa TDD é essencial ter todas as camadas testadas.
  • Reaproveitamento de código
    O código que é gerado com MVC é seu, você o conhece e o reaproveita onde quiser.
  • Aperfeiçoamento no conhecimento de CSS, HTML e JavaScript.
    Essas tecnologias por mais que bem conhecidas estão em alta, novidades como Windows 8, HTML 5 e o conceito da “Nova Web” são baseadas no uso destes conhecimentos, não dá mais para deixar de lado.

Até então todos desenvolvedores ASP.Net eram adeptos ao WebForms, logo nem sempre encontramos profissionais experientes em MVC (que já está na versão 4).

Cenário:
Você tem um projeto de um sistema web para fazer, o prazo é curto, o sistema não exige uma interface rica e customizada (ainda mais se for uma intranet) e sua equipe não tem conhecimento de MVC, vá de WebForms, não é nesse momento que deverá colocar em prática o aprendizado do MVC.

Eu mesmo gosto do WebForms (assim como já gostei muito de ASP3), trabalhei anos com ele, migrei para o MVC e aos poucos estou convertendo projetos para essa tecnologia.

Minha dica é:
Aprenda! Não deixe de aprender, experimente fazer um projeto em MVC, com o tempo e conhecimento a produtividade volta ao normal, e mais, você se manterá atualizado (MVC já é um pré-requisito para muitas vagas de desenvolvimento).

Por hoje é isso…
Pretendo continuar esse assunto abordando um novo conceito, chamado até então de “Nova Web”. Aguardem.

Quer compartilhar sua experiência? Tirar dúvidas? Utilize os comentários 😉

Referências: