Esse é o quarto post sobre ASP.Net MVC 2 Preview 1. Os outros dois são:

1. Primeiras impressões e suporte a áreas
2. Data Annotations
3. Helpers HTML tipados

O time do ASP.Net MVC colocou mais algumas coisinhas. Os 3 tópicos acima são as grandes novidades. Há mais algumas menores.

Eles criaram um atributo chamado DefaultValueAttribute, que permite que você especifique valores default em uma ação. Assim, um método assim:

public ActionResult Index([DefaultValue(i)] id)
{
    //implementação
}

Você pode chamar ele diretamente sem o valor, por exemplo:

1. /Posts
2. /Posts/Index
3. /Posts/Index/1

Hoje isso já é possível porque a rota imlementa um valor padrão para o id:

routes.MapRoute(
    "Default",                                              // Route name
    "{controller}/{action}/{id}",                           // URL with parameters
    new { controller = "Home", action = "Index", id = "" }  // Parameter defaults

Mas agora, fica mais fácil definir isso por método. E não precisamos mais de ficar criando rotas específicas, só por que o parâmetro de um método não é chamado “id”.

E no C#4 (e imagino que no VB 10, e talvez no 9) você pode usar parâmetros opcionais. Esse método funciona da mesma forma que o anterior:

public ActionResult Index(int id = 1)
{
    //implementação
}

Outra coisa que vai deixar o código mais expressivo é a inclusão do novo atributo HttpPost. Antes você fazia assim:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Create(Post post)

Você ainda pode fazer assim, mas agora pode fazer também assim:

[HttpPost]
public ActionResult Create(Post post)

Ficou mais bonito.

Agora também é possível fazer bind de dados binários, com um array de bytes (byte[]) ou com System.Data.Linq.Binary. O MVC coloca o valor binário como string em base 64.

E basicamente é isso aí. Tem mais coisa vindo por aí. Tem um assembly de MVCFutures no Codeplex, se você quiser saber o que pode entrar na versão 2 do MVC (ou não).

Quando for sair o Preview 2 eu volto a falar do assunto. Em breve.

Esse é o terceiro post sobre ASP.Net MVC 2 Preview 1. Os outros dois são:

1. Primeiras impressões e suporte a áreas
2. Data Annotations

Neste vamos ver os helpers tipados. E esse é bem simples e rápido.

O problema:

Você escrevia a view, e sem querer digitava um nome errado de algum campo. Tudo compilava, mas você só percebia o problema em runtime. Por exemplo, escrevia:

<%= Html.TextBox("Ttulo", Model.Titulo) %>

ou

<%= Html.TextBox("Ttulo") %>

Notaram que na string está faltando um “i”? No primeiro caso, o dado é exibido corretamente, mas é postado incorretamente. No segundo, ele sequer é exibido. Você até pode pegar esse tipo de problema com um teste de interface gráfica (que você também devia estar fazendo), como os que o VSTS provê, ou um Fitnesse, mas não seria melhor se você pudesse pegar isso em compile time?

Pois bem. A solução:

Helpers tipados, baseado em lambdas e Expressions. Vivas às lambdas. Fica assim:

<%= Html.EditorFor(p => p.Titulo) %>
<%= Html.LabelFor(p => p.Titulo) %>

E adivinhem? Mesmo se estiver com erro, ainda vai compilar! Pra ter suporte à validação das views em tempo de compilação, você precisa também descarregar o projeto (veja o primeiro post da série onde fiz isso para abilitar suporte a áreas), e editar esta linha, modificando ela de false para true:

<MvcBuildViews>true</MvcBuildViews>

Só que se você fizer isso a compilação vai demorar um pouco mais. Mas é um preço a se pagar se isso é importante para você. Vejam o resultado abaixo:

Notem também que a palavra “Ttulo”, escrita errado está vermelha. Isso é o Resharper. Ou seja, você não precisa mexer no XML se estiver usando Resharper. A bolinha vermelhinha no canto inferior direito também mostra isso, e clicando nela o Resharper mostra uma lista de erros. (E, não, eu já disse que não ganho nada com o Resharper!)

Outra coisa interessante é que você pode criar seus próprios templates. no exemplo que está sendo chamado o método “Html.EditorFor”? Não é “Html.TextBoxFor”, é EditorFor. Isso significa que o próprio framework vai avaliar qual o melhor controle para exibir. Se for um booleano, por exemplo, ele exibe um checkbox. Mas você também pode controlar isso. Basta criar uma pasta chamada “EditorTemplates” e colocar a classe que fará a edição lá dentro. Assim:

Nesse caso, fiz um template para DateTime, que coloca o atributo class=”calendario”. Ficou assim:

<%@ Control Language="C#" Inherits="System.Web.Mvc.ViewUserControl" %>
<%=Html.TextBox("", String.Format("{0:d}", Model), new { Class = "calendario"} ) %>

Vejam que o id está sendo passado em branco. Depois o próprio ASP.Net MVC coloca o id correto. Super esperto. Dessa forma, todos as minhas datas estão com o atributo calendário na classe, o que permite eu ligar elas ao datepicker do jQuery.

Antes isso era feito com T4, para facilitar o trabalho, mas o T4 só gerava o código que eu esperava. Dessa forma, não há código algum, e se eu precisar manter, faço isso num lugar só. Bem melhor.

Este é o tipo de funcionalidade que vem para facilitar muito o trabalho.

Continuando a olhar o ASP.Net MVC 2 Preview 1, vou examinar agora o Data Annotations, uma novidade no ASP.Net MVC, mas que foi introduzida no .Net Framework 3.5 SP1. Já olhei outra funcionalidade da v2p1, o suporte a áreas, em um post anterior.

Os Data Annotations, ou simplesmente “anotações”, foram introduzidos no .Net Framework 3.5 SP1, principalmente por causa do Dynamic Data. Os Data Annotations são usados para realizar validação, de forma muito parecida ao do Validation Application Block (VAB) do Enterprise Library, então se você já conhece esta tecnologia e ainda não conhece os Data Annotations, vai achá-los bastante parecidos. O legal do Data Annotations é que ele é mais simples que o validation application block do Enterprise Library. O ruim é que tem menos validadores. Imagino que logo devam começar a aparecer novos validadores, se é que já não há algum projeto “Contrib” por aí.

Vejam as anotações disponíveis por enquanto (são todos os que terminam com “Attribute”, menos o “ValidationAttribute” que é a classe base abstrata):

O time do ASP.Net MVC então passou a usar os atributos de anotações para realizar a validação no ASP.Net MVC. Simples, não é? Então tudo ficou muito simples. Vou validar uma classe de Posts:

public class Post
{
    [Required]
    public int Id { get; set; }
    [Required]
    public string Corpo { get; set; }
    [Required, StringLength(50)]
    public string Titulo { get; set; }
    [Required]
    [Range(typeof(DateTime), "2000-01-01", "2100-12-31")]
    public DateTime DataDePostagem { get; set; }
} 

Na hora que recebo ela na ação:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Edit(Post post)
{
    if (!ModelState.IsValid)
        return View(post);
    _repositorio.Salvar(post);
    return RedirectToAction("Index");
}

Ao chamar o método ModelState.IsValid estarão presentes também os erros resultantes da validação feita com as anotações. Simples, não é? Vejam o resultado da validação da classe Post, quando posto dados inválidos:

Estava na hora de a Microsoft incorporar isso no .Net Framework. Seria interessante se outros frameworks se integrassem agora ao Data Annotations, como o VAB, e o NH Validator.

Ontem (30/set/2009) foi lançado o Preview 2 do ASP.Net MVC 2. Peguem ele aqui. Eu já estava com minha série do Preview 1 pronta, vou publicar o resto dela na próxima semana.

Neste sábado passado fiz a apresentação de ASP.Net MVC com o Visual Studio 2010 e .Net 4.0.

Segue abaixo a apresentação:

E os links:

1. Site do MVC no ASP.Net: www.asp.net/mvc
2. ASP.Net MVC no codeplex: aspnet.codeplex.com
3. Phil Haack: haacked.com
4. Victor Cavalcante: cavalcante.net

A Microsoft vai disponibilizar a palestra gravada para quem não pode ver lá na área de webcasts do MSDN.

Pra quem assistiu: gostaram?

A versão 1.0 do ASP.Net MVC foi lançada seis meses atrás. Todo mundo ainda está pegando o jeito do novo framework web da Microsoft, ainda está se acostumando, que eu acho que a maioria não percebeu que eles estão tão ativos no desenvolvimento do framework que já lançaram, dois meses atrás, o primeiro preview da versão 2. As coisas andam rápido, não é?

Essa história toda de versões é um pouco confusa, então vou tentar explicar um pouco para deixar claro em que pé estamos:
A versão 2.0 é a versão que virá instalada por padrão no Visual Studio 2010, segundo dizem alguns funcionários da Microsoft. Não sei se seremos capazes de trabalhar também com a versão 1.1 no Visual Studio 2010, mas imagino que sim. A versão 1.1 é absolutamente idêntica com relação a funcionalidades à versão 1.0, mudando apenas a versão do .Net Framework, que na versão 1.0 utiliza o 3.5SP1, e na versão 1.1 o 4.0 é utilizado. A versão 1.1 foi liberada para trabalhar já com o Visual Studio 2010 Beta 1, e pode ser baixada desde junho, já que o Beta 1 do VS 2010 não possuía nenhuma versão do ASP.Net MVC. O Beta 2 já vai ter uma versão dele, já no preview 2, ou seja, se tudo estiver certo, teremos o preview 2 sendo lançado entre o fim de Outubro e começo de Novembro (lançamento do Beta 2). Update: errei feio, lançado em 30 de Setembro.

Este post é o primeiro de alguns onde vou abordar o primeiro preview da versão 2 do ASP.Net MVC. Neste post vou começar falando de algo muito esperado: áreas! Mas antes disso é bom dizer que a instalação do ASP.Net MVC 2P1 é segura, e pode ser instalada lado a lado da versão 1.0. Ela também não pode ser instalada no VS 2010, só no VS 2008.

Áreas é algo muito útil, que já vinha sendo implementado por alguns componentes open source no mercado, já para a versão 1.0 no ASP.Net MVC. A Microsoft resolveu incluir isso então na v2. Basicamente, áreas suportam nativamente urls mais simpáticas, como /Area1/Controlador1, e /Area2/Controlador1, algo antes só possível de ser feito com algum hack no ASP.Net Routing.

Pra fazer uma estrutura de áreas, neste primeiro preview, você cria pelo menos dois projetos ASP.Net MVC, um é o pai, e o outro é o filho, que vai conter a área. Você pode criar quantas áreas quiser. Aqui, por exemplo, criei o pai (MVC2Application1) e dois filhos (Area1 e Area2):

Vejam que os scripts, css, views, controllers, e global.asax não estão nos projetos de área. Fiz também uma referência do projeto principal para os dois filhos.

Incluí então alguns controladores e visões. Deixei tudo muito simples, os controladores e visões são iguaizinhos nos dois projetos de área, mudando só o namespace. Vejam o controlador:

public class Controller1Controller : Controller
{
    public ActionResult Index()
    {
        return View();
    }
    public ActionResult Acao1()
    {
        return View();
    }
    public ActionResult Acao2()
    {
        return View();
    }
}

Essa é uma das views:

<%@ Page Title="" Language="C#" MasterPageFile="~/Views/Shared/Site.Master" Inherits="System.Web.Mvc.ViewPage" %>
<asp:Content ID="Content1" ContentPlaceHolderID="TitleContent" runat="server">
    Acao1
</asp:Content>
<asp:Content ID="Content2" ContentPlaceHolderID="MainContent" runat="server">
    <h2>Area1 - Acao1</h2>
    <%= Html.ActionLink("Index", "Index")%>
    <%= Html.ActionLink("Acao 2", "Acao2") %>
</asp:Content>

Sem novidades. Código padrão ASP.Net MVC. Vejam que há links entre as views, mas esses links direcionam às mesmas views.

Quero ser capaz de linkar da minha área padrão para outras, daí acrescentei o seguinte à minha view Index do projeto padrão:

<%= Html.ActionLink("Home", "Index", "Home", new { area = "Rota padrão" }, null)%><br />
<%= Html.ActionLink("Área 1", "Index", "Controller1", new { area = "Area1" }, null)%><br />
<%= Html.ActionLink("Área 2", "Index", "Controller1", new { area = "Area2" }, null)%><br />
<%= Html.ActionLink("Área 1 - Acao 1", "Acao1", "Controller1", new { area = "Area1" }, null)%><br />
<%= Html.ActionLink("Área 1 - Acao 2", "Acao1", "Controller1", new { area = "Area1" }, null)%><br />
<%= Html.ActionLink("Área 2 - Acao 1", "Acao1", "Controller1", new { area = "Area2" }, null)%><br />
<%= Html.ActionLink("Área 2 - Acao 2", "Acao2", "Controller1", new { area = "Area2" }, null)%>

Precisamos agora configurar as rotas. Precisamos informar como configurar as áres. O código vai no método RegisterRoutes, no global.asax.cs, no lugar do código anterior, você coloca esse (não precisa excluir o código de IgnoreRoute):

routes.MapAreaRoute(
    "Area2",
    "Rota area 2",
    "MinhaArea2/{controller}/{action}/{id}",
    new {controller = "Home", action = "Index", id = ""},
    new[] {"Area2.Controllers"}
    );

routes.MapAreaRoute(
    "Area1",
    "Rota area 1",
    "Area1/{controller}/{action}/{id}",
    new {controller = "Home", action = "Index", id = ""},
    new[] {"Area1.Controllers"}
    );

routes.MapAreaRoute(
    "Main",
    "Rota padrão",
    "{controller}/{action}/{id}",
    new {controller = "Home", action = "Index", id = ""},
    new[] { "Mvc2Application1.Controllers" }
    );

Dessa forma, as novas rotas ficam configuradas pra trabalhar com áreas. Vejam que para a área 1, usei a url /Area1, mas pra área 2 usei a url /MinhaArea2. O novo código utiliza um método chamado MapAreaRoute, em vez do método MapRoute que existia antes.

É importante que você coloque o mapeamento das áreas filhas antes do mapeamento padrão de rotas. O mapeamento padrão é “{controller}/{action}/{id}”, se você colocar fora de ordem, as rotas filhas nunca vão ser encontradas, já que rotas são avaliadas na ordem em que são registradas. Isso significa que se mapear primeiro a rota padrão, ao chamar /Area2/Controller1/Acao1, em vez de bater com a área correta, vai bater com a rota padrão, e mapear “Area2” como o controller, “Controller1” como ação, e “Acao1” como id.

Agora a cola final. Para tudo isso funcionar, você precisa descarregar o projeto:

Editá-lo:

E onde estava comentado, descomentar:

<!-- To enable MVC area subproject support, uncomment the following two lines:
-->
<UsingTask TaskName="Microsoft.Web.Mvc.Build.CreateAreaManifest" 
    AssemblyName="Microsoft.Web.Mvc.Build, 
    Version=2.0.0.0, Culture=neutral, 
    PublicKeyToken=31bf3856ad364e35" />
<UsingTask TaskName="Microsoft.Web.Mvc.Build.CopyAreaManifests" 
    AssemblyName="Microsoft.Web.Mvc.Build, 
    Version=2.0.0.0, Culture=neutral, 
    PublicKeyToken=31bf3856ad364e35" />

Você também precisa descomentar o seguinte xml. Se for do projeto pai, descomente esse:

<!-- If this is an area parent project, uncomment the following lines:
-->
<CreateAreaManifest AreaName="$(AssemblyName)" AreaType="Parent" 
AreaPath="$(ProjectDir)" ManifestPath="$(AreasManifestDir)" ContentFiles="@(Content)" />
<CopyAreaManifests ManifestPath="$(AreasManifestDir)" CrossCopy="false" RenameViews="true" />

Senão, descomente esse:

<!-- If this is an area child project, uncomment the following line:
-->
<CreateAreaManifest AreaName="$(AssemblyName)" AreaType="Child" 
AreaPath="$(ProjectDir)" ManifestPath="$(AreasManifestDir)" ContentFiles="@(Content)" />

Depois recarregue o projeto. Se ele perguntar como você deve recarregar o projeto, escolha recarregar normalmente.

Isso é tudo. Rode, e vai funcionar.

Vejam aqui como o método Html.ActionLink funcionou conforme o esperado, criando o link corretamente:

Aqui podemos ver dentro de uma área. O ActionLink agora aponta para a própria área, se eu não informar nenhuma. O código deste ActionLink é:

<%= Html.ActionLink("Acao 2", "Acao2") %>

Tem alguns bugzinhos, mas nada de mais, que impeça o uso. Vou reportar lá no Connect. Experimentem, está ficando bem legal. Se você quiser, também pode baixar o fonte do Preview 2 lá no Codeplex.

Neste momento, o processo de utilização de rotas está muito manual. Temos que descarregar projeto, editar o csproj, etc. Ainda que isso só seja feito uma única vez para cada rota, tenho certeza que até a versão final isso deve passar a ter um suporte melhor do Visual Studio. Outra coisa que o time está olhando é a utilização de áreas com um único projeto, sem precisar criar projetos adicionais para isso.

O que acharam?

Foi criado o fórum de ASP.Net MVC no MSDN Brasil. Com certeza isso vai ser muito legal para separar as questões pertinentes em um fórum específico.

Vão lá visitar:

http://social.msdn.microsoft.com/Forums/pt-BR/mvcpt/threads

Perguntem e ajudem a responder.

Já tem uma pergunta, e a primeira resposta (minha).

O Rob Conery, da Microsoft, e que tem atuado no ASP.Net MVC e advogado seu uso desde sempre, lançou essa, agora a pouco:

"WebForms is a lie. It’s abstraction wrapped in deception covered in lie sauce presented on a plate full of diversion and sleight of hand. Nothing you do with Webforms has anything to do with the web – you let it do the work for you.
(…) You’re working in a lie. The web is *not* stateful and works with this stuff called HTML sent across wires using another thing called HTTP (…)"

E segue explicando porque você deve usar ASP.Net MVC. (E queimar seus livros de WebForms – não brincadeira, ele não disse isso.)

O mais interessante é dizer que o Webforms é uma mentira, e fechar dizendo que quem trabalha com WF trabalha com uma mentira. Obviamente eu não concordo, mas que vai dar o que falar vai. Afinal, o cara trabalha na Microsoft… quero só ver.

O .Net Architects já debateu muito sobre ASP.Net MVC e Webforms, prós, contras, etc. Eu também já postei, uns 6 meses atrás, quando você deve usar WF ou MVC. Todo mundo já falou alguma coisa sobre isso. Mas parece que o assunto continua quente…

Aproveitando, já subi também o PPTX do webcast de introdução ao ASP.Net MVC, feito semana passada.

Está aqui:

Enjoy.

Para quem assistiu ou quiser ver o projeto do webcast ASP.Net MVC que apresentei, o download está aqui.

Os slides estão abaixo:

Os links são os seguintes:

Site do MVC no ASP.Net: http://www.asp.net/mvc
Scott Hanselman (Microsoft): http://www.hanselman.com
Scott Guthrie (Microsoft): http://weblogs.asp.net/scottgu
Phil Haack (Microsoft): http://haacked.com
Rob Conery (Microsoft): http://blog.wekeroad.com

Meu site de consultoria: http://giovannibassi.com
Meu fórum: http://forum.giggio.net

.Net Architects:
Grupo: http://dotnetarchitects.net
Online: http://tinyurl.com/DotNetArch

Para quem viu: o que você achou?

Daqui a pouco, ao meio dia de hoje (7 de Abril), vou fazer o webcast de ASP.Net MVC em N Camadas.  Vejo vocês lá.

Depois a Microsoft sempre libera o audio/video/screen share, para quem não conseguir ver agora. Vou por meus slides também no slideshare em seguida.

Na próxima terça-feira, dia 7 de Abril (em menos de uma semana), farei outro webcast de ASP.Net MVC. Desta vez o foco é mais complexo do que o que apresentei no webcast do Codificando que fizemos hoje. Não vou apresentar o ASP.Net MVC, vou assumir que quem está assistindo já o conhece. Vou mostrar uma aplicação com boa separação de responsabilidades funcionando.

Descrição do webcast:

"O ASP.Net MVC traz um novo paradigma ao desenvolvimento feito com ASP.Net. Entenda neste webcast como uma aplicação desenhada em camadas se utiliza deste novo framework para exibição e manipulação dos dados. O webcast será essencialmente prático."

Registre-se aqui.

Farei um webcast em conjunto com o Codificando.Net nesta quinta-feira, às 20 horas. O assunto será ASP.Net MVC, bem introdutório, para quem não conhece ainda.

Estou avisando em cima da hora, porque eles me convidaram ontem, e prepararam tudo rapidinho.

Além de mim terá também outro sobre ASP.Net Membership e mais um sobre SEO e .Net.

A é? Não mudou nada significativo. Mas mudou. Vou baixar por que odeio código velho.

Old news, afinal esse é o release um milhão, duzentos e cinquenta mil, e quinze do MVC… Que mais?

Bom, está na cara que a Microsoft esqueceu o que RC quer dizer. E Beta também. Estava falando sobre isso com o Victor hoje, no Beta, o software está feature complete, e não deve mais mudar. O próprio MSF diz isso. Só bugs devem ser corrigidos. Eles fizeram o Beta, aí mudou tudo para o RC1, e agora mudou de novo para o RC2. As palavras "Feature Frozen" não valem mais nada? Tenho certeza que o time do MVC está desenvolvendo com Scrum ou alguma variável de Scrum, e talvez isso esteja deixando eles mais iterativos, mas responsivos, o que é bom. Mas ignorar convenções é ruim.

Além disso, desse jeito, daqui uns meses estamos no RC15. Microsoft, para de enfiar coisas no MVC, e façam o release final!!!!! Uma das premissas do Agile é "release often", então… release!!! Um release de verdade, não quero mais releases que não são o final, não quero mais código sem suporte, peguem um conjunto de funcionalidades, testem e façam o release. Se vocês ficarem acrescentando coisas nos release candidates, essas coisas vão gerar bugs, e você vai ter que fazer outro RC para corrigir bugs. Aí vão colocar mais coisas, aí vão ter outro RC, aí vocês entraram num while (true) sem break;

"Feature Frozen", não esqueçam.

Crie interfaces explícitas, que indicam o que você quer fazer. Eu já havia falado algo parecido em "Como nomear seus objetos", e sigo no assunto.

Parece bobo, mas faz uma grande diferença. Crie nomes e parâmetros que tenham significado.

Tenho aqui um exemplo do que não fazer, e vem justamente da Microsoft. Todo mundo sabe como eu gosto do ASP.Net MVC, e o quanto eu acho que é uma evolução, mas o problema está justamente lá.

Para criar um "input select", ou seja, um dropdownlist, eu fazia inicialmente da seguinte forma, mas não funcionava:

<% =Html.DropDownList("idCategoriaSelecionada", new SelectList(Model.Categorias, "Id", "Nome", Model.CategoriaSelecionada))%>

Eu esperava uma saída assim:

<select id="idCategoriaSelecionada" name="idCategoriaSelecionada">
    <option selected="selected" value="1">Livros</option>
    <option value="2">CDs</option>
</select>

Mas recebia algo assim:

<select id="idCategoriaSelecionada" name="idCategoriaSelecionada">
    <option value="1">Livros</option>
    <option value="2">CDs</option>
</select>

Repararam que não tem nenhum item selecionado? Fui ver o construtor de SelectList, que é onde indiquei o valor que queria selecionado:

namespace System.Web.Mvc
{
    public class SelectList : MultiSelectList
    {
        //um monte de código omitido
        public SelectList(IEnumerable items, string dataValueField, string dataTextField, object selectedValue);
    }
}

Tudo certo! Eu passei o objeto categoria esperado, então ele deveria estar selecionado. Depois que eu depurei com a minha própria cópia do MVC, que eu baixei do codeplex, e pude ver o problema, é que descobri que o "object selectedValue" esperado, era na verdade o valor do objeto, e não o objeto de negócio. E era o valor no contexto do SelectList, ou seja, o valor presente na minha propriedade "Id". Ou seja, eu teria que passar "1", para ter o option com valor "1" selecionado. Mudei o código para isso:

<% =Html.DropDownList("idCategoriaSelecionada", new SelectList(Model.Categorias, "Id", "Nome", Model.CategoriaSelecionada.Id))%>

E funcionou. Falem a verdade, isso não é uma interface mentirosa? Portanto, não faça isso! Deixe que sua interface indique o que ela está fazendo, sem o usuário precisar ficar procurando na documentação para entender. Eu, o resto do mundo, e você mesmo (quando estiver depurando) agradecemos.