Чи краще Razor або XSLT для мого проекту? [зачинено]

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

XSLT або Razor допоможуть забезпечити розділення проблем, коли оригінальний XML або відповідь представляє вашу модель, XSLT або "Перегляд бритви" представляє ваш погляд. Я залишу контролер поза цим прикладом. Початкова проектна пропозиція рекомендує 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 досить потужний у встановлених операціях, він просто руйнується, коли ви намагаєтеся в ньому реалізувати логіку (якщо так, комутатор, для тощо).

Вибирати не потрібно, ви можете використовувати і те, і інше. У 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.

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

Все це говорило, якщо ви повинні піти шляхом завершення своєї роботи користувальницьким інтерфейсом, я настійно рекомендую Razor за XSLT.

XSLT - це стандарт, так. Але XSLT 2.0 все ще має обмежену підтримку, тому ви застрягли із застарілим стандартом, якщо хочете зробити цей аргумент.

XSLT читати непросто. Тим, хто не є експертом XSLT. Як ви думаєте, кого легше знайти, коли вам потрібно найняти нових співробітників? Хтось, хто претендує на експерта XSLT чи ASP.NET для експерта MVC?

І так, я бачив, як XSLT успішно використовувався, але лише до того, як MVC для ASP.NET був варіантом.