ASP.NET MVC View Engine Сравнение
Я искал в SO & Google информацию о различных движках представления, доступных для ASP.NET MVC, но не нашел ничего, кроме простых высокоуровневых описаний движка представления.
Я не обязательно ищу "лучших" или "самых быстрых", а скорее некоторые сравнения реальных преимуществ / недостатков основных игроков (например, стандартный WebFormViewEngine, MvcContrib View Engines и т. Д.) Для различных ситуаций. Я думаю, что это было бы действительно полезно для определения того, будет ли переключение с движка по умолчанию выгодным для данного проекта или группы разработчиков.
Кто-нибудь сталкивался с таким сравнением?
6 ответов
ASP.NET MVC View Engines (Сообщество Wiki)
Поскольку полный список не существует, давайте начнем один здесь, на SO. Это может иметь большое значение для сообщества ASP.NET MVC, если люди добавят свой опыт (особенно любой, кто участвовал в одном из них). Что-нибудь реализующее IViewEngine (например VirtualPathProviderViewEngine) Честная игра здесь. Просто расположите в алфавитном порядке новые View Engines (оставив 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>
<%}%>
Цели дизайна:
Плюсы:
- Компактный, выразительный и плавный
- Легко обучаема
- Не новый язык
- Имеет большой 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>
}
}
Цели дизайна:
- Уважайте 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 использует XML-литералы VB.NET вместо строк, как большинство других движков представления.
Плюсы:
- Проверка правильности XML во время компиляции
- Синтаксическая раскраска
- Полная интеллигенция
- Скомпилированные представления
- Расширяемость с помощью обычных CLR-классов, функций и т. Д.
- Бесшовная компоновка и манипулирование, поскольку это обычный код VB.NET
- Блок тестируемый
Минусы:
- Производительность: строит весь DOM перед отправкой клиенту.
Пример:
Protected Overrides Function Body() As XElement
Return _
<body>
<h1>Hello, World</h1>
</body>
End Function
Цели дизайна:
NDjango - это реализация языка шаблонов Django на платформе.NET с использованием языка F#.
Плюсы:
- НДжанго релиз 0.9.1.0 кажется более стабильным в условиях стресса, чем
WebFormViewEngine - Django Template Editor с окраской синтаксиса, дополнением кода и диагностикой по типу (только VS2010)
- Интегрирован с ASP.NET, Castle MonoRail и Bistro MVC.
Цели дизайна:
.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 - это частичный порт 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>
Цели дизайна:
Идея состоит в том, чтобы позволить 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 - это внутренний DSL для создания XHTML. Он основан на F# и включает в себя механизм просмотра ASP.NET MVC, но также может использоваться исключительно для возможности создания XHTML.
Плюсы:
- Проверка правильности XML во время компиляции
- Синтаксическая раскраска
- Полная интеллигенция
- Скомпилированные представления
- Расширяемость с помощью обычных CLR-классов, функций и т. Д.
- Бесшовная компоновка и манипулирование, так как это обычный код F#
- Блок тестируемый
Минусы:
- Вы действительно не пишете HTML, а код, который представляет HTML в DSL.
Цели дизайна:
Строит взгляды из знакомого 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 имеют разные цели. Например, Spark 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>