ASP.NET MVC Переглянути порівняння двигуна


339

Я шукав в SO & Google для розбиття різноманітних двигунів View, доступних для ASP.NET MVC, але не знайшов набагато більше, ніж прості описи на високому рівні того, що таке двигун перегляду.

Я не обов'язково шукаю "найкращих" чи "найшвидших", а скоріше порівняння переваг / недоліків основних гравців (наприклад, WebFormViewEngine за замовчуванням, MvcContrib View Engines тощо) для різних ситуацій. Я думаю, що це було б дуже корисно у визначенні, чи було б вимкнення двигуна за замовчуванням вигідним для певного проекту чи групи розробників.

Хтось стикався з таким порівнянням?


43
Іронічно, що це "неконструктивно", але надало велику цінність тим, хто займався, хто переглянув це майже 45 тис. Разів. Шкода, що SO обмежує власну корисність, незважаючи на потреби громади. Я сумніваюся, @ jeff-atwood почував би це так.
mckamey

Відповіді:


430

ASP.NET MVC Перегляд двигунів (Community Wiki)

Оскільки, як видається, не існує всебічного списку, почнемо його тут із ТА. Це може мати велику цінність для спільноти ASP.NET MVC, якщо люди додадуть свій досвід (особливо будь-хто, хто сприяв одному з них). Все, що реалізується IViewEngine(наприклад VirtualPathProviderViewEngine), тут є чесною грою. Просто алфавітуйте нові механізми перегляду (залишаючи WebFormViewEngine та Razor вгорі), і намагайтеся бути об'єктивними у порівняннях.


System.Web.Mvc.WebFormViewEngine

Цілі дизайну:

Механізм перегляду, який використовується для відображення сторінки веб-форм до відповіді.

Плюси:

  • всюдисущий, оскільки постачається з ASP.NET MVC
  • знайомий досвід для розробників ASP.NET
  • IntelliSense
  • Ви можете вибрати будь-яку мову у постачальника CodeDom (наприклад, C #, VB.NET, F #, Boo, Nemerle)
  • складання на замовлення або попередньо складені перегляди

Мінуси:

  • використання плутає існування "класичних шаблонів ASP.NET", які більше не застосовуються в MVC (наприклад, ViewState PostBack)
  • може внести внесок у "шаблон супу"
  • синтаксис кодового блоку та сильне введення тексту можуть перешкоджати
  • IntelliSense застосовує стиль, не завжди підходящий для блоків вбудованого коду
  • може бути галасливим при розробці простих шаблонів

Приклад:

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

Цілі дизайну:

Плюси:

  • Компактний, виразний і текучий
  • Легко вчитися
  • Це не нова мова
  • Має чудовий Intellisense
  • Підрозділ Тестувальний
  • Усюдисучий, поставляється з ASP.NET MVC

Мінуси:

  • Створює дещо іншу проблему, ніж "суп із тегів", на який згадувалося вище. Там, де теги сервера насправді забезпечують структуру навколо серверного та несерверного коду, Razor плутає HTML та код сервера, роблячи складні чисті HTML чи JS (див. Приклад № 1), оскільки в кінцевому підсумку потрібно "втекти" HTML та / або JavaScript теги за певних дуже поширених умов.
  • Погана інкапсуляція + повторне використання: Недоцільно називати шаблон бритви так, як якщо б це був звичайний метод - на практиці бритва може називати код, але не навпаки, що може заохочувати змішування коду та подання.
  • Синтаксис дуже орієнтований на html; генерування не-html-вмісту може бути складним. Незважаючи на це, модель даних бритви, по суті, є лише об'єднанням рядків, тому синтаксис та помилки введення не виявляються ні статично, ні динамічно, хоча допомога проекту VS.NET дещо пом'якшує це. Через це можуть постраждати ремонтопридатність та рефакторізація.
  • Немає документально підтвердженого API , http://msdn.microsoft.com/en-us/library/system.web.razor.aspx

Con Приклад №1 (зверніть увагу на розміщення "string [] ..."):

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

Bellevue

Цілі дизайну:

  • Поважайте HTML як першокласну мову, а не трактуйте її як "просто текст".
  • Не возиться з моїм HTML! Код прив'язки даних (код Беллева) повинен бути окремим від HTML.
  • Забезпечте суворе розділення моделей

Плетіть

Цілі дизайну:

Двигун перегляду Brail був перенесений з MonoRail для роботи з Microsoft ASP.NET MVC Framework. Для ознайомлення з Brail дивіться документацію на веб-сайті проекту Castle .

Плюси:

  • за зразком "синтаксис пітону"
  • Перегляди, складені за запитом (але попередня компіляція не доступна)

Мінуси:

  • призначений для написання мовою Boo

Приклад:

<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 використовує XML-літерали VB.NET замість рядків, як і більшість інших механізмів перегляду.

Плюси:

  • Перевірка часу компіляції дійсної XML
  • Забарвлення синтаксису
  • Повна інтелігенція
  • Складені перегляди
  • Розширюваність за допомогою звичайних класів, функцій CLR тощо
  • Безкоштовна комбінованість та маніпулювання, оскільки це звичайний код VB.NET
  • Одиниця перевірена

Мінуси:

  • Продуктивність: Створює весь DOM, перш ніж надсилати його клієнту.

Приклад:

Protected Overrides Function Body() As XElement
    Return _
    <body>
        <h1>Hello, World</h1>
    </body>
End Function

NDjango

Цілі дизайну:

NDjango - це реалізація мови шаблонів Django на платформі .NET, використовуючи мову F # .

Плюси:


NHaml

Цілі дизайну:

.NET порт двигуна перегляду Rails Haml. З веб-сайту Haml :

Haml - мова розмітки, яка використовується для чистого та простого опису XHTML будь-якого веб-документа, без використання вбудованого коду ... Haml уникає необхідності явного кодування XHTML в шаблон, оскільки це насправді абстрактний опис XHTML , з деяким кодом для створення динамічного вмісту.

Плюси:

  • лаконічна структура (тобто сухий)
  • добре з відступом
  • чітка структура
  • C # Intellisense (для VS2008 без ReSharper)

Мінуси:

  • абстрагування від XHTML, а не використання ознайомлення з розміткою
  • Немає Intellisense для VS2010

Приклад:

@type=IEnumerable<Product>
- if(model.Any())
  %ul
    - foreach (var p in model)
      %li= p.Name
- else
  %p No products available

NVelocityViewEngine (MvcContrib)

Цілі дизайну:

Механізм перегляду, заснований на NVelocity, який є .NET портом популярного Java проекту Velocity .

Плюси:

  • легко читати / писати
  • короткий перегляд коду

Мінуси:

  • обмежена кількість помічних методів, доступних для перегляду
  • не має автоматичної інтеграції Visual Studio (IntelliSense, перевірка перегляду в режимі компіляції або рефакторинг)

Приклад:

#foreach ($p in $viewdata.Model)
#beforeall
    <ul>
#each
    <li>$p.Name</li>
#afterall
    </ul>
#nodata 
    <p>No products available</p>
#end

SharpTiles

Цілі дизайну:

SharpTiles - це частковий порт JSTL в поєднанні з концепцією за рамкою Tiles (станом на Mile Kamen 1).

Плюси:

  • знайомий розробникам Java
  • Кодові блоки у стилі XML

Мінуси:

  • ...

Приклад:

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

Spark View Engine

Цілі дизайну:

Ідея полягає в тому, щоб дозволити html домінувати в потоці, а код легко вписуватися.

Плюси:

  • Створює більш читабельні шаблони
  • C # Intellisense (для VS2008 без ReSharper)
  • Плагін SparkSense для VS2010 (працює з ReSharper)
  • Забезпечує потужну функцію Прив'язки, щоб позбутися всього коду у ваших переглядах та дозволяє легко вигадувати власні теги HTML

Мінуси:

  • Немає чіткого відокремлення логіки шаблону від буквальної розмітки (це можна пом'якшити за допомогою префіксів простору імен)

Приклад:

<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 Перегляд двигуна MVC

Цілі дизайну:

  • Легкий. Класи сторінок не створюються.
  • Швидкий. Шаблони записуються в потік Response Output.
  • Кешування. Шаблони кешуються, але використовують FileSystemWatcher для виявлення змін файлів.
  • Динамічний. Шаблони можуть бути згенеровані на льоту в коді.
  • Гнучка. Шаблони можна вкладати на будь-який рівень.
  • Відповідно до принципів MVC. Сприяє розділенню інтерфейсу користувача та бізнес-логіки. Усі дані створюються достроково і передаються до шаблону.

Плюси:

  • знайомий розробникам Java StringTemplate

Мінуси:

  • синтаксис спрощеного шаблону може перешкоджати призначеному виводу (наприклад, конфлікт jQuery )

Крило б'є

Wing Beats - це внутрішній DSL для створення XHTML. Він заснований на F # і включає двигун перегляду ASP.NET MVC, але також може використовуватися виключно для його можливості створення XHTML.

Плюси:

  • Перевірка часу компіляції дійсної XML
  • Забарвлення синтаксису
  • Повна інтелігенція
  • Складені перегляди
  • Розширюваність за допомогою звичайних класів, функцій CLR тощо
  • Безкоштовна комбінованість та маніпулювання, оскільки це звичайний F # код
  • Одиниця перевірена

Мінуси:

  • Ви дійсно не пишете HTML, але код, який представляє HTML у DSL.

XsltViewEngine (MvcContrib)

Цілі дизайну:

Створює представлення з знайомих XSLT

Плюси:

  • широко всюдисущий
  • знайома мова шаблонів для розробників XML
  • На основі XML
  • перевірений часом
  • Помилки введення синтаксису та елементів можна статично виявити.

Мінуси:

  • функціональний стиль мови ускладнює контроль потоку
  • XSLT 2.0 (можливо?) Не підтримується. (XSLT 1.0 набагато менш практичний).


9
@ BrianLy: оскільки F # компільований і функціональний, а це означає, що він швидкий, більш взаємодіючий з рештою часу виконання (принаймні, до c # 4) та безвідмовний. Спочатку ми пішли по залізопітонному маршруту, але не були задоволені результатами. що стосується найменування - ми відкриті для пропозицій :)
kolosy

7
Вниз голосування через розділ "Мінуси" Brail. Визначення Бу як мови, безумовно, не є противником.
Оуен

48
@Owen: Так. Ви повинні дивитися на це з точки зору розробника C #. Ви не хочете вивчати ще одну мову лише для використання двигуна шаблонів. (звичайно, якщо ви вже знаєте Boo, це здорово, але для більшості розробників C # це додаткове перешкоду для подолання)
Крістіан Клаузер

5
Бритви там. Її слід оновити, щоб алфавітно обрізати.
mckamey

3
Бу - професіонал, а не кон. Ви вже "за межами" C #, чим термініший шаблон може вийти тим краще. C # не мав на увазі використовуватись у "шаблоновому" контексті, він дещо виразний, але не "підходить до зап'ястя". З іншого боку, BOO був створений з цим на увазі, і як такий він дає можливість набагато краще використовуватись у шаблоновому контексті.
Loudenvier

17

Мій поточний вибір - Бритва. Він дуже чистий і простий для читання, а сторінки перегляду зберігають дуже просто в обслуговуванні. Є також підтримка intellisense, яка справді чудова. ALos, коли використовується з веб-помічниками, він теж дуже потужний.

Щоб надати простий зразок:

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

І ось у вас це є. Це дуже чисто і легко читати. Зрозуміло, це простий приклад, але навіть на складних сторінках і формах його все ще дуже легко читати та розуміти.

Щодо мінусів? Досі (я новачок у цьому), коли використовуються деякі помічники для форм, не вистачає підтримки для додавання посилання на клас CSS, що трохи дратує.

Дякую Nathj07


1
До! Щойно помітив, скільки років це обговорення. Ну добре, можливо, хтось знайде це, і все одно виявиться корисним.
nathj07

10

Я знаю, що це насправді не відповідає на ваше запитання, але різні View Engine мають різні цілі. Наприклад, Spark View Engine , наприклад, має на меті позбавити ваших поглядів на "суп з тегів", намагаючись зробити все вільним і читабельним.

Найкраще ставитись до перегляду деяких реалізацій. Якщо це виглядає привабливо до наміру вашого рішення, спробуйте це. Ви можете змішувати та узгоджувати двигуни перегляду в MVC, тому це не повинно бути проблемою, якщо ви вирішите не користуватися певним двигуном.


Дякую за відповідь. Я буквально починав те, що ви запропонували, коли я зрозумів, "хтось уже повинен був зробити підсумок". Я сподіваюся на деяке узагальнення цих типів цілей дизайну та недоліків. "Іскрова система перегляду ... має на меті позбавити ваших поглядів на" суп із тегів ", намагаючись зробити все вільним і читабельним". Це означає причину його побудови, а також недолік механізму подання за замовчуванням. Ще одна куля в списку.
mckamey

7

Перевірте цей SharpDOM . Це внутрішній dsl AC # 4.0 для генерації html, а також движок перегляду asp.net mvc.


Здається, це єдиний розумний спосіб побудови поглядів.
Стефан Еггермонт

чи можете ви додати його до загальної відповіді вікі?
Маурісіо Шеффер

Я більше не можу його знайти на CodePlex або Google. Куди воно пішло ?? (Це все ще на Codeproject: codeproject.com/Articles/667581/… )
Джаред Тріск,

5

Мені подобається ndjango . Він дуже простий у використанні і дуже гнучкий. Ви можете легко розширити функціонал перегляду за допомогою спеціальних тегів та фільтрів. Я думаю, що "сильно прив’язаний до F #" - це скоріше перевага, ніж недолік.


4

Я думаю, що цей список також повинен містити зразки кожного механізму перегляду, щоб користувачі могли отримати смак кожного, не відвідуючи кожен веб-сайт.

Картинки говорять про тисячу слів, а зразки розмітки - це як скріншоти для двигунів перегляду :) Отже ось одне з мого улюбленого 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>

4
виглядає занадто схоже на застуду. Я не великий прихильник змішування коду в розмітку, як це. Це стає важко утримувати.
Agile Jedi
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.