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

Я искал SO и Google для разбивки различных механизмов просмотра, доступных для ASP.NET MVC, но не нашел намного больше, чем простые описания на высоком уровне того, что такое механизм просмотра.

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

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

Ответ 1

ASP.NET MVC View Engine (Community Wiki)

Поскольку исчерпывающий список не существует, запустите его здесь на SO. Это может иметь большое значение для сообщества ASP.NET MVC, если люди добавляют свой опыт (особенно тот, кто внес вклад в один из них). Все, что реализует IViewEngine (например, VirtualPathProviderViewEngine), является честной игрой здесь. Просто переместите в алфавитном порядке новые View Engine (оставляя WebFormViewEngine и Razor вверху) и старайтесь быть объективными в сравнении.

System.Web.Mvc.WebFormViewEngine

Цели проектирования:

Механизм просмотра, который используется для визуализации Веб-формы для ответа.

Плюсы:

вездесущий, поскольку он поставляется с ASP.NET MVC
знакомый опыт для разработчиков ASP.NET
IntelliSense
может выбрать любой язык с провайдером CodeDom (например, С#, 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
Единичное тестирование
Ubiquitous, поставляется с 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.

Обеспечить строгое разделение Model-View

Brail

Цели проектирования:

Механизм просмотра Brail был портирован от MonoRail для работы с Microsoft ASP.NET MVC Framework. Для введение в Брейл, см. документация по проекту Замок сайт.

Плюсы:

смоделированный после "синтаксиса питона на основе запястья"
Скомпилированные представления по запросу (но не существует прекомпиляции)

Минусы:

предназначен для написания на языке 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
Раскраска синтаксиса
Полная intellisense
Скомпилированные представления
Расширяемость с использованием обычных классов CLR, функций и т.д.
Бесшовная композиция и манипуляция, так как это обычный код VB.NET
Единичное тестирование

Минусы:

Производительность: создает всю DOM перед отправкой ее клиенту.

Пример:

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

NDjango

Цели проектирования:

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

Плюсы:

NDjango release 0.9.1.0 кажется более стабильным при стрессе, чем WebFormViewEngine
Редактор шаблонов Django с раскраской синтаксиса, завершением кода и диагностикой типа (только VS2010)
Интегрировано с ASP.NET, каркасами MonoRail и бистро MVC

NHaml

Цели проектирования:

Интерфейс .NET port of Rails Haml. Из веб-сайт Haml:

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

Плюсы:

краткая структура (т.е. D.R.Y.)
с отступом
четкая структура
С# 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в сочетании с концепцией Плитки каркас (на Майл-Камень 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 доминировать над потоком и код для соответствия бесшовно.

Плюсы:

Создает более читаемые шаблоны
С# Intellisense (для VS2008 без ReSharper)
плагин SparkSense для VS2010 (работает с ReSharper)
Предоставляет мощную функцию Bindings, чтобы избавиться от всего кода в ваших представлениях и позволяет легко изобретать собственные 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 для обнаружения изменения файла.

Dynamic. Шаблоны можно генерировать "на лету" в коде.

Гибкая. Шаблоны могут быть вложены в любой уровень.

В соответствии с принципами MVC. Способствует разделению пользовательского интерфейса и бизнеса Логика. Все данные создаются раньше времени и передается шаблону.

Плюсы:

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

Минусы:

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

Wing Beats

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

Плюсы:

Проверка времени правильного XML
Раскраска синтаксиса
Полная intellisense
Скомпилированные представления
Расширяемость с использованием обычных классов CLR, функций и т.д.
Бесшовная композиция и манипуляция с регулярным кодом F #
Единичное тестирование

Минусы:

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

XsltViewEngine (MvcContrib)

Цели проектирования:

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

Плюсы:

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

Минусы:

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

Ответ 2

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

Ответ 3

Я знаю, что это не отвечает на ваш вопрос, но разные View Engine имеют разные цели. Например, Spark View Engine стремится избавить ваши взгляды от "суп-суп", пытаясь сделать все свободно и читаемо.

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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