A sintaxe do Razor fornece uma vantagem atraente na marcação da IU?

Percebo que Scott Guthrie está começando a mencionar Razor um pouco em seu blog, mas não tenho certeza se é uma boa opção para o meu estilo.

Concedido, é um estilo bastante desconhecido para alguém que está bastante acostumado com um tipo "padrão" de marcação ASP.Net (espaços reservados para conteúdo e código embutido), mas parece que muitas páginas adicionais para gerenciar e uma marcação menos clara para mim.

Quais são os sentimentos de outras pessoas sobre isso? É algo que você acredita que deve ser considerado seriamente ao criar o scaffold de novas páginas MVC ou está apenas tentando resolver um problema que não existe?

[Aviso: Sou um dos desenvolvedores da Microsoft no MVC e Razor, então posso ser um pouco tendencioso :)]

Projetamos o Razor para ser uma linguagem de modelagem concisa que usa apenas a quantidade mínima necessária de caracteres de controle. Eu diria que grandes partes de suas visualizações podem ser expressas com menos caracteres do que o mesmo código usando a sintaxe "tradicional" de WebForms.

Por exemplo, o seguinte snippet de código na sintaxe ASPX:

<% if(someCondition) { %>
  <ol>
  <% foreach(var item in Model) { %>
     <li><%: item.ToString() %></li>
  <% } %>
  </ol>
<% } %>

Pode ser expresso da seguinte forma no Razor:

@if(someCondition) {
   <ol>
   @foreach(var item in Model) {
      <li>@item.ToString()</li>
   }
   </ol>
}

Enquanto a versão ASPX possui 21 caracteres de transição (o <%e %>), a versão Razor possui apenas três ( @)

Eu diria que as vantagens do Razor são as seguintes:

1. Sintaxe concisa, que é muito semelhante à maneira como você escreve código C # regular (verifique a seguinte postagem recente no blog de Phil Haack comparando Asxp com a sintaxe do Razor: http://haacked.com/archive/2011/01/06/razor- syntax-quick-reference.aspx )
2. Codificação automática de HTML de saída (que ajuda a protegê-lo de ataques de injeção de html)
3. Validação integrada (embora não 100%) de sua marcação, o que ajuda a evitar tags desequilibradas

Os conceitos relacionados à página também mapeiam facilmente do que você tem no ASPX

• Como você pode ver, o código embutido ainda é permitido
• As seções (que podem ser opcionais) são equivalentes a marcadores de conteúdo
• Páginas de layout em vez de páginas mestras
• Os conceitos de visualizações totais e parciais são os mesmos
• @functions { ... } blocos em vez de <script runat="server"> ... </script>

Além disso, o Razor tem uma série de conceitos úteis que eu diria que são melhores do que os disponíveis no ASPX:

• @helper funções para a criação realmente fácil de funções que emitem marcação
• @modelpalavra-chave para especificar o tipo de modelo de sua visão sem ter que escrever uma <%@ Page ...diretiva com o nome completo da classe

Eu gostaria de pensar que resolvemos um problema real, que é permitir que você escreva mais facilmente visualizações concisas e compatíveis com os padrões, ao mesmo tempo que fornece maneiras de refatorar código comum.

Claro, nem todo mundo vai preferir a sintaxe, e é por isso que também oferecemos suporte total ao mecanismo de exibição ASPX. Além disso, você pode verificar o Spark e o NHaml, que são dois mecanismos de exibição de terceiros que contam com uma comunidade significativa de seguidores. A seguinte postagem do blog tem uma boa comparação das diferentes ofertas: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx

Pessoalmente, eu realmente aprecio a redução em quantos caracteres de escape são usados. Usar <% %>torna-se muito tedioso quando comparado @{}e não é tão atraente sintaticamente.

Além disso, escrever uma definição inteira para o code-behind e a página é simplificado para um único @model model.

Como também notado por marcind, não ter que incluir sempre runat=serveré muito bom também.

No geral, eu realmente aprecio usar o mecanismo Razor e acho que ele não apenas torna as coisas mais fáceis para eu desenvolver, mas também torna o código mais fácil de ler.