web-dev-qa-db-ja.com

オブジェクトの配列とオブジェクトのオブジェクト

問題は、次の表記法のトレードオフを決定することです。

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"
    }
]

同じ問題に関する this の投稿に関連して、私は（フロントエンドで）オブジェクトの配列の代わりにJSONオブジェクト表記を使用することを決定しました。これは、要件とパフォーマンスの向上、ブラウザーのコードの削減に適しているためです。

しかし、問題はリスト自体が静的ではないことです。これにより、リストが生成されます。つまり、DB（NoSQL）から取得/保存され、サーバーでJava APIを介して新しいエントリ用に作成されます。どの表記法を決定することはできません。バックエンドで使用します（最終的にはUIにも影響します）。

パフォーマンス、保守性、またはスケーラビリティについての考えや提案を歓迎します。

javaarraysjsonperformancemaintainability
49
me_digvijay

これは、全体的な意見に基づいた質問です。他にも多くのポイントがあるかもしれませんが、以下のように指摘できます。

JSONベースのアプローチ：私が間違っていなければ、これはサーバー側でMapを使用して実装されます。

Advantage： JavaScriptでは、users.id1、users.id2を直接使用できます。つまり、繰り返しの必要はありません。

短所：クライアント側では、JSONに存在するIDを要求する方法、つまり、ハードコーディングするか、JSONに存在するIDを示す動的アプローチを使用します。

配列ベースのアプローチ：私が間違っていなければ、これはサーバー側でArray/Listを使用して実装されます。

利点：

  1. クライアント側では、配列内にどのIDが存在するかを事前に心配することなく、つまりハードコーディングなしで、配列を直接反復処理できます。
  2. @ JBNizetで指摘されているように、配列ベースのアプローチは順序を維持します。

短所：単一のIDを取得する場合は、配列を反復処理する必要があります。

一般に、クライアント側では多くの情報を送信しないため、配列ベースのアプローチでは問題は発生しません。そして、IDベースのアプローチが必要な場合は、配列をマップに変換することは両方の側（サーバーとクライアント）で可能です.

19
Naman Gala

サーバー側では、配列は単純なリストとして保存されます：ArrayList<Content>、オブジェクトはマップとして保存されます：HashMap<String, Content>または、Javaオブジェクト。

JavaエンティティとJSONの間の変換を行うには、すべての処理を行う Jackson プロジェクトをご覧ください。

これら2つのバリアントのパフォーマンスの違いについて心配する必要はありません。理解できるセマンティックAPIを持つことがより重要であるため、パフォーマンスよりもビジネスケースに基づいて意思決定を行う必要があります。

あなたの例を見ると、Arrayがより良いアプローチだと思います。なぜなら、あなたはすべて等しいユーザーのリストを返したいからです。 idを2回送信しても意味がなく、送信するデータの量が増えます。

さらに、ArraysはJavaでの保存と反復がはるかに簡単なので、Objectsよりもパフォーマンスが優れているはずです。

いくつかの一般的な違い：

  • 配列は順序を保持します
  • 配列には重複エントリを含めることができます
  • 多くの場合、オブジェクトにはより大きなストレージ/ネットワークオーバーヘッドがあります
  • 配列の反復処理の高速化（サーバー側）
6
maja

頭に浮かぶ最初の「JSONベース」表記法の大きな欠点の1つは、一部のフレームワークでこれの（デ）シリアル化に問題があることです。たとえば、DataContractSerializer（C＃.NET）では、フィールドid1およびid2オブジェクトのクラスで定義（ハードコード）されるusers。これが一部のJavaフレームワークにも当てはまるかどうかはわかりません。使用するフレームワークは、代わりにHashMapとしてデシリアライズできます。

配列の表記法は、イテレーションなどに関しては、はるかに直感的に使用できます。

1
Sebastian

object[property]表記 を使用して、JavaScriptのオブジェクトのプロパティにアクセスしたり、プロパティを設定したりできます。

バックエンドでarray basedアプローチを使用して、配列をマップに変換します（JSON basedあなたがそれを参照するように）フロントエンドで。

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

リストが変更された場合、バックエンドから新しいリストを取得し、UIでマップを更新できます。

この方法では、リストをマップに変換する必要がないため、バックエンドの応答が速くなります。フロントエンドは、リストにO(n)反復once）を実行してマップに変換します。これはO(n)と比較して小さな価格です。リストで検索するたびに料金が発生します。

バックエンドで主にデータでIDを取得する場合は、バックエンド自体でJSON Basedを使用します（LinkedHashMap順序を保持します）。

0
Foxx

上記のすべての技術的な違いに加えて、ObjectとArrayの目的と意味には根本的な違いがあると思います。

  1. オブジェクトのプロパティDESCRIBE/DEFINEオブジェクト

  2. 配列の要素はNOT DESCRIBE/DEFINE配列であり、逆に配列はその内容を定義します。注意してください-私は技術的な側面について話していません。技術的には任意の組み合わせを使用できますが、意味的にはそれぞれに目的があります。

    • たとえば、カード所有者。各カードはNOT DESCRIBE/DEFINEカード所有者です。ただし、カード所有者は、カード/

    • オブジェクトは、エンティティとそのプロパティを表すために使用されますDESCRIBE/DEFINEエンティティ。同じカードの例を見てください。カードには、色、番号などのプロパティがありますDESCRIBE/DEFINEカードの内容。

上記の例の場合：

  1. 個人を表す各オブジェクトプロパティで定義されます id、firstName、lastName。

  2. 各IDはオブジェクトのオブジェクトを記述していないであるため、これらの人物のリストはオブジェクトのオブジェクトにはなれません。そう

    "users"：[{"id"： "id"、 "key2"： "value2"、 "key3"： "value3"}、{"id"： "id"、 "key2"： "value2"、 "key3 "：" value3 "}]

より良い表現です

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

技術的にはどちらでも使用できますが。私は自分の考えを正しい方法で伝えることができたと思います。

0
wallop

どちらのアプローチにも長所と短所があり、あなたが見ているものに依存します。

配列アプローチは、シリアル化が簡単で、より「フレームワーク」に適しています（リストにBeanを追加してリストをシリアル化すれば完了です）。これにより、たとえば、Webコンテナーはカスタマイズを必要とせずに応答を返すことができます。これは、ほとんどのフレームワークですぐにサポートされる可能性があります。

一方、オブジェクトベースのアプローチは（相対的な観点から）生成するのがより困難ですが、キーが与えられている場合はルックアップが容易です。

（プロデューサーによる）実装を簡単にするために、配列ベースのアプローチに進みます。 （クライアントが使用する）使いやすさのために、オブジェクトベースのアプローチを選択してください。

0
Ravindra HV