[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:
- 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 )
- Codificação automática de HTML de saída (que ajuda a protegê-lo de ataques de injeção de html)
- 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
@model
palavra-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