Razor или XSLT лучше для моего проекта? [закрыто]

Я на начальной стадии разработки системы, которая по сути будет разделена на две части. Одна часть является службой, а другая - интерфейсом со службой, предоставляющей данные через что-то вроде OData или XML. Приложение будет основано на архитектурном шаблоне MVC. Для представлений мы рассматриваем возможность использования XSLT или Razor в ASP.NET.

XSLT или Razor помогут разделить проблемы, когда исходный XML или ответ представляет вашу модель, XSLT или «Razor view» представляет ваше представление. Я оставлю контроллер для этого примера. Первоначальное проектное предложение рекомендует XSLT, однако я предложил использовать вместо него Razor в качестве более дружественного механизма просмотра.

Вот причины, которые я предложил для Razor (C #):

• Проще работать и создавать более сложные страницы.
• Может легко производить вывод не-ML, например csv, txt, fdf
• Менее подробные шаблоны
• Модель представления строго типизирована, где XSLT должен полагаться на соглашение, например, логические значения или значения даты
• Разметка более доступна, например, nbsp, нормализация новой строки, нормализация значений атрибутов, правила пробелов
• Встроенный помощник HTML может генерировать код проверки JS на основе атрибутов DTO
• Встроенный HTML-помощник может генерировать ссылки на действия

И аргументы для XSLT над бритвой были:

• XSLT является стандартом и будет существовать еще много лет в будущем.
• Трудно случайно переместить логику в поле зрения
• Легче для не программистов (с которыми я не согласен).
• Это было успешным в некоторых наших прошлых проектах.
• Значения данных по умолчанию закодированы в HTML
• Всегда хорошо сформирован

Итак, я ищу агенты с обеих сторон, рекомендации или какой-либо опыт, делающий подобный выбор?

Я БЫЛИ успешно используется XSLT в качестве веб - ярусе презентации ... в 1999 году в течение последних 12 лет, гораздо лучшие варианты пришли вместе. Сделай себе большую услугу и используй бритву. С удовольствием.

Вот базовое сравнение синтаксиса

бритва

@foreach(var item in View.List) {
  <span>@item.Name</span><br/>
}

XSLT

  <xsl:template match="/">
    <xsl:apply-templates/>
  </xsl:template>

  <xsl:template match="item">
    <xsl:for-each select="name">
      <xsl:value-of select="."/><br/>
    </xsl:for-each>
  </xsl:template>

</xsl:stylesheet>

Источники данных для двух примеров

XML

<?xml version="1.0" standalone="no"?>
<?xml-stylesheet type="text/xsl" href="transform.xsl"?>
<list>
    <item>
        <name>List item one</name>
        <url>http://site.com/one</url>
    </item>
    <item>
        <name>List item two</name>
        <url>http://site.com/two</url>
    </item>
</list>

C #

ViewModel.List = new[] {
    new Link {
        Name = "List item one",
        Url = "http://site.com/one"
    },
    new Link {
        Name = "List item two",
        Url = "http://site.com/two"
    }
};

Существует ли соотношение 1: 1 между страницами HTML и выводом XML? Рассмотрим следующие случаи:

• Сильная корреляция: каждая веб-страница имеет HTML-код и соответствующую XML-форму.

Пример: у вас есть сайт с обзорами фильмов. У вас есть домашняя страница с последними отзывами, одна страница на обзор и страница с комментариями и оценками гостей. Там нет регистрации вообще. Вы хотите упростить использование вашего веб-сайта программным способом без разбора HTML. В этом случае вы можете иметь отношение 1: 1: все, что может сделать человек, бот тоже может сделать: при одинаковых запросах они получат одинаковое содержимое.

http://example.com/Movie/View/12345/The%20Adjustment%20Bureau используется людьми.
http://example.com/Movie/View/12345/The%20Adjustment%20Bureau?xml используется ботами для доступа к той же информации.

• Слабая связь или отсутствие корреляции: на одной стороне просто куча веб-сервисов, а на другой - куча веб-страниц.

Пример: вы создатель другого Facebook. Есть веб-сайт, и есть API. Единственная общая черта заключается в том, что используется одна и та же база данных, но боты не могут получить доступ к тому, что могут люди, а информация представлена ​​по-другому.

http://example.com/MyFriends/ показывает первую десятку друзей, которые у меня есть в моей учетной записи. При нажатии «Далее» делается запрос AJAX, показывающий других друзей.
http://api.example.com/friends?user=MainMa&key=1DE051C6F&xml показывает соответствующий XML со всеми моими друзьями.

Ты это видишь:

• API размещается отдельно, на отдельном сервере,
• Отношение между страницами и API трудно увидеть.
• Веб-сайт должен использовать сеансы для отслеживания входа в систему. API требует только сгенерированного ключа для отправки на каждый запрос.
• Количество запросов не одинаково. В одном случае вам нужно запросить страницу, а затем сделать запрос AJAX, чтобы получить остальных ваших друзей. В другом случае вы получаете весь список сразу.
• Возвращенная информация не совпадает. Как человек, вы идентифицируете своих друзей по имени. Бот, использующий API, идентифицирует их по уникальному идентификатору, который вы никогда не увидите на сайте.

Я рекомендую выбирать XSLT, только если вы близки к соотношению 1: 1 . В этом случае это упростит подход: приложение будет каждый раз испускать XML, но иногда преобразует его в XSLT для браузеров.

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

Что касается перечисленных вами преимуществ:

XSLT является стандартом и будет существовать много лет в будущем

Планируете ли вы подать заявку, которая будет жить очень долго? Бритва может быть использована в течение четырех лет или, по крайней мере, получит поддержку. Срок службы большинства приложений составляет менее четырех лет, так что ...

Легче для не программистов (что-то, с чем я мог бороться).

Чего ждать?! Даже программисты считают, что XSLT отстой, сложен для понимания и использования. И когда я говорю с непрограммистами о XML (даже близко не к XSLT), они плачут и убегают.

Это было успешным в некоторых наших прошлых проектах.

Если ваша команда никогда раньше не использовала Razor, подумайте, сколько времени нужно для ее изучения.

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

Я рекомендую Razor, и главная причина в том, что с ним гораздо проще работать (чем с XSLT, и в отличие от вашего перечисленного аргумента в пользу XSLT, вы на моей стороне). У меня есть опыт работы с обоими, и Razor становится исключительно мощным в условных выражениях, декларативных помощниках (функциях в принципе), ветвлениях, циклах и т. Д.

В конце концов, давайте не будем забывать, что Razor - это язык программирования (да, механизм шаблонов или механизм просмотра, но реализованный через язык программирования, такой как C # или VB.NET), в то время как XSLT более имеет структуру разметки.

Я думаю, что ваш сценарий похож на попытку выбрать C # или T-SQL для написания сложного бизнес-приложения. Хотя T-SQL довольно мощный в операциях над множествами, он просто ломается, когда вы пытаетесь реализовать в нем логику (if-else, switch, for и т. Д.).

Вам не нужно выбирать, вы можете использовать оба. В ASP.NET MVC вы можете использовать несколько механизмов просмотра одновременно. В проекте, над которым я сейчас работаю, я использую XSLT для представлений только для чтения и Razor для форм. Вы также можете использовать XSLT с макетом Razor или Razor с макетом XSLT. Я использую макет XSLT, поэтому я просто использую макет Razor, который вызывает макет XSLT и передает разделы HTML в качестве параметров:

@{ 
   Html.RenderPartial("~/Views/shared/htmlRaw.xsl", null, new ViewDataDictionary { 
      { "head", RenderSection("head", required: false) },
      { "content", RenderBody().ToString() }
   });
}

... и htmlRaw.xslвы просто используете disable-output-escaping="yes":

<div id="content">
   <xsl:value-of select="$content" disable-output-escaping="yes"/>
</div>

Смотрите Использование Razor и XSLT в одном проекте .

Я хотел бы предложить третий и лучший способ: поместить два разных тонких интерфейса поверх одного уровня службы / приложения, который не имеет пользовательского интерфейса как такового.

Так что вместо

UI -> converts to and from xml -> Service -> talks to -> Application Layer -> Model

использование

UI -> talks to -> Application Layer -> manipulates -> Model
Service ^

и убедитесь, что пользовательский интерфейс и служба содержат ТОЛЬКО код, уникальный для этого интерфейса. (извинения за диаграммы ASCII, лучшее, что я могу сделать прямо сейчас)

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

Хуже того, если бизнес хочет отображать данные для конечного пользователя совершенно иначе, чем то, как они представляются механическому пользователю через сервис (что кажется весьма вероятным), вам придется начать вводить сложный код в XSLT, или создайте второй сервисный слой (или, что еще хуже, жирные контроллеры) поверх вашего сервиса, чтобы представить презентацию пользователю.

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

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

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

Все это говорит о том, что если вы хотите пойти по пути упаковки вашего сервиса с помощью пользовательского интерфейса, я настоятельно рекомендую Razor вместо XSLT.

XSLT - это стандарт, да. Но XSLT 2.0 по-прежнему имеет ограниченную поддержку, поэтому вы застряли с устаревшим стандартом, если вы хотите сделать этот аргумент.

XSLT не легко читать. Любой, кто не является экспертом по XSLT. Как вы думаете, кого легче найти, когда вам нужно нанять новых сотрудников? Кто-то, претендующий на звание эксперта по XSLT или ASP.NET для MVC?

И да, я видел, как XSLT успешно использовался, но только до того, как MVC для ASP.NET был выбран.