Чому погана практика повертати згенерований HTML замість JSON? Або це?

Завантажити вміст HTML зі своїх користувацьких URL-адрес / веб-служб досить просто за допомогою JQuery або будь-якого іншого подібного фреймворку. Я багато разів використовував цей підхід і до цього часу вважав ефективність задовільною.

Але всі книги, всі експерти намагаються змусити мене використовувати JSON замість генерованого HTML. Як він набагато перевершує HTML?

Це дуже швидше?
Чи має він набагато менше навантаження на сервер?

З іншого боку, у мене є деякі причини використання створеного HTML.

1. Це проста розмітка, і часто так само компактна або насправді більш компактна, ніж JSON.
2. Це менше схильних до помилок, тому що все, що ви отримуєте, - це розмітка, і немає коду.
3. Програмування буде швидше у більшості випадків, оскільки вам не доведеться писати код окремо для клієнта.

На якій стороні ви знаходитесь і чому?

Я трохи по обидва боки, насправді:

• Коли то , що мені потрібно на стороні браузера дані , я використовую JSON
• Коли мені потрібно на стороні javascript - це презентація, на якій я не буду робити жодних обчислень, я зазвичай використовую HTML

Основна перевага використання HTML полягає в тому, що ви хочете замінити повну частину своєї сторінки тим, що повертається з запиту Ajax:

• Повторно скласти частину сторінки в JS (досить) важко
• Напевно, у вас вже є якийсь механізм шаблонування на стороні сервера, який використовувався в першу чергу для створення сторінки ... Чому б не використати її повторно?

Я, як правило, не беру до уваги "продуктивність" сторони речей, принаймні на сервері:

• На сервері, генеруючи частину HTML чи деякий JSON, ймовірно, це не змінить
• Про розмір речей, які проходять через мережу: ну ви, мабуть, не використовуєте сотні КБ даних / html ... Використання gzip у будь-якому, що ви передаваєте, саме те, що має найбільше значення (не вибираючи між HTML і JSON)
• Одне, що може бути враховано, це те, які ресурси вам потрібні клієнту, щоб відтворити HTML (або структуру DOM) з даних JSON ... порівняйте це з проштовхуванням частини HTML на сторінку; -)

Нарешті, однозначно важливе:

• Скільки часу знадобиться розробка нової системи, яка надсилатиме дані як JSON + код, JS, необхідний для введення його як HTML на сторінку?
• Скільки часу буде потрібно лише повернути HTML? І як довго, якщо ви зможете повторно використовувати якийсь із вже існуючих кодів на стороні сервера?

І щоб відповісти на іншу відповідь: якщо вам потрібно оновити більше однієї частини сторінки, все ще є рішення / хак для надсилання всіх цих частин в одну велику рядок, що об'єднує кілька частин HTML, і витягніть відповідні частини в JS.

Наприклад, ви можете повернути рядок, який виглядає приблизно так:

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

Це виглядає не дуже добре, але це, безумовно, корисно (я використовував його досить багато разів, в основному, коли HTML-дані були занадто великими, щоб бути інкапсульованими в JSON) : ви надсилаєте HTML для частин сторінки, які потрібна презентація, і ви надсилаєте JSON у випадку необхідних даних ...

... І щоб витягнути їх, метод підстроки JS зробить трюк, я думаю ;-)

В основному я згоден з висловленими тут думками. Я просто хотів підсумувати їх як:

• Неправильна практика надсилати HTML, якщо ви в кінцевому підсумку аналізуєте його на стороні клієнта, щоб зробити деякі обчислення над ним.

• Неправильна практика надсилати JSON, якщо все, що ви в кінцевому підсумку робите, - це включити його в дерево DOM сторінки.

Добре,

Я одна з тих рідкісних людей, яка любить розділяти речі таким чином: - Сервер відповідає за доставку даних (модель); - Клієнт відповідає за показ (перегляд) та маніпулювання даними (модель);

Отже, сервер повинен зосередитися на наданні моделі (в цьому випадку JSON краще). Таким чином, ви отримуєте гнучкий підхід. Якщо ви хочете змінити вигляд вашої моделі, ви продовжуєте сервер надсилати ті самі дані і просто змінювати клієнт, компоненти JavaScript, які змінюють ці дані на представлення. Уявіть, у вас є сервер, який передає дані на мобільні пристрої, а також настільні додатки.

Крім того, такий підхід збільшує продуктивність, оскільки сервер і клієнтський код можна будувати одночасно, ніколи не втрачаючи уваги, що відбувається, коли ви продовжуєте переходити з js на PHP / JAVA / і т.д.

Як правило, я думаю, що більшість людей вважають за краще робити якомога більше на серверній стороні, оскільки вони не опановують js, тому намагаються уникати цього якомога більше.

В основному я маю таку ж думку, що і ті хлопці, які працюють над Angular. На мою думку, це майбутнє веб-додатків.

У мене є щось цікаве, що я думав, що можу додати. Я розробив додаток, який лише один раз завантажував повний перегляд. З цього моменту він спілкувався назад із сервером лише ajax. Для завантаження однієї сторінки потрібно було лише колись (моя причина цього тут неважлива). Цікава частина полягає в тому, що у мене була особлива потреба повернути деякі дані, якими слід працювати в javascript І частковий вигляд, який буде відображатися. Я міг би розділити це на два заклики до двох окремих методів дій, але я вирішив піти на щось трохи веселіше.

Перевір:

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

Що ви можете запитати RenderPartialViewToString ()? Саме цей маленький самородок прохолоди тут:

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

Я не робив жодних тестів на ефективність щодо цього, тому я не впевнений, що він несе більш-менш накладні витрати, ніж викликати один метод дій для JsonResult і один для ParticalViewResult, але я все ще вважав, що це досить круто. Він просто серіалізує частковий вигляд у рядок і надсилає його разом з Json як один із його параметрів. Тоді я використовую JQuery, щоб взяти цей параметр і ляпати його у відповідний вузол DOM :)

Дайте мені знати, що ви думаєте про мій гібрид!

Якщо відповідь не потребує подальшої обробки на стороні клієнта, на мою думку, HTML в порядку. Відправлення JSON лише змусить вас зробити цю обробку на стороні клієнта.

З іншого боку, я використовую JSON, коли не хочу використовувати всі дані відповіді одночасно. Наприклад, у мене є серія з трьох ланцюгових вибірок, де вибране значення одного визначає, які значення використовуватимуться для заповнення другого тощо.

IMV, справа в тому, щоб відокремити дані від подання даних, але я з Паскалем, це не обов'язково випливає, що поділ може бути лише через межу клієнта / сервера. Якщо у вас вже є розмежування (на сервері) і ви просто хочете щось показати клієнту, чи ви надсилаєте назад JSON, чи обробляєте його на клієнті, чи просто відправляєте назад HTML, повністю залежить від ваших потреб. Сказати, що ви "неправі" надсилати HTML назад у загальному випадку, це занадто бланк заяви IMV.

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

З іншого боку, надсилаючи чисті дані з сервера, ви абстрагуєте їх від презентації, тому, якщо завтра ви хочете змінити їх або інтегрувати свої дані в інший сервіс, ви можете зробити це набагато простіше.

Всього мої 2 копійки.

Якщо ви хочете отримати чистий розв'язаний клієнт, що, на мій погляд, є найкращою практикою, то має сенс мати 100% DOM, створений JavaScript. Якщо ви створюєте клієнт на базі MVC, який має всі знання про те, як створити інтерфейс користувача, то ваші користувачі завантажують один раз файл Javascript один раз і він кешується на клієнті. Усі запити після цього початкового завантаження базуються на Ajax і повертають лише дані. Цей підхід є найчистішим, що я знайшов, і забезпечує чітке незалежне капсулювання презентації.

Тоді серверна сторона зосереджується лише на наданні даних.

Тож завтра, коли продукт попросить вас повністю змінити дизайн сторінки, все, що ви зміните, - це джерело JS, який створює DOM, але, швидше за все, ви отримаєте можливість використовувати вже наявні обробники подій, і сервер не звертає уваги, оскільки він на 100% відключається від презентації

Залежно від вашого інтерфейсу користувача, можливо, вам доведеться оновити два (або більше) різних елемента у вашому домені. Якщо ваша відповідь у HTML, чи збираєтесь ви її розібратися, щоб зрозуміти, що куди йде? Або ви можете просто використовувати хеш JSON.

Ви навіть можете комбінувати його, повертати дані JSON w / html :)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

HTML має багато зайвих і не відображаються даних, тобто тегів, таблиць стилів тощо. Отже, розмір HTML у порівнянні з даними JSON буде більшим, що призведе до більшого часу завантаження та візуалізації, а також призведе до того, що браузер буде зайнятий переданням нових даних.

Надсилання json, як правило, виконується, коли у вас є віджет javascript, який запитує інформацію з сервера, наприклад, список або дерево, або автозаповнення. Це коли я надішлю JSON, оскільки це дані, які будуть проаналізовані та використані в сирому вигляді. Однак якщо ваш тільки що покаже HTML, то його набагато менше роботи, щоб створити його на стороні сервера і просто показати його в браузері. Веб-браузери оптимізовані для вставки HTML безпосередньо в dom з innerHTML = "", тому ви не можете помилитися з цим.

Я думаю, це залежить від структури дизайну, використовувати JSON просто більш сексуально, ніж HTML, але питання полягає в тому, як би впоратися з ним, щоб його було легко підтримувати.

Наприклад, скажіть, що у мене є сторінка переліку, яка використовує той самий html / стиль всього сайту, я б написав глобальну функцію для форматування цих частин HTML, і все, що мені потрібно зробити, це передати об’єкт JSON у функцію.

Відповіді Html достатньо в більшості випадків, якщо вам не доведеться виконати певний розрахунок на стороні клієнта.

Залежить від обставин.

Іноді важливо уникати JSON. Наприклад, коли наші програмісти мають проблеми з програмуванням у js, наприклад.

Мій досвід говорить про це: краще використовувати послугу ajax, ніж вбудований JSON.

Рано чи пізно js стає проблемою