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

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

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

Быстрее ли это?
Он имеет гораздо меньшую нагрузку на сервер?

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

Наконец, важно одно:

  • Как долго вам понадобится разработать новую систему, которая будет отправлять данные в виде кода JSON +, который JS должен был ввести в HTML как 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 выполнит трюк, я полагаю; -)

Ответ 2

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

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

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

Ответ 3

Ну,

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

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

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

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

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

Ответ 4

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

Сообщите мне, что вы думаете о моем гибриде!

Ответ 5

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

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

Ответ 6

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

Ответ 7

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

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

Только мои 2 цента.

Ответ 8

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

Затем серверная часть фокусируется на доставке данных.

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

Ответ 9

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

Вы даже можете объединить его, вернуть данные JSON w/html:)

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Ответ 15

Без сомнения, я согласен с "ramaralo", если мы придерживаемся принципа ответственности, это то, как он говорит, и исходя из этого, наш код будет иметь самое отдельное представление и независимо от сервера, по крайней мере, в случае использования чистого PHP