3

JSON をあまり実装していないので、データを処理するための推奨されるアプローチがあるかどうか知りたいです。2 つの主なアプローチがあると推測していますが (おそらくそれらは無効な JSON です)、追加のプラス/マイナス、またはより良いアプローチがあるかどうかを確認したいと思います。

アプローチ 1 : キーと値のペアの組み合わせ

var all_in_one = { "person"  : [{
                                  "firstName" : "John",
                                  "lastName"  : "Smith",
                                  "phone"     : [{ 
                                                   "areaCode"  : "800", 
                                                   "number"    : "222-3333" 
                                                 },
                                                 {
                                                   "areaCode"  : "800",
                                                   "number"    : "222-3334",
                                                   "extension" : "1111"
                                                 }]
                                },
                                {
                                  "firstName" : "John",
                                  "lastName"  : "Rolfe"
                                },
                                {...}],
                   "other"    : [{...}]
                 };

利点：

  • キーは値に近い (値をループしてプルするときのコードがより視覚的で明確になる)
  • 値/キーは必要ありません (流体モデル/構造)

問題:

  • 複数のレコードのオーバーヘッドが増える (キーの繰り返し)

アプローチ 2 : キーと値の分離

var json = { "model" : { "person" : ["firstName","lastName",["areaCode","number","extension"]],
                         "other"  : [...]
                       },
             "data"  : { "person" : [["John","Smith",[["800","222-3333",undefined],
                                                      ["800","222-3334","1111"]]],
                                     ["John","Rolfe",[[undefined,undefined,undefined]],
                                     [...]
                                    ],
                         "other"  : [...]
                       }
            };

利点：

  • オーバーヘッドが少ない (キーは 1 回定義される)
  • 一箇所で変更可能な静的モデル/構造

問題:

  • 変更が予想される場合、静的モデル/構造はより問題になる可能性があります
  • データを抽出するとき、コードがより混乱する可能性があります
4

2 に答える 2

2

アプローチ 2 を使用している人を見たことがありません。「モデルからデータ」を分離しません。とにかく、データはモデルなので意味がありません。あなたがしたことは、データが何であるかを伝えるのを本当に難しくしただけです。

フィールドの名前を 1 か所で変更できるようになったと思いますが、これはスキーマ変更の中で最も一般的でないタイプの 1 つに違いありません。フィールドの追加、フィールドの移動、フィールドの削除、2 つのフィールドの交換、フィールドのオプション化などはすべて、検証不可能な悪夢です。

(そして、オーバーヘッドに関しては、gzip がネットワーク上でそれを処理し、JSON デコーダーや言語が、繰り返されるキーごとに同じ文字列オブジェクトを再利用するのに十分スマートであることを願っています。)

于 2013-01-21T06:17:31.370 に答える
1

あなたのアプローチ2をオブジェクトの形で見たことはありませんが、最初の配列に列名が含まれ、他の配列にデータが含まれるデータテーブルに非常に似ています。

2 番目のアプローチには 2 つの主な問題があります。

  • より厳格です（たとえば、別の電話プロパティを追加するのは簡単ではありません）
  • 多くの「未定義」になってしまうため、スパースデータでは不便です

明らかな利点は、プロパティ名を繰り返す必要がないため、データ サイズが大幅に小さくなることです。

結論: データがテーブルにうまく収まり (空のセルが数個しかない)、データセットが大きい場合は、2 番目のアプローチを使用します。

[編集] 「他のメタデータも渡す必要があるかどうか知りたい」という質問については、これは間違いなく 2 番目のアプローチの追加の利点です。コメントで既に述べたように、Google Visualization は良い例です。また、まさにそれを行う Microsoft SharePoint 2013 も使用しています。SharePoint の例を次に示します。

{"Name": "Editor",
"FieldType": "User",
"RealFieldName": "Editor",
"DisplayName": "Modified By",
...
"AllowGridEditing": "FALSE"}
于 2013-01-21T06:32:09.610 に答える