Вопрос

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

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

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

Это было полезно?

Решение

Механизмы представления ASP.NET MVC (вики-сообщество)

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


System.Web.Mvc.WebFormViewEngine

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

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

Плюсы:

  • повсеместно распространен, поскольку поставляется с ASP.NET MVC.
  • знакомый опыт для разработчиков ASP.NET
  • IntelliSense
  • можно выбрать любой язык с помощью провайдера CodeDom (например,C#, VB.NET, F#, Бу, Немерле)
  • компиляция по требованию или предварительно скомпилированный Просмотры

Минусы:

  • использование сбивает с толку существование «классических шаблонов 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>
<%}%>

Система.Web.Razor

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

Плюсы:

  • Компактный, выразительный и плавный
  • Легко обучаема
  • Это не новый язык
  • Имеет отличный IntelliSense
  • Модульное тестирование
  • Вездесущ, поставляется с ASP.NET MVC.

Минусы:

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

Пример мошенничества № 1 (обратите внимание на размещение «string[]...»):

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

Бельвью

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

  • Уважайте HTML как первоклассный язык, а не рассматривайте его как «просто текст».
  • Не связывайтесь с моим HTML!Код привязки данных (код Bellevue) должен быть отделен от HTML.
  • Обеспечьте строгое разделение модели и представления.

Брайл

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

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

Плюсы:

  • создан по образцу «синтаксиса Python, удобного для запястья»
  • Компилированные представления по требованию (но предварительная компиляция недоступна)

Минусы:

  • предназначен для написания на языке Бу

Пример:

<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 — это реализация Язык шаблонов Джанго на платформе .NET, используя язык F#.

Плюсы:


Нхамл

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

.NET-порт механизма представления Rails Haml.От сайт Хамла:

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

Плюсы:

  • краткая структура (т.СУХОЙ.)
  • с хорошим отступом
  • четкая структура
  • С# 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

Нвелокитивиевэнжине (MvcContrib)

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

Механизм просмотра, основанный на NСкорость который является портом .NET популярного Java Project Скорость.

Плюсы:

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

Минусы:

  • ограниченное количество вспомогательных методов, доступных в представлении
  • не имеет автоматической интеграции с 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

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

Идея состоит в том, чтобы позволить HTML доминировать в потоке и коде, чтобы соответствовать плавному соответствию.

Плюсы:

  • Создает более читаемые шаблоны
  • С# 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

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

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

Плюсы:

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

Минусы:

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

Другие советы

Мой текущий выбор — Razor.Он очень понятен и легко читается, а страницы просмотра очень просты в обслуживании.Существует также поддержка IntelliSense, и это действительно здорово.Однако при использовании с веб-помощниками это тоже очень мощный инструмент.

Чтобы предоставить простой образец:

@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

Я знаю, что это на самом деле не отвечает на ваш вопрос, но разные механизмы просмотра имеют разные цели.А Механизм просмотра Spark, например, стремится избавить ваши взгляды от «супа тегов», пытаясь сделать все беглым и читабельным.

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

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

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

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

Картинки говорят тысячу слов, а образцы разметки похожи на скриншоты для движков просмотра :) Итак, вот один из моих любимых Механизм просмотра Spark

<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>
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top