Лучший способ моделирования идентификаторов (уникальный идентификатор) в JSON

При моделировании данных JSON мы обычно имеем дело с уникальными идентификаторами объектов. Мы могли бы моделировать их как (i) ключ (или имущество) или как (ii) значение. Какое лучшее решение, если оно есть, или какие плюсы и минусы? Вот пример.Лучший способ моделирования идентификаторов (уникальный идентификатор) в JSON

идентификатор в качестве ключа:

[ 
    { 
    "1": { 
     "tel": "tel1", 
     "e-mail": "mail2" 
    } 
    }, 
    { 
    "2": { 
     "tel": "tel2", 
     "e-mail": "mail2" 
    } 
    } 
]

идентификатор в качестве значения id ключа:

[ 
    { 
    "id": 1, 
    "tel": "tel1", 
    "e-mail": "mail2" 
    }, 
    { 
    "id": 1, 
    "tel": "tel2", 
    "e-mail": "mail2" 
    } 
]

источник

2015-09-22 floatingpurr

Я боюсь, что этот вопрос может быть подвержен в первую очередь на основе мнения. Во всяком случае, почему первый пример? Было бы разумнее описать концепцию * key * как '{" 1 ": {}," b ": {}," 3 ": {}}'. –

Спасибо, Пьеро, Извините Если мой вопрос кажется слишком общим, но я искал лучшие практики для этих случаев. Например, MongoDb сохраняет идентификатор документа как значение ключа с именем '' _id '', мне было интересно, почему. Возможно, это зависит от контекста. – floatingpurr

Я нахожу ваш вопрос интересным; часто в ООП вам нужно решить, должен ли объект знать свой идентификатор или нет («самосознание»?) –

Преимущество № 2

[ 
    { 
    "id": 1, 
    "tel": "tel1", 
    "e-mail": "mail2" 
    }, 
    { 
    "id": 1, 
    "tel": "tel2", 
    "e-mail": "mail2" 
    } 
]

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

Однако по той же причине, если идентификатор не является свойством модели, а имеет отдельное значение, тогда вы должны перейти с опцией 1, поскольку он говорит: вот первый объект, и это его свойства , Вот второй объект, и эти его свойства и т.д.

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

Также , как правильно предложил Пьетро, вариант 1 можно сделать красивее, удалив {} вокруг каждого объекта.

{ 
    "1": { 
     "tel": "tel1", 
     "e-mail": "mail2" 
    }, 
    "2": { 
     "tel": "tel2", 
     "e-mail": "mail2" 
    } 
}

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

Принимая это во внимание, вариант 2 также красивее. Меньше сговорок {}.

Другой правильное замечание Пьетро:

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

источник

2015-09-22 12:40:33

. Я бы добавил, что JSON - это * формат обмена данными *, не очень близкий к инструменту моделирования. Вы должны сначала взглянуть на свою модель данных (класс, базу данных или что еще), а затем на ваш сериализатор JSON (de): ваш выбор JSON-представления должен возникнуть оттуда. –

@PietroSaccardi Я согласен, но я решил, что это дано –

, которые должны быть понятны заранее. Однако это не повредит будущим читателям! –

Лучший способ моделирования идентификаторов (уникальный идентификатор) в JSON

ответ

Смежные вопросы