Обеспечивает ли синтаксис Razor убедительное преимущество в разметке пользовательского интерфейса?

Я заметил Скотт Гатри начинает упоминать бритву на справедливый бит на своем блоге , но я просто не так уверен , что это хорошо подходит для моего стиля.

Конечно, это довольно незнакомый стиль для тех, кто привык к «стандартному» виду разметки ASP.Net (заполнители содержимого и встроенный код), но мне кажется, что для управления он требует большого количества дополнительных страниц и менее четкой разметки.

Что думают по этому поводу другие люди? Вы считаете, что это нужно серьезно учитывать при создании новых страниц MVC, или это просто попытка решить проблему, которой не существует?

[Отказ от ответственности: я один из разработчиков Microsoft по MVC и Razor, поэтому я могу быть немного предвзятым :)]

Мы разработали Razor как краткий язык шаблонов, который использует только минимально необходимое количество управляющих символов. Я бы сказал, что большие части ваших представлений могут быть выражены меньшим количеством символов, чем тот же код, с использованием «традиционного» синтаксиса WebForms.

Например, следующий фрагмент кода в синтаксисе ASPX:

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

В Razor может быть выражено следующим образом:

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

В то время как версия ASPX имеет 21 символ перехода ( <%и %>), версия Razor имеет только три ( @)

Я бы сказал, что преимущества Razor следующие:

1. Краткий синтаксис, который очень похож на то, как вы пишете обычный код C # (посмотрите следующее недавнее сообщение в блоге Фила Хаака, сравнивающее синтаксис Asxp с Razor: http://haacked.com/archive/2011/01/06/razor- syntax-quick-reference.aspx )
2. Автоматическое HTML-кодирование вывода (что помогает защитить вас от атак с использованием HTML-инъекций)
3. Встроенная (но не 100%) проверка вашей разметки, которая помогает избежать несбалансированных тегов.

Понятия, связанные со страницами, также легко сопоставляются с тем, что у вас есть в ASPX

• Как видите, встроенный код все еще разрешен
• Разделы (которые могут быть необязательными) эквивалентны заполнителям содержимого
• Страницы макета вместо мастер-страниц
• Концепции полного и частичного просмотра одинаковы
• @functions { ... } блоки вместо <script runat="server"> ... </script>

Вдобавок в Razor есть ряд полезных концепций, которые, я бы сказал, лучше, чем то, что доступно в ASPX:

• @helper функции для действительно простого создания функций, которые генерируют разметку
• @modelключевое слово для указания типа модели вашего представления без необходимости писать <%@ Page ...директиву с полным именем класса

Я хотел бы думать, что мы взялись за реальную проблему, которая заключается в том, чтобы позволить вам более легко писать краткие и соответствующие стандартам представления, в то же время предоставляя вам способы рефакторинга общего кода.

Конечно, не все предпочтут синтаксис, поэтому мы также полностью поддерживаем механизм просмотра ASPX. Кроме того, вы можете попробовать Spark и NHaml, два сторонних движка просмотра, пользующиеся большим успехом в сообществе. В следующем сообщении блога есть хорошее сравнение различных предложений: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx

Лично я очень ценю сокращение количества используемых escape-символов. Использование <% %>становится очень утомительным по сравнению с @{}синтаксически и даже близко не так привлекательно.

Более того, написание целого определения программной части и страницы упрощается до одного @model model.

Как также отметил марсинд, runat=serverтоже очень приятно не включать всегда .

В целом, я очень ценю использование движка Razor и считаю, что он не только упрощает мне разработку, но и упрощает чтение кода.