ASP.NET MVC Zobacz porównanie silnika

Szukałem w SO i Google podziału różnych silników widokowych dostępnych dla ASP.NET MVC, ale nie znalazłem nic więcej niż proste opisy wysokiego poziomu tego, czym jest silnik widoku.

Niekoniecznie szukam „najlepszego” lub „najszybszego”, ale raczej kilka porównań rzeczywistych zalet / wad głównych graczy (np. Domyślnego WebFormViewEngine, silników widoku MvcContrib itp.) Dla różnych sytuacji. Myślę, że byłoby to bardzo pomocne w ustaleniu, czy przejście z domyślnego silnika byłoby korzystne dla danego projektu lub grupy programistycznej.

Czy ktoś napotkał takie porównanie?

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:

• Wydanie 0.9.1.0 NDjango wydaje się być bardziej stabilne pod wpływem stresu niż WebFormViewEngine
• Edytor szablonów Django z kolorowaniem składni, uzupełnianiem kodu i diagnostyką podczas pisania (tylko VS2010)
• Zintegrowany z platformami ASP.NET, Castle MonoRail i Bistro MVC

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

Mój obecny wybór to Razor. Jest bardzo czysty i czytelny, a strony przeglądania bardzo łatwe w utrzymaniu. Istnieje również wsparcie intellisense, które jest naprawdę świetne. ALos, w połączeniu z pomocnikami internetowymi, jest też naprawdę potężny.

Aby podać prostą próbkę:

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

I masz to. To jest bardzo czyste i łatwe do odczytania. To prawda, że ​​jest to prosty przykład, ale nawet na skomplikowanych stronach i formularzach jest nadal bardzo łatwy do odczytania i zrozumienia.

Co do wad? Jak do tej pory (jestem w tym nowy) przy korzystaniu z niektórych pomocników do formularzy brakuje wsparcia dla dodawania odwołania do klasy CSS, co jest nieco denerwujące.

Dzięki Nathj07

Wiem, że tak naprawdę nie odpowiada na twoje pytanie, ale różne silniki widokowe mają różne cele. Na przykład silnik Spark View Engine ma na celu usunięcie twoich poglądów na temat „zupy tagowej”, starając się, aby wszystko było płynne i czytelne.

Najlepiej byłoby po prostu spojrzeć na niektóre implementacje. Jeśli wygląda to atrakcyjnie dla intencji twojego rozwiązania, wypróbuj to. Możesz mieszać i dopasowywać silniki widoku w MVC, więc nie powinno to stanowić problemu, jeśli zdecydujesz się nie używać określonego silnika.

Sprawdź to SharpDOM . Jest to wewnętrzny dsl ac # 4.0 do generowania html, a także silnik widoku asp.net mvc.

Lubię ndjango . Jest bardzo łatwy w użyciu i bardzo elastyczny. Możesz łatwo rozszerzyć funkcjonalność widoku o niestandardowe tagi i filtry. Myślę, że „bardzo związany z F #” jest raczej zaletą niż wadą.

Myślę, że ta lista powinna również zawierać próbki każdego silnika przeglądania, aby użytkownicy mogli poznać smak każdego z nich bez konieczności odwiedzania każdej witryny.

Zdjęcia mówią tysiąc słów, a próbki znaczników są jak zrzuty ekranu dla przeglądarek :) Więc oto jeden z moich ulubionych Spark View Engine

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