ASP.NET MVC-Ansicht-Engine-Vergleich

Question

Ich habe SO & Google-Suche auf eine Aufschlüsselung der verschiedenen Ansicht Engines für ASP.NET MVC, aber nicht viel mehr als eine einfache High-Level-Beschreibungen von dem, was eine Ansicht Motor gefunden.

Ich bin nicht unbedingt für „besten“ suchen oder „schnellsten“, sondern einige reale Welt Vergleiche Vorteile / Nachteile der wichtigsten Akteure (zum Beispiel der Standard WebFormViewEngine, MvcContrib Ansicht Motor, etc.) für verschiedene Situationen. Ich denke, das wäre wirklich hilfreich bei der Bestimmung, ob aus der Standard-Motorschalt vorteilhaft für ein bestimmtes Projekt oder Entwicklungsgruppe sein würde.

Hat jemand einen solchen Vergleich anzutreffen?

Answer 1

ASP.NET MVC-Ansicht Engines (Community Wiki)

Da eine umfassende Liste nicht zu existieren scheinen, lassen Sie sich einen Start hier auf SO. Dies kann auf die ASP.NET MVC Gemeinschaft von großem Wert sein, wenn die Menschen ihre Erfahrung hinzufügen (insb. Jeder, der zu einer von diesen beigetragen). Alles, was die Umsetzung IViewEngine (z VirtualPathProviderViewEngine) ist faires Spiel hier. Nur neue Ansicht Engines alphabetize (WebFormViewEngine und Razor an der Spitze zu verlassen), und versucht, in Vergleichen, objektiv zu sein.

---

System.Web.Mvc.WebFormViewEngine

Design Ziele:

  

Eine Ansicht Motor, der verwendet wird, eine machen   Web Forms-Seite auf die Antwort.

Vorteile:

• allgegenwärtig, da sie Schiffe mit ASP.NET MVC
• vertraute Erfahrung für ASP.NET-Entwickler
• IntelliSense
• kann jede Sprache mit einem CodeDom Anbieter wählen (zum Beispiel C #, VB.NET, F #, Boo, Nemerle)
• On-Demand-Kompilierung oder vorkompilierte Ansichten

Nachteile:

• Nutzung wird durch die Existenz von „klassischen ASP.NET“ Muster verwechselt, die nicht mehr in MVC anwenden (z Viewstate Postback)
• kann zu anti-Muster von "Tag Suppe"
beitragen
• Code-Block-Syntax und starke Typisierung kann in die Quere kommen
• IntelliSense erzwingt Stil nicht immer geeignet für Inline-Codeblöcke
• kann laut sein, wenn einfache Vorlagen entwerfen

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

Design Ziele:

Vorteile:

• Kompakt, Expressive, und Fluid
• Einfach zu erlernen
• Ist das nicht eine neue Sprache
• Hat großes Intellisense
• Einheit Prüfbar
• Ubiquitous, Schiffe mit ASP.NET MVC

Nachteile:

• Erstellt ein etwas anderes Problem von „Tag Suppe“ verwiesen oben. Wo der Server-Tags tatsächlich Struktur um Server und Nicht-Server-Code, verwirrt Razor HTML und Server-Code, reine HTML oder JS Entwicklung machte eine Herausforderung (Con Beispiel siehe # 1), wie Sie am Ende zu „entkommen“ HTML und / oder JavaScript Tags unter bestimmten sehr häufig Bedingungen.
• Schlechte Kapselung + Wiederverwendbarkeit. Es ist unpraktisch, eine Rasierklinge Vorlage zu nennen, als ob es ein normales Verfahren waren - Rasierer in der Praxis Code aufrufen, aber nicht umgekehrt, die von Code und Präsentation Mischen fördern können
• Die Syntax ist sehr html orientiert; Nicht-HTML-Inhalte zu erzeugen kann tückisch sein. Trotz dieses Datenmodell Rasiermesser ist im Wesentlichen nur String-Verkettung, so Syntax und Verschachtelung Fehler sind weder statisch noch dynamisch erkannt, obwohl VS.NET Entwurfszeit Hilfe dieses etwas abschwächt. Wartbarkeit und refactorability können aufgrund dieser leiden.
• Keine dokumentierte API http : //msdn.microsoft.com/en-us/library/system.web.razor.aspx

Con Beispiel # 1 (man beachte die Platzierung von "string [] ..."):

@{
    <h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
    foreach (var person in teamMembers)
    {
        <p>@person</p>
    }
}

---

Bellevue

Entwurfsziele:

  

  
• Respekt HTML als First-Class-Sprache im Gegensatz sie als „nur Text“ zu behandeln.
  
• Verwirren Sie nicht mit meinem HTML! Die Datenbindung Code (Bellevue-Code) sollte von HTML getrennt sein.
  
• Erzwingen strenge Model-View Trennung
  

---

Brail

Design Ziele:

  

Die Brail Ansicht Motor portiert wurde   von Monorail mit der Arbeit   Microsoft ASP.NET MVC Framework.Zum   eine Einführung in Brail finden Sie in der   Dokumentation der Castle Projekt rel="noreferrer"> .

Vorteile:

• nach dem Vorbild "wrist freundlichen Python Syntax"
• On-Demand-kompilierten Ansichten (aber kein Precompilieren verfügbar)

Nachteile:

• entworfen in der Sprache geschrieben werden Boo

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 VB.NET XML-Literale anstelle von Strings wie die meisten anderen Ansicht Motoren.

Vorteile:

• Übersetzen Zeit der gültigen XML-Überprüfung
• Syntaxcoloring
• Voll intellisense
• Zusammengestellt Ansichten
• Erweiterbarkeit mit regulären CLR Klassen, Funktionen, usw.
• Nahtlose composability und Manipulation, da es regelmäßiger VB.NET-Code
• Einheit prüfbar

Nachteile:

• Performance: Baut 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

Design Ziele:

  

NDjango ist eine Implementierung der    Django Template-Sprache auf .NET   Plattform, mit der F # -Sprache .

Vorteile:

• NDjango Release 0.9.1.0 scheint unter Stress stabiler zu sein als WebFormViewEngine
• Django Template Editor mit Syntax-Einfärbung, Code-Vervollständigung und as-you-type-Diagnose (VS2010 nur)
• Integrierte mit ASP.NET, Castle Monorail- und Bistro MVC-Frameworks

---

NHaml

Design Ziele:

  

.NET Hafen von Rails Haml Ansicht-Engine.   Aus der Haml Webseite :

     

Haml ist eine Markup-Sprache, die verwendet wird   sauber beschreiben und einfach die   XHTML von jedem Web-Dokument, ohne die   Verwendung von Inline-Code ... Haml vermeidet die   müssen explizit Codierung XHTML in   die Vorlage, weil es tatsächlich ist   eine abstrakte Beschreibung des XHTML,   mit einigem Code dynamisch zu generieren   Inhalt.

Vorteile:

• terse Struktur (d.h. D.R.Y.)
• gegliederte
• klare Struktur
• C # Intellisense (für VS2008 ohne ReSharper)

Nachteile:

• eine Abstraktion von XHTML statt Vertrautheit des Markup 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)

Design Ziele:

  

Ein Blick Motor basiert auf    NVelocity die ein NET-Port ist   des beliebten Java-Projekt    Geschwindigkeit .

Vorteile:

• leicht zu lesen / schreiben
• prägnante Ansicht Code

Nachteile:

• begrenzte Anzahl von Helfermethoden, die auf der Ansicht
• nicht automatisch von Visual Studio-Integration hat (IntelliSense, kompiliert Zeit von Ansichten überprüft 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

Design Ziele:

  

SharpTiles ist eine Teilhafen JSTL   mit Konzept hinter den Fliesen kombiniert   Rahmen (Stand Mile Stein 1).

Vorteile:

• vertraut Java-Entwickler
• XML-Stil Codeblöcke

Nachteile:

• ...

Beispiel:

<c:if test="${not fn:empty(Page.Tiles)}">
  <p class="note">
    <fmt:message key="page.tilesSupport"/>
  </p>
</c:if>

---

Spark-Ansicht-Engine

Design Ziele:

  

Die Idee ist, die HTML zu ermöglichen   dominieren die Strömung und den Code zu passen   nahtlos.

Vorteile:

• Erzeugt lesbare Vorlagen
• C # Intellisense (für VS2008 ohne ReSharper)
• SparkSense Plug-in für VS2010 (funktioniert mit ReSharper)
• bietet eine leistungsstarke Bindungen verfügen loszuwerden alle Code in Ihren Ansichten und ermöglicht es Ihnen, Ihre eigenen HTML-Tags leicht zu erfinden

Nachteile:

• Keine klare Trennung der Vorlage Logik von wörtlichen Markup (dies kann durch Namespacepräfixe gemildert 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>

---

String Ansicht Motor MVC

Design Ziele:

  

  
• Leicht. Keine Seite Klassen erstellt werden.
  
• Fast. Vorlagen werden den Antwortausgabestrom geschrieben.
  
• Cached. Vorlagen werden zwischengespeichert, sondern verwenden ein Filesystemwatcher zu erkennen   Dateiänderungen.
  
• Dynamisch. Vorlagen können im laufenden Betrieb in Code erzeugt werden.
  
• Flexible. Vorlagen können auf jeder Ebene verschachtelt werden.
  
• Im Einklang mit MVC Prinzipien. Fördert die Trennung von UI und Geschäft   Logik. Alle Daten werden erstellt vor   Zeit, und an der Vorlage weitergegeben.
  

Vorteile:

• vertraut String Java-Entwickler

Nachteile:

• simpel Vorlagensyntax mit beabsichtigtem Ausgang (zB jQuery Konflikt ) stören kann

---

Flügel Beats

  

Wing Beats ist ein internes DSL für XHTML zu schaffen. Es basiert auf F # und enthält eine ASP.NET MVC-Ansicht-Engine, kann aber auch allein für seine Fähigkeit zu schaffen XHTML verwendet werden.

Vorteile:

• Übersetzen Zeit der gültigen XML-Überprüfung
• Syntaxcoloring
• Voll intellisense
• Zusammengestellt Ansichten
• Erweiterbarkeit mit regulären CLR Klassen, Funktionen, usw.
• Nahtlose composability und Manipulation, da es regelmäßig F # Code
ist
• Einheit prüfbar

Nachteile:

• Sie nicht schreiben, wirklich HTML-Code, der aber HTML in einem DSL darstellt.

---

XsltViewEngine (MvcContrib)

Design Ziele:

  

Baut Ansichten von vertrauten XSLT

Vorteile:

• weit allgegenwärtig
• vertraut Template-Sprache für XML-Entwickler
• XML-basierte
• time-tested
• Syntax und Element Verschachtelung Fehler statisch erfaßt werden kann.

Nachteile:

• funktionale Sprache Stil macht Flusskontrolle schwer
• XSLT 2.0 ist (wahrscheinlich?) Nicht unterstützt. (XSLT 1,0 mviel weniger praktisch).

---

Answer 2

Meine heutige Wahl ist Razor. Es ist sehr sauber und leicht zu lesen und hält die Ansicht Seiten sehr leicht zu pflegen. Es gibt auch Intellisense Unterstützung, die wirklich toll ist. Alos, wenn sie mit Web-Helfer verwendet es ist wirklich zu mächtig.

ein einfaches Beispiel bieten:

@Model namespace.model
<!Doctype html>
<html>
<head>
<title>Test Razor</title>
</head>
<body>
<ul class="mainList">
@foreach(var x in ViewData.model)
{
<li>@x.PropertyName</li>
}
</ul>
</body>

Und dort haben Sie es. Das ist sehr sauber und leicht zu lesen. Zugegeben, das ist ein einfaches Beispiel, aber auch bei komplexen Seiten und bildet es immer noch sehr leicht zu lesen und zu verstehen.

Was die Nachteile? Nun so weit (ich bin neu in diesem), wenn einige der Helfer für Formulare gibt es einen Mangel an Unterstützung für das Hinzufügen einer CSS-Klasse Referenz verwendet, die ein wenig ärgerlich ist.

Danke Nathj07

Answer 3

Ich weiß, das beantwortet nicht wirklich Ihre Frage, aber unterschiedliche Ansicht Engines hat verschiedene Zwecke. Die Ansicht Motor Funken zum Beispiel zielt darauf ab, Ihre Ansichten von „Tag Suppe“ zu befreien, indem sie versuchen, alles fließend zu machen und lesbar.

Ihre beste Wette wäre, nur bei einigen Implementierungen aussehen. Wenn es um die Absicht Ihrer Lösung ansprechend aussieht, probieren Sie es aus. Sie können in MVC mischen und Motoren Ansicht Spiel, so sollte es kein Problem sein, wenn Sie nicht mit einem bestimmten Motor entscheiden zu gehen.

Answer 4

Überprüfen Sie diese SharpDOM . Dies ist eine c # 4.0 interne dsl für HTML zu erzeugen und auch asp.net MVC-Ansicht-Engine.

Answer 5

Ich mag ndjango . Es ist sehr einfach zu bedienen und sehr flexibel. Sie können ganz einfach Ansicht Funktionalität mit benutzerdefinierten Tags und Filter erweitern. Ich denke, dass „stark zu F # gebunden“ ist eher Vorteil als Nachteil.

Answer 6

Ich denke, diese Liste auch Proben jeder Ansicht-Engine enthalten sollte, so dass Benutzer einen Eindruck von jedem bekommen können, ohne jede Website besuchen zu müssen.

Bilder sagen mehr als tausend Worte und Markup-Proben sind wie Screenshots für View Motoren :) Also hier ist eine von meinem Liebling Ansicht Motor Funken

<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>