Соглашение о написании кода: Сопоставление бэкенда с метками внешнего интерфейса

В моем бэкэнде у меня есть атрибуты данных, помеченные в верблюжьем регистре:

customerStats: {
  ownedProducts: 100,
  usedProducts: 50,
},

Мой код пользовательского интерфейса настроен таким образом, что массив ["label", data] работает лучше всего большую часть времени, т. е. наиболее удобен для внешнего кодирования. В моем внешнем интерфейсе мне нужно, чтобы эти метки были в правильном английском написании, чтобы их можно было использовать как есть в пользовательском интерфейсе:

customerStats: [
  ["Owned products", 100],
  ["Used products", 50],
],

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

Существует ли соглашение о кодировании того, как данные должны передаваться во внешний интерфейс?

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

Технологии, которые я использую:

  • Фронтенд: Javascript/React
  • Бэкенд: Javascript/Node.js + Java/Java Spring

frontend backend data-conversion conventions code-standards
person EliteRaceElephant    schedule 08.12.2019    source источник
comment
Структуры данных должны быть преобразованы в удобочитаемые метки как можно позже, обычно только в окончательном HTML-шаблоне (если применимо). Когда именно «последняя» возможная точка, во многом зависит от вашего конкретного приложения.   -  person deceze♦    schedule 09.12.2019
comment
@deceze Да, я так и думал. У вас есть ссылка, например, сообщение в блоге или статья для этого утверждения, в которой это объясняется более подробно? Тогда я бы принял это как ответ.   -  person EliteRaceElephant    schedule 09.12.2019
comment
Вы не упомянули, какие технологии вы используете для внешнего или внутреннего интерфейса, эта информация может сильно повлиять на ответ, который вы получите.   -  person Chris Schaller    schedule 11.12.2019
comment
@ChrisSchaller Я добавил технологии: Внешний интерфейс: Javascript / React. Бэкенд: Javascript/Node.js + Java/Java Spring. Я задал общий вопрос и ожидал общего ответа. Ваш ответ довольно обширен. Спасибо!   -  person EliteRaceElephant    schedule 11.12.2019

Ответы (1)


arrow_upward
1
arrow_downward

Существует ли соглашение о кодировании для передачи данных во внешний интерфейс?

Если ваш внешний интерфейс основан на javascript, то JSON (нотация объектов Java Script) является самой простой формой для использования, это строчная версия объектов в памяти. Дополнительную информацию о JSON см. в этом здоровом обсуждении

Учитывая, что в наши дни самым популярным языком разработки интерфейсов является javascript (см. последний обзор SO по технологиям) Очень распространено и широко распространено использование формата JSON для передачи данных между серверной и клиентской частью решений. Решение использовать JSON в решениях, не основанных на javascript, зависит от используемых вами инструментов разработки и развертывания, поскольку все больше разработчиков используют javascript, и большинство наших инструментов разработаны для поддержки javascript в той или иной степени.

Однако в равной степени допустимо использование других структурированных форматов, таких как XML.

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

  • XML является более формальным форматом для передачи данных, он может включать полную документацию схемы, которая позволяет получателям использовать информацию практически без дополнительной документации.

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

Лучше всего преобразовывать данные в форму, которая требуется во внешнем или внутреннем интерфейсе?

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

Поскольку JSON может быть изначально интерпретирован во внешнем интерфейсе javascript, во внешнем интерфейсе javascript мы можем существенно сократить преобразование только до границы на стороне сервера, где данные сериализуются/десериализуются. По сути, во внешнем интерфейсе вообще нет преобразования.

Как ссылаться на данные по имени свойства, а не по визуальной метке

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

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

В разных технологиях и платформах мы относимся к этому по-разному, но основная концепция отделения модели от представления или представления постоянно представлена ​​в этих шаблонах проектирования:

Для конкретного сценария OP это может включать структуру сопоставления, подобную следующей:

customerStatsLabels: {
  ownedProducts: "Owned products",
  usedProducts: "Used products",
}

Если этот вопрос будет дополнен некоторым кодом, касающимся построения пользовательского интерфейса, я обновлю этот ответ чем-то более конкретным.

ПРИМЕЧАНИЕ:

В javascript объекты — это просто массивы массивов, поэтому очень легко преобразовать существующий код, основанный на массивах, в код, основанный на объектах, и наоборот.

person Chris Schaller    schedule 11.12.2019