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

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

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

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

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

Плюсы:

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

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. Способствует разделению пользовательского интерфейса и бизнес-логики. Все данные создаются заранее и передаются в шаблон.

Плюсы:

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

Минусы:

• упрощенный синтаксис шаблона может мешать намеченному выводу (например, конфликт 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 гораздо менее практичен).

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

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

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

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

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

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

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