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

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

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

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

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

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

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

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

• Когда на стороне 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 сделает свое дело, я полагаю ;-)

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

• Это плохая практика отправлять 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 и views на стороне сервера (создавая высокую нагрузку на сервер), теперь я использую некоторые пользовательские функции jquery, и все данные отображаются на стороне клиента, используя клиентский браузер в качестве парсера шаблонов. это экономит ресурсы сервера, и с другой стороны, браузеры улучшают свои движки JS каждый день. Таким образом, скорость синтаксического анализа клиента сейчас не важна, тем более что объекты JSON обычно очень малы, поэтому они не потребляют много ресурсов на стороне клиента. Я предпочитаю иметь медленный сайт для некоторых пользователей с медленным браузером, а не медленный сайт для всех из-за очень загруженного сервера.

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

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

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

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

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

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

Вы даже можете объединить это, вернуть JSON с 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 становится проблемой