ASP.NET MVC View Engines (Community Wiki)
Ponieważ wydaje się, że wyczerpująca lista nie istnieje, zacznijmy ją tutaj na SO. Może to mieć wielką wartość dla społeczności ASP.NET MVC, jeśli ludzie dodadzą swoje wrażenia (szczególnie każdy, kto przyczynił się do jednego z nich). Cokolwiek implementujące IViewEngine(np. VirtualPathProviderViewEngine) Jest tutaj uczciwą grą. Po prostu ułóż alfabetycznie nowe silniki widoków (pozostawiając WebFormViewEngine i Razor na górze) i postaraj się być obiektywny w porównaniu.
System.Web.Mvc.WebFormViewEngine
Cele projektu:
Mechanizm wyświetlania używany do renderowania strony formularzy sieci Web w odpowiedzi.
Plusy:
- wszechobecny, ponieważ jest dostarczany z ASP.NET MVC
- znane doświadczenie dla programistów ASP.NET
- IntelliSense
- może wybrać dowolny język u dostawcy CodeDom (np. C #, VB.NET, F #, Boo, Nemerle)
- kompilacje na żądanie lub wstępnie skompilowane widoki
Cons:
- użycie jest mylone z powodu istnienia „klasycznych wzorców ASP.NET”, które nie mają już zastosowania w MVC (np. ViewState PostBack)
- może przyczynić się do anty-wzoru „zupy tag”
- może to przeszkadzać w składni bloków kodu i silnym typowaniu
- IntelliSense wymusza styl nie zawsze odpowiedni dla wbudowanych bloków kodu
- może być głośno podczas projektowania prostych szablonów
Przykład:
<%@ 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
Cele projektu:
Plusy:
- Kompaktowy, wyrazisty i płynny
- Łatwe do nauki
- To nie jest nowy język
- Ma świetne Intellisense
- Jednostka do przetestowania
- Wszechobecny, dostarczany z ASP.NET MVC
Cons:
- Tworzy nieco inny problem niż wspomniana powyżej „zupa tag”. Tam, gdzie tagi serwera faktycznie zapewniają strukturę wokół kodu serwera i kodu innego niż serwer, Razor myli kod HTML i kod serwera, co utrudnia rozwój czystego HTML lub JS (patrz Con Przykład # 1), gdy ostatecznie musisz „uciec” HTML i / lub JavaScript tagi w pewnych bardzo powszechnych warunkach.
- Słaba enkapsulacja + możliwość ponownego użycia: niepraktyczne jest wywoływanie szablonu maszynki do golenia, tak jakby to była normalna metoda - w praktyce maszynka do golenia może wywoływać kod, ale nie odwrotnie, co może zachęcać do mieszania kodu i prezentacji.
- Składnia jest bardzo zorientowana na HTML; generowanie zawartości innej niż HTML może być trudne. Mimo to model danych maszynki do golenia jest po prostu konkatenacją łańcuchów, więc błędy składniowe i zagnieżdżania nie są wykrywane ani statycznie, ani dynamicznie, chociaż czas projektowania VS.NET nieco to łagodzi. Z tego powodu może ucierpieć możliwość konserwacji i refaktowalności.
Brak udokumentowanego API , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx
Przeciw Przykład 1 (zauważ umieszczenie „string [] ...”):
@{
<h3>Team Members</h3> string[] teamMembers = {"Matt", "Joanne", "Robert"};
foreach (var person in teamMembers)
{
<p>@person</p>
}
}
Bellevue
Cele projektu:
- Szanuj HTML jako język pierwszej klasy, a nie traktuj go jako „zwykły tekst”.
- Nie zadzieraj z moim HTML! Kod powiązania danych (kod Bellevue) powinien być oddzielny od HTML.
- Wymuszaj ścisłą separację Model-View
Zwijać
Cele projektu:
Silnik widoku Brail został przeniesiony z MonoRail do pracy z Microsoft ASP.NET MVC Framework. Wprowadzenie do Braila można znaleźć w dokumentacji na stronie projektu Castle .
Plusy:
- wzorowany na „przyjaznej dla nadgarstka składni python”
- Widoki skompilowane na żądanie (ale brak wstępnej kompilacji)
Cons:
- przeznaczony do napisania w języku Boo
Przykład:
<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 używa literałów XML VB.NET zamiast ciągów znaków, jak większość innych silników widoków.
Plusy:
- Sprawdzanie poprawności XML w czasie kompilacji
- Kolorowanie składni
- Pełna inteligencja
- Skompilowane widoki
- Rozszerzalność za pomocą zwykłych klas CLR, funkcji itp
- Bezproblemowa kompozycja i manipulacja, ponieważ jest to zwykły kod VB.NET
- Jednostka do przetestowania
Cons:
- Wydajność: buduje cały DOM przed wysłaniem go do klienta.
Przykład:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
NDjango
Cele projektu:
NDjango to implementacja języka
szablonów Django na platformie .NET przy użyciu języka F # .
Plusy:
NHaml
Cele projektu:
Port .NET silnika widoku Rails Haml. Ze strony internetowej Haml :
Haml to język znaczników używany do czystego i prostego opisu XHTML dowolnego dokumentu internetowego, bez użycia wbudowanego kodu ... Haml unika potrzeby jawnego kodowania XHTML w szablonie, ponieważ jest to w rzeczywistości abstrakcyjny opis XHTML , z pewnym kodem do generowania dynamicznej treści.
Plusy:
- zwarta struktura (tj. DRY)
- dobrze wcięte
- przejrzysta struktura
- C # Intellisense (dla VS2008 bez ReSharper)
Cons:
- abstrakcja z XHTML zamiast korzystania ze znajomości znaczników
- Brak Intellisense dla VS2010
Przykład:
@type=IEnumerable<Product>
- if(model.Any())
%ul
- foreach (var p in model)
%li= p.Name
- else
%p No products available
NVelocityViewEngine (MvcContrib)
Cele projektu:
Silnik widoku oparty na
NVelocity, który jest portem .NET popularnego projektu Java
Velocity .
Plusy:
- łatwy do odczytu / zapisu
- zwięzły kod widoku
Cons:
- ograniczona liczba metod pomocniczych dostępnych w widoku
- nie ma automatycznie integracji Visual Studio (IntelliSense, sprawdzanie widoków podczas kompilacji lub refaktoryzacja)
Przykład:
#foreach ($p in $viewdata.Model)
#beforeall
<ul>
#each
<li>$p.Name</li>
#afterall
</ul>
#nodata
<p>No products available</p>
#end
SharpTiles
Cele projektu:
SharpTiles jest częściowym portem JSTL w
połączeniu z koncepcją szkieletu Tiles (od Mile stone 1).
Plusy:
- znane programistom Java
- Bloki kodu w stylu XML
Cons:
Przykład:
<c:if test="${not fn:empty(Page.Tiles)}">
<p class="note">
<fmt:message key="page.tilesSupport"/>
</p>
</c:if>
Silnik Spark View
Cele projektu:
Chodzi o to, aby umożliwić HTMLowi zdominowanie przepływu i dopasowanie kodu.
Plusy:
- Tworzy bardziej czytelne szablony
- C # Intellisense (dla VS2008 bez ReSharper)
- Wtyczka SparkSense dla VS2010 (współpracuje z ReSharper)
- Zapewnia potężną funkcję Wiązania, aby pozbyć się całego kodu w twoich widokach i pozwala łatwo wymyślić własne tagi HTML
Cons:
- Brak wyraźnego oddzielenia logiki szablonu od literalnego znacznika (można to złagodzić za pomocą prefiksów przestrzeni nazw)
Przykład:
<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 Wyświetl silnik MVC
Cele projektu:
- Lekki Żadne klasy stron nie są tworzone.
- Szybki. Szablony są zapisywane w strumieniu danych wyjściowych odpowiedzi.
- Buforowane. Szablony są buforowane, ale wykorzystują FileSystemWatcher do wykrywania zmian w plikach.
- Dynamiczny. Szablony można generować w locie w kodzie.
- Elastyczne. Szablony można zagnieżdżać na dowolnym poziomie.
- Zgodnie z zasadami MVC. Promuje rozdzielenie interfejsu użytkownika i logiki biznesowej. Wszystkie dane są tworzone z wyprzedzeniem i przekazywane do szablonu.
Plusy:
- znane programistom Java StringTemplate
Cons:
- uproszczona składnia szablonu może zakłócać zamierzone dane wyjściowe (np. konflikt jQuery )
Wing Beats
Wing Beats to wewnętrzna DSL do tworzenia XHTML. Opiera się na F # i zawiera silnik widoku ASP.NET MVC, ale można go również używać wyłącznie do tworzenia XHTML.
Plusy:
- Sprawdzanie poprawności XML w czasie kompilacji
- Kolorowanie składni
- Pełna inteligencja
- Skompilowane widoki
- Rozszerzalność za pomocą zwykłych klas CLR, funkcji itp
- Bezproblemowa kompozycja i manipulacja, ponieważ jest to zwykły kod F #
- Jednostka do przetestowania
Cons:
- Tak naprawdę nie piszesz HTML, ale kod reprezentujący HTML w DSL.
XsltViewEngine (MvcContrib)
Cele projektu:
Tworzy widoki ze znanego XSLT
Plusy:
- powszechnie wszechobecny
- znajomy język szablonów dla programistów XML
- Oparty na XML
- sprawdzony w czasie
- Błędy składni i zagnieżdżania elementów można wykryć statycznie.
Cons:
- funkcjonalny styl języka utrudnia kontrolę przepływu
- XSLT 2.0 nie jest (prawdopodobnie?) Obsługiwany. (XSLT 1.0 jest znacznie mniej praktyczny).