ASP.NET MVC View Engines (Community-Wiki)
Da eine umfassende Liste nicht zu existieren scheint, beginnen wir eine hier auf SO. Dies kann für die ASP.NET MVC-Community von großem Wert sein, wenn Personen ihre Erfahrungen hinzufügen (insbesondere alle, die zu einer dieser Erfahrungen beigetragen haben). Alles, was implementiert wird IViewEngine(z. B. VirtualPathProviderViewEngine), ist hier faires Spiel. Alphabetisieren Sie einfach neue View Engines (lassen Sie WebFormViewEngine und Razor oben) und versuchen Sie, bei Vergleichen objektiv zu sein.
System.Web.Mvc.WebFormViewEngine
Designziele:
Eine Ansichts-Engine, mit der eine Web Forms-Seite auf die Antwort gerendert wird.
Vorteile:
- allgegenwärtig, da es mit ASP.NET MVC geliefert wird
- vertraute Erfahrung für ASP.NET-Entwickler
- IntelliSense
- kann mit einem CodeDom-Anbieter eine beliebige Sprache auswählen (z. B. C #, VB.NET, F #, Boo, Nemerle)
- On-Demand-Kompilierung oder vorkompilierte Ansichten
Nachteile:
- Die Verwendung wird durch das Vorhandensein von "klassischen ASP.NET" -Mustern verwirrt, die in MVC nicht mehr gelten (z. B. ViewState PostBack).
- kann zum Anti-Muster von "Tag-Suppe" beitragen
- Codeblock-Syntax und starke Typisierung können im Weg stehen
- IntelliSense erzwingt einen Stil, der für Inline-Codeblöcke nicht immer geeignet ist
- kann beim Entwerfen einfacher Vorlagen verrauscht sein
Beispiel:
<%@ Control Inherits="System.Web.Mvc.ViewPage<IEnumerable<Product>>" %>
<% if(model.Any()) { %>
<ul>
<% foreach(var p in model){%>
<li><%=p.Name%></li>
<%}%>
</ul>
<%}else{%>
<p>No products available</p>
<%}%>
System.Web.Razor
Designziele:
Vorteile:
- Kompakt, ausdrucksstark und flüssig
- Leicht zu lernen
- Ist keine neue Sprache
- Hat große Intellisense
- Gerät testbar
- Allgegenwärtig, wird mit ASP.NET MVC geliefert
Nachteile:
- Erzeugt ein etwas anderes Problem als die oben genannte "Tag-Suppe". Wo die Server-Tags tatsächlich eine Struktur um Server- und Nicht-Server-Code bieten, verwechselt Razor HTML- und Server-Code, was die reine HTML- oder JS-Entwicklung schwierig macht (siehe Beispiel 1), da Sie am Ende HTML und / oder JavaScript "entkommen" müssen Tags unter bestimmten sehr häufigen Bedingungen.
- Schlechte Kapselung + Wiederverwendbarkeit: Es ist unpraktisch, eine Rasiervorlage wie eine normale Methode aufzurufen. In der Praxis kann Rasierer Code aufrufen, aber nicht umgekehrt, was das Mischen von Code und Präsentation fördern kann.
- Die Syntax ist sehr HTML-orientiert. Das Generieren von Nicht-HTML-Inhalten kann schwierig sein. Trotzdem ist das Datenmodell von razor im Wesentlichen nur eine Verkettung von Zeichenfolgen, sodass Syntax- und Verschachtelungsfehler weder statisch noch dynamisch erkannt werden, obwohl die VS.NET-Entwurfszeit dazu beiträgt, dies etwas zu mildern. Wartbarkeit und Refactorability können darunter leiden.
Keine dokumentierte API , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Con Beispiel # 1 (beachten Sie die Platzierung von "string [] ..."):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
Bellevue
Designziele:
- Respektieren Sie HTML als erstklassige Sprache, anstatt es als "nur Text" zu behandeln.
- Leg dich nicht mit meinem HTML an! Der Datenbindungscode (Bellevue-Code) sollte von HTML getrennt sein.
- Erzwingen Sie eine strikte Trennung zwischen Modell und Ansicht
Brail
Designziele:
Die Brail-Ansichts-Engine wurde von MonoRail portiert, um mit Microsoft ASP.NET MVC Framework zu arbeiten. Eine Einführung in Brail finden Sie in der Dokumentation auf der Website des Castle-Projekts .
Vorteile:
- modelliert nach "handgelenksfreundlicher Python-Syntax"
- On-Demand-kompilierte Ansichten (aber keine Vorkompilierung verfügbar)
Nachteile:
Beispiel:
<html>
<head>
<title>${title}</title>
</head>
<body>
<p>The following items are in the list:</p>
<ul><%for element in list: output "<li>${element}</li>"%></ul>
<p>I hope that you would like Brail</p>
</body>
</html>
Hasic
Hasic verwendet die XML-Literale von VB.NET anstelle von Zeichenfolgen wie die meisten anderen View Engines.
Vorteile:
- Überprüfung der Kompilierungszeit von gültigem XML
- Syntaxfärbung
- Volle Intelligenz
- Kompilierte Ansichten
- Erweiterbarkeit mit regulären CLR-Klassen, -Funktionen usw.
- Nahtlose Kompositionsfähigkeit und Manipulation, da es sich um regulären VB.NET-Code handelt
- Gerät testbar
Nachteile:
- Leistung: Erstellt das gesamte DOM, bevor es an den Client gesendet wird.
Beispiel:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
Designziele:
NDjango ist eine Implementierung der
Django-Vorlagensprache auf der .NET-Plattform unter Verwendung der F # -Sprache .
Vorteile:
NHaml
Designziele:
.NET-Port der Rails Haml-Ansichts-Engine. Von der Haml-Website :
Haml ist eine Auszeichnungssprache, mit der das XHTML eines Webdokuments ohne Verwendung von Inline-Code sauber und einfach beschrieben wird. Haml vermeidet die Notwendigkeit, XHTML explizit in die Vorlage zu codieren, da es sich tatsächlich um eine abstrakte Beschreibung des XHTML handelt mit etwas Code zum Generieren von dynamischem Inhalt.
Vorteile:
- knappe Struktur (dh trocken)
- gut eingerückt
- klare Struktur
- C # Intellisense (für VS2008 ohne ReSharper)
Nachteile:
- eine Abstraktion von XHTML, anstatt die Vertrautheit des Markups zu nutzen
- Kein Intellisense für VS2010
Beispiel:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
Designziele:
Eine View-Engine basierend auf
NVelocity , einem .NET-Port des beliebten Java-Projekts
Velocity .
Vorteile:
- leicht zu lesen / schreiben
- prägnanter Ansichtscode
Nachteile:
- begrenzte Anzahl von Hilfsmethoden in der Ansicht verfügbar
- verfügt nicht automatisch über eine Visual Studio-Integration (IntelliSense, Überprüfung von Ansichten zur Kompilierungszeit oder Refactoring)
Beispiel:
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
Designziele:
SharpTiles ist ein Teilport von JSTL,
kombiniert mit dem Konzept hinter dem Tiles-Framework (ab Mile Stone 1).
Vorteile:
- Java-Entwicklern bekannt
- Codeblöcke im XML-Stil
Nachteile:
Beispiel:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Spark View Engine
Designziele:
Die Idee ist, dass das HTML den Ablauf dominiert und der Code nahtlos passt.
Vorteile:
- Erzeugt besser lesbare Vorlagen
- C # Intellisense (für VS2008 ohne ReSharper)
- SparkSense-Plug-In für VS2010 (funktioniert mit ReSharper)
- Bietet eine leistungsstarke Bindungsfunktion , mit der Sie den gesamten Code in Ihren Ansichten entfernen und auf einfache Weise Ihre eigenen HTML-Tags erfinden können
Nachteile:
- Keine klare Trennung der Vorlagenlogik vom Literal-Markup (dies kann durch Namespace-Präfixe verringert werden).
Beispiel:
<viewdata products="IEnumerable[[Product]]"/>
<ul if="products.Any()">
<li each="var p in products">${p.Name}</li>
</ul>
<else>
<p>No products available</p>
</else>
<Form style="background-color:olive;">
<Label For="username" />
<TextBox For="username" />
<ValidationMessage For="username" Message="Please type a valid username." />
</Form>
StringTemplate View Engine MVC
Designziele:
- Leicht. Es werden keine Seitenklassen erstellt.
- Schnell. Vorlagen werden in den Antwortausgabestream geschrieben.
- Zwischengespeichert. Vorlagen werden zwischengespeichert, verwenden jedoch einen FileSystemWatcher, um Dateiänderungen zu erkennen.
- Dynamisch. Vorlagen können im laufenden Betrieb im Code generiert werden.
- Flexibel. Vorlagen können auf jeder Ebene verschachtelt werden.
- In Übereinstimmung mit den MVC-Prinzipien. Fördert die Trennung von Benutzeroberfläche und Geschäftslogik. Alle Daten werden vorab erstellt und an die Vorlage weitergegeben.
Vorteile:
- StringTemplate Java-Entwicklern vertraut
Nachteile:
- Eine vereinfachte Vorlagensyntax kann die beabsichtigte Ausgabe beeinträchtigen (z. B. jQuery-Konflikt ).
Wing Beats
Wing Beats ist ein internes DSL zum Erstellen von XHTML. Es basiert auf F # und enthält eine ASP.NET MVC-Ansichts-Engine, kann jedoch auch ausschließlich für die Erstellung von XHTML verwendet werden.
Vorteile:
- Überprüfung der Kompilierungszeit von gültigem XML
- Syntaxfärbung
- Volle Intelligenz
- Kompilierte Ansichten
- Erweiterbarkeit mit regulären CLR-Klassen, -Funktionen usw.
- Nahtlose Kompositionsfähigkeit und Manipulation, da es sich um regulären F # -Code handelt
- Gerät testbar
Nachteile:
- Sie schreiben nicht wirklich HTML, sondern Code, der HTML in einem DSL darstellt.
XsltViewEngine (MvcContrib)
Designziele:
Erstellt Ansichten aus vertrauten XSLT
Vorteile:
- weit verbreitet
- vertraute Vorlagensprache für XML-Entwickler
- XML-basiert
- erprobt
- Syntax- und Elementverschachtelungsfehler können statisch erkannt werden.
Nachteile:
- Der funktionale Sprachstil erschwert die Flusskontrolle
- XSLT 2.0 wird (wahrscheinlich?) Nicht unterstützt. (XSLT 1.0 ist viel weniger praktisch).