Массив объектов vs объект объектов

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

JSON на основе:

"users": {
    "id1": {
        "id": "id1",
        "firstname": "firstname1",
        "lastname": "lastname1"
    },
    "id2": {
        "id": "id2",
        "firstaame": "firstname2",
        "lastname": "lastname2"
    }
}

Массива:

users: [
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    },
    {
        "id": "id",
        "key2": "value2",
        "key3": "value3"
    }
]

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

но проблема в том, что сам список не статический. Под этим я подразумеваю, что список генерируется, т. е. извлекается/сохраняется из DB (NoSQL) и создается для новых записей через Java API на сервере. Я не могу решить, какую нотацию я должен использовать в конце (что в конечном итоге также повлияет на пользовательский интерфейс).

любые мысли/предложения о производительности, ремонтопригодности или масштабируемости ценятся.

38
arrays java json maintainability performance

5 ответов

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

подход на основе JSON: Если я не ошибаюсь, это будет реализовано с помощью Map на стороне сервера.

преимущество : в JavaScript вы можете напрямую использовать пользователей.id1, пользователи.id2 т. е. нет необходимости в итерации

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

подход на основе массива: если я не ошибаюсь, то это будет реализовано с помощью Array/List на стороне сервера.

преимущество:

  1. на стороне клиента, вы можете сразу итерировать через массив, без беспокоясь заранее о том, какой id присутствует внутри него, т. е. не трудно кодирование.
  2. As указал @JBNizet, подход на основе массива будет поддерживать порядок.

недостаток : если вы хотите получить один идентификатор, вам нужно будет перебрать массив.

вообще мы не отправляем много информации на стороне клиента, поэтому подход на основе массива не создаст никаких проблем. И преобразование массива в карту возможно как на стороне (сервер и клиент) если вы хотите подход на основе id.

17

на стороне сервера, массивы хранятся в виде простых списков: ArrayList<Content>, в то время как объекты хранятся в виде карт: HashMap<String, Content> или, в основном, как объекты Java.

чтобы преобразовать объекты Java в JSON и из JSON, вы можете взглянуть на Джексон что делает все это для вас.

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

глядя на ваш пример, я думаю Array является лучшим подходом, так как вы хотите вернуть список пользователей, которые все равны. Отправка id дважды не имеет смысла imho и увеличивает объем данных, которые должны быть переданы.

кроме того, так как Arrays намного проще хранить и перебирать в Java, они также должны обеспечивать лучшую производительность, чем объекты.

некоторые общие различия:

  • массивы сохраняют порядок
  • массивы могут содержать повторяющиеся записи
  • объекты часто имеют большие накладные расходы на хранение / сеть
  • массивы быстрее итерации (на стороне сервера)
5

одним из больших недостатков вашей первой нотации на основе JSON, которая приходит на ум, является то, что некоторые фреймворки будут иметь проблемы с (de)сериализацией этого. Например, DataContractSerializer (C# .NET) будет ожидать поля id1 и id2 для определения (hardcoded) в классе ваших объектов users. Я не уверен, что это относится и к некоторым Java-фреймворкам. Может быть, эти рамки вы можете использовать deserialze его как хранилище HashMap вместо.

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

1

можно использовать object[property] обозначение для доступа или установки свойств объекта в JavaScript.

идете с массива подойдите к бэкэнду и преобразуйте массив в карту (JSON на основе как вы его называете) в передней части.

var list = [{id: "id1", value: "One"}, {id: "id2", value: "Two"}]
var map = {};
list.forEach(function (item) { map[item.id] = item });
map.get("id1")

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

таким образом, ваш бэкэнд быстрее реагирует, поскольку ему не нужно конвертировать список на карте. Ваш передний конец будет выполнять итерацию O(n)после над списком, чтобы преобразовать его в карте. Но это небольшая цена по сравнению с O (n), которую вы будете платить каждый раз, когда вы ищете в списке.

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

0

оба подхода имеют свои плюсы и минусы и зависит от того, что вы смотрите.

подход массива прост в сериализации и более удобен для "фреймворка" (вы можете добавить бобы в список и сериализовать список, и все готово). Это позволяет, например, веб-контейнеру возвращать ответ, не требуя настройки. Это, вероятно, будет поддерживаться из коробки большинством фреймворков.

с другой стороны, объектно-ориентированный подход сложнее генерировать (в относительных терминах), но его легче искать, учитывая, что ключ известен.

поэтому для простоты реализации (производителем) перейдите к подходу на основе массива. Для удобства использования (потребляется клиентами) перейти на объектный подход.

0