it-swarm.com.ru

Почему плохой практикой является возвращать сгенерированный HTML вместо JSON? Либо это?

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

Но все книги, все эксперты пытаются заставить меня использовать JSON вместо сгенерированного HTML. Как это намного лучше, чем HTML? 

Это очень намного быстрее?
Есть ли у него намного меньшая нагрузка на сервер?

С другой стороны, у меня есть несколько причин для использования сгенерированного HTML.

  1. Это простая разметка, часто такая же компактная или даже более компактная, чем JSON.
  2. Это менее подвержено ошибкам, потому что все, что вы получаете, это разметка, а не код.
  3. В большинстве случаев программирование будет выполняться быстрее, так как вам не придется писать код отдельно для клиентской части.

На какой ты стороне и почему?

290
Cyril Gupta

Я немного с обеих сторон, на самом деле:

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

Основное преимущество использования HTML - это когда вы хотите заменить полную часть своей страницы тем, что возвращается из запроса Ajax:

  • Перестроить часть страницы в JS (довольно) сложно
  • У вас, вероятно, уже есть какой-то шаблонизатор на стороне сервера, который использовался для генерации страницы в первую очередь ... Почему бы не использовать его повторно?

Обычно я не принимаю во внимание аспекты производительности, по крайней мере, на сервере:

  • На сервере создание части HTML или JSON, вероятно, не будет иметь большого значения
  • О размере материала, который проходит через сеть: ну, вы, вероятно, не используете сотни КБ data/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 сделает свое дело ;-)

244
Pascal MARTIN

Я в основном согласен с мнением, изложенным здесь. Я просто хотел обобщить их как:

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

  • Неправильно отправлять JSON, если все, что вам в итоге нужно сделать, это включить его в дерево DOM страницы.

108
Vinko Vrsalovic

Что ж,

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

Таким образом, сервер должен сосредоточиться на доставке модели (в этом случае JSON лучше) .... Таким образом, вы получаете гибкий подход. Если вы хотите изменить представление вашей модели, вы сохраняете сервер, отправляющий те же данные, и просто меняете клиент, компоненты javascript, которые превращают эти данные в представление. Представьте себе, у вас есть сервер, доставляющий данные на мобильные устройства, а также настольные приложения.

Кроме того, такой подход повышает производительность, поскольку серверный и клиентский код можно создавать одновременно, не теряя при этом фокуса, что и происходит, когда вы продолжаете переключаться с js на PHP/Java/и т.д.

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

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

26
user1769128

У меня есть кое-что интересное, я думаю, я мог бы добавить. Я разработал приложение, которое загружало полный просмотр только один раз. С этого момента он общался обратно на сервер только с 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 :)

Дайте мне знать, что вы думаете о моем гибриде!

9
Chev

Если ответ не нуждается в дальнейшей обработке на стороне клиента, на мой взгляд, HTML в порядке. Отправка JSON только заставит вас выполнить эту обработку на стороне клиента.

С другой стороны, я использую JSON, когда не хочу использовать все данные ответов одновременно. Например, у меня есть серия из трех связанных выборок, где выбранное значение одного определяет, какие значения будут использоваться для заполнения второго, и так далее.

8
Ionuț G. Stan

IMV, это все о отделении данных от представления данных, но я с Паскалем, это не обязательно означает, что это разделение может быть только через границу клиент/сервер. Если у вас уже есть это разделение (на сервере) и вы просто хотите что-то показать клиенту, то, будете ли вы отправлять обратно JSON и обрабатывать его на клиенте или просто будете возвращать HTML, полностью зависит от ваших потребностей. Сказать, что вы «не правы», чтобы отослать обратно HTML в общем случае, - это слишком далеко от заявления IMV.

7
T.J. Crowder

Если вам нужен чистый отделенный клиент, что, на мой взгляд, является наилучшей практикой, то имеет смысл иметь 100% DOM, созданных с помощью javascript. Если вы создаете клиент на основе MVC, который обладает всеми необходимыми знаниями для создания пользовательского интерфейса, тогда ваши пользователи загружают один файл JavaScript один раз, и он кэшируется на клиенте. Все запросы после этой начальной загрузки основаны на Ajax и возвращают только данные. Этот подход является самым чистым, который я нашел, и обеспечивает чистую независимую инкапсуляцию презентации.

Серверная сторона тогда просто фокусируется на доставке данных.

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

6
Lance Caraccioli

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

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

Просто мои 2 цента.

6
Mike

В зависимости от вашего пользовательского интерфейса вам может потребоваться обновить два (или более) различных элемента в вашей DOM. Если ваш ответ в HTML, вы собираетесь проанализировать это, чтобы выяснить, что и куда? Или вы можете просто использовать хэш JSON.

Вы даже можете объединить это, вернуть JSON с HTML-данными :)

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

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

2
John Saman

Отправка json обычно выполняется, когда у вас есть виджет javascript, запрашивающий информацию с сервера, такую ​​как список, древовидная структура или автозаполнение. Это когда я отправляю JSON, так как это данные, которые будут проанализированы и использованы в сыром виде. Однако, если вы просто собираетесь показывать HTML, тогда гораздо меньше работы для его генерации на стороне сервера и просто для показа в браузере. Браузеры оптимизированы для вставки HTML прямо в dom с помощью innerHTML = "", так что вы не ошибетесь с этим.

1
Zoidberg

Зависит от обстоятельств.

Иногда важно избегать JSON . Когда у наших программистов возникают проблемы при программировании, например, на js.

Мой опыт подсказывает мне, что лучше использовать сервис ajax, чем встроенный JSON.

Рано или поздно JS становится проблемой

0
Alegoric

Html-ответа достаточно в большинстве случаев, если только вам не придется выполнять какие-либо вычисления на стороне клиента.

0
mubashir

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

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

0
Methee