[Haftungsausschluss: Ich bin einer der Microsoft-Entwickler für MVC und Razor, daher bin ich möglicherweise etwas voreingenommen :)]
Wir haben Razor als prägnante Vorlagensprache entwickelt, die nur die minimal erforderliche Anzahl von Steuerzeichen verwendet. Ich würde sagen, dass große Teile Ihrer Ansichten mit weniger Zeichen als der gleiche Code mit der "traditionellen" WebForms-Syntax ausgedrückt werden können.
Zum Beispiel das folgende Codefragment in der ASPX-Syntax:
<% if(someCondition) { %>
<ol>
<% foreach(var item in Model) { %>
<li><%: item.ToString() %></li>
<% } %>
</ol>
<% } %>
Kann in Razor wie folgt ausgedrückt werden:
@if(someCondition) {
<ol>
@foreach(var item in Model) {
<li>@item.ToString()</li>
}
</ol>
}
Während die ASPX-Version 21 Übergangszeichen (das <%und %>) hat, hat die Razor-Version nur drei ( @)
Ich würde sagen, dass die Vorteile von Razor wie folgt sind:
- Prägnante Syntax, die der Art und Weise, wie Sie normalen C # -Code schreiben, sehr ähnlich ist (lesen Sie den folgenden aktuellen Blog-Beitrag von Phil Haack, in dem Asxp mit der Razor-Syntax verglichen wird: http://haacked.com/archive/2011/01/06/razor- syntax-quick-reference.aspx )
- Automatische HTML-Codierung der Ausgabe (die Sie vor HTML-Injection-Angriffen schützt)
- Integrierte (wenn auch nicht 100%) Validierung Ihres Markups, mit der Sie unausgeglichene Tags vermeiden können
Die seitenbezogenen Konzepte lassen sich auch leicht von dem abbilden, was Sie in ASPX haben
- Wie Sie sehen, ist Inline-Code weiterhin zulässig
- Abschnitte (die optional sein können) entsprechen Inhaltsplatzhaltern
- Layoutseiten anstelle von Masterseiten
- Die Konzepte von Voll- und Teilansichten sind gleich
@functions { ... } Blöcke statt <script runat="server"> ... </script>
Darüber hinaus verfügt Razor über eine Reihe nützlicher Konzepte, die meiner Meinung nach besser sind als die in ASPX verfügbaren:
@helper Funktionen für die einfache Erstellung von Funktionen, die Markups ausgeben@modelSchlüsselwort zum Angeben des Modelltyps Ihrer Ansicht, ohne dass eine <%@ Page ...Direktive mit dem vollständigen Klassennamen geschrieben werden muss
Ich würde gerne glauben, dass wir ein echtes Problem gelöst haben, das es Ihnen ermöglicht, einfacher prägnante und standardkonforme Ansichten zu schreiben und Ihnen gleichzeitig Möglichkeiten zur Umgestaltung des allgemeinen Codes zu bieten.
Natürlich wird nicht jeder die Syntax bevorzugen, weshalb wir auch die ASPX View Engine voll unterstützen. Darüber hinaus können Sie sich Spark und NHaml ansehen, zwei View-Engines von Drittanbietern, die eine große Community-Fangemeinde haben. Der folgende Blog-Beitrag bietet einen guten Vergleich der verschiedenen Angebote: http://blogs.msdn.com/b/coding4fun/archive/2010/10/04/10070953.aspx