Czy składnia Razor zapewnia przekonującą przewagę w znacznikach interfejsu użytkownika?

Question 1

Zauważyłem, Scott Guthrie zaczyna wspominać Razor się trochę godziwej na swoim blogu, ale jestem pewien, że nie tylko, że jest to dobre dopasowanie do mojego stylu.

To prawda, że jest to dość nieznany styl dla kogoś, kto jest przyzwyczajony do „standardowego” rodzaju znaczników ASP.Net (posiadaczy miejsca na zawartość i kodu wbudowanego), ale wydaje mi się, że jest to wiele dodatkowych stron do zarządzania i mniej czytelne znaczniki.

Jakie są odczucia innych ludzi? Czy uważasz, że jest to coś, co powinno być poważnie brane pod uwagę podczas tworzenia szkieletów nowych stron MVC, czy po prostu próbuje rozwiązać problem, który nie istnieje?

Question 2

[Uwaga: jestem jednym z programistów Microsoft w MVC i Razor, więc mogę być nieco stronniczy :)]

Zaprojektowaliśmy Razor jako zwięzły język szablonów, który używa tylko minimalnej niezbędnej liczby znaków sterujących. Powiedziałbym, że duże części poglądów można wyrazić za pomocą mniejszej liczby znaków niż ten sam kod przy użyciu „tradycyjnej” składni WebForms.

Na przykład następujący fragment kodu w składni ASPX:

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

W Razor można to wyrazić następująco:

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

Chociaż wersja ASPX ma 21 znaków przejścia ( <%i %>), wersja Razor ma tylko trzy ( @)

Powiedziałbym, że zalety Razora są następujące:

Zwięzła składnia, która jest bardzo podobna do sposobu, w jaki piszesz zwykły kod C # (zapoznaj się z następującym ostatnim postem na blogu Phila Haacka porównującym Asxp ze składnią Razor: http://haacked.com/archive/2011/01/06/razor- syntax-quick-reference.aspx )
Automatyczne kodowanie HTML danych wyjściowych (które pomaga chronić Cię przed atakami iniekcji HTML)
Wbudowana (choć nie 100%) walidacja znaczników, która pomaga uniknąć niezrównoważonych tagów

Pojęcia związane ze stroną również łatwo odwzorowują to, co masz w ASPX

Jak widać, kod wbudowany jest nadal dozwolony
Sekcje (które mogą być opcjonalne) są odpowiednikami symboli zastępczych zawartości
Strony układu zamiast stron wzorcowych
Koncepcje widoków pełnych i częściowych są takie same
@functions { ... } bloki zamiast <script runat="server"> ... </script>

Ponadto Razor ma wiele przydatnych koncepcji, które powiedziałbym, że są lepsze niż to, co jest dostępne w ASPX:

@helper funkcje do naprawdę łatwego tworzenia funkcji, które emitują znaczniki
@modelsłowo kluczowe do określania typu modelu widoku bez konieczności pisania <%@ Page ...dyrektywy z pełną nazwą klasy

Chciałbym myśleć, że poradziliśmy sobie z prawdziwym problemem, który polega na umożliwieniu ci łatwiejszego pisania zwięzłych i zgodnych ze standardami widoków, jednocześnie zapewniając sposoby refaktoryzacji wspólnego kodu.

Oczywiście nie każdemu spodoba się składnia, dlatego też w pełni wspieramy silnik widoku ASPX. Ponadto możesz sprawdzić Spark i NHaml, czyli dwa silniki widoku innych firm, które cieszą się znacznym zainteresowaniem społeczności. Poniższy post na blogu zawiera dobre porównanie różnych ofert: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx

Question 3

Osobiście naprawdę doceniam zmniejszenie liczby używanych znaków ucieczki. Używanie <% %>staje się bardzo żmudne w porównaniu z @{}i nie jest tak atrakcyjne pod względem składniowym.

Co więcej, pisanie całej definicji za kodem i stronę jest uproszczone do jednej @model model.

Jak również zauważył Marcind, nie zawsze trzeba je uwzględniać runat=server.

Ogólnie rzecz biorąc, naprawdę doceniam używanie silnika Razor i uważam, że nie tylko ułatwia mi on tworzenie, ale także ułatwia czytanie kodu.