ASP.NET MVC View Engine Сравнение

Я искал в SO & Google информацию о различных движках представления, доступных для ASP.NET MVC, но не нашел ничего, кроме простых высокоуровневых описаний движка представления.

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

Кто-нибудь сталкивался с таким сравнением?

20.09.2009 15:47:47
Странно, что это «неконструктивно», но в то же время принесло много пользы тем, кто смотрел его почти 45 тысяч раз. Жаль, что SO ограничивает свою собственную полезность, несмотря на потребности сообщества. Я сомневаюсь, что @ Jeff-Atwood будет чувствовать себя так.
mckamey 10.05.2013 16:06:14
6 ОТВЕТОВ

Я знаю, что это на самом деле не отвечает на ваш вопрос, но разные View Engine имеют разные цели. Спарк Просмотр двигатель , например, цели , чтобы избавить ваши взгляды «теги супа», пытаясь сделать все , свободно и читаемым.

Лучше всего было бы просто взглянуть на некоторые реализации. Если это выглядит привлекательным для целей вашего решения, попробуйте его. Вы можете смешивать и сопоставлять механизмы представления в MVC, поэтому это не должно быть проблемой, если вы решите не использовать определенный механизм.

10
20.09.2009 15:49:23
Спасибо за ответ. Я буквально начинал то, что вы предложили, когда понял, что «кто-то уже должен был сделать резюме». Я надеюсь на некоторое объединение этих типов целей дизайна и недостатков. «Spark View Engine ... стремится избавить ваши взгляды от« супа метки », пытаясь сделать все свободно и читабельно». Это подразумевает причину его построения, а также недостаток механизма представления по умолчанию. Еще одна пуля в списке.
mckamey 20.09.2009 15:56:57
РЕШЕНИЕ

ASP.NET MVC View Engines (Сообщество Wiki)

Поскольку полный список не существует, давайте начнем один здесь, на SO. Это может иметь большое значение для сообщества ASP.NET MVC, если люди добавят свой опыт (особенно любой, кто участвовал в одном из них). Все, что реализует IViewEngine(например VirtualPathProviderViewEngine), является честной игрой здесь. Просто расположите в алфавитном порядке новые View Engine (оставив 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! Код привязки данных (код Bellevue) должен быть отделен от 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

Hasic использует XML-литералы VB.NET вместо строк, как большинство других движков представления.

Плюсы:

  • Проверка правильности XML во время компиляции
  • Синтаксическая раскраска
  • Полная интеллигенция
  • Скомпилированные представления
  • Расширяемость с помощью обычных классов, функций и т. Д.
  • Бесшовная компоновка и манипулирование, поскольку это обычный код 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 stone 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 View Engine MVC

Цели дизайна:

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

Плюсы:

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

Минусы:

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

Wing Beats

Wing Beats - это внутренний DSL для создания XHTML. Он основан на F # и включает в себя механизм просмотра ASP.NET MVC, но также может использоваться исключительно для его возможности создания XHTML.

Плюсы:

  • Проверка правильности XML во время компиляции
  • Синтаксическая раскраска
  • Полная интеллигенция
  • Скомпилированные представления
  • Расширяемость с помощью обычных классов, функций и т. Д.
  • Бесшовная компоновка и манипулирование, так как это обычный код F #
  • Блок тестируемый

Минусы:

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

XsltViewEngine (MvcContrib)

Цели дизайна:

Строит взгляды из знакомого XSLT

Плюсы:

  • широко вездесущий
  • знакомый язык шаблонов для разработчиков XML
  • XML на основе
  • испытанный
  • Синтаксис и ошибки вложения элементов могут быть обнаружены статически.

Минусы:

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

430
23.05.2017 12:18:26
@ BrianLy: потому что F # скомпилирован и функционален, что означает, что он быстрый, более совместим с остальной частью времени выполнения (по крайней мере, до c # 4) и идемпотентен. Сначала мы пошли по маршруту Ironpython, но не остались довольны результатами. что касается наименования - мы открыты для предложений :)
kolosy 22.09.2009 19:31:40
Вниз голосование из-за секции Минусы Brail. Иметь Boo как язык - это не обман.
Owen 28.03.2010 16:42:49
@ Оуэн: Да, это так. Вы должны смотреть на это с точки зрения разработчика C #. Вы не хотите изучать еще один язык только для того, чтобы использовать шаблонизатор. (естественно, если вы уже знаете Boo, это круто, но для большинства разработчиков на C # это дополнительное препятствие, которое нужно преодолеть)
Christian Klauser 1.06.2010 17:09:26
Бритва там. Это должно быть обновлено, чтобы разложить Razor по алфавиту.
mckamey 22.07.2010 20:08:26
Бу - Профи, а не Кон. Вы уже «за пределами» C #, чем круче шаблон, тем лучше. C # не предназначался для использования в «шаблонном» контексте, он несколько выразителен, но не «дружелюбен к запястьям». С другой стороны, BOO был создан с учетом этого и, как таковой, он гораздо лучше подходит для использования в шаблонном контексте.
Loudenvier 16.05.2011 15:44:12

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

На рисунках написано, что тысячи слов, а образцы разметки похожи на скриншоты для движков представления :) Итак, вот один из моих любимых 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
12.10.2010 21:01:48
выглядит слишком похоже на холодный синтез. Я не большой поклонник смешивания кода в разметку, как это. Это становится трудно поддерживать.
Agile Jedi 30.12.2010 04:55:41

Мне нравится нджанго . Он очень прост в использовании и очень гибкий. Вы можете легко расширить функциональность просмотра с помощью пользовательских тегов и фильтров. Я думаю, что «сильно привязанный к F #» является скорее преимуществом, чем недостатком.

5
25.02.2010 19:48:57

Проверьте это SharpDOM . Это внутренний dsl ac # 4.0 для генерации html, а также механизм просмотра asp.net mvc.

8
30.04.2010 21:10:34
Звучит как единственный разумный способ построения представлений.
Stephan Eggermont 7.07.2010 08:22:23
Вы можете добавить его в общий ответ вики?
Mauricio Scheffer 31.08.2010 13:59:26
Я не могу найти его на CodePlex или Google больше. Куда это делось ?? (Это все еще на Codeproject: codeproject.com/Articles/667581/… )
Jared Thirsk 21.05.2014 21:34:58

Мой текущий выбор - Бритва. Он очень чистый и легкий для чтения, а страницы просмотра очень просты в обслуживании. Есть также поддержка 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

17
13.11.2011 19:21:15
Doh! Просто заметил, сколько лет этой дискуссии. Ну что ж, может быть, кто-то найдет это, и это все равно окажется полезным.
nathj07 13.11.2011 19:22:08