2

100 ~ 1,000 行の 20 列のグリッドがあります。

各セルの平均が 50 文字である場合、1000 行のグリッドは 20x50x1000 文字 = 1MB で構成されると推定されます。

このグリッドのデータは、1 つ (または複数) の AJAX リクエストでサーバーから返される必要があります。グリッドは編集できません... 多くの情報 (特に人間の遺伝子について) を表す方法にすぎません。

これを 1 つの AJAX リクエストで返すか、複数で返すかを決めるのに苦労しています。これは、1 つの AJAX 要求の XML/JSON 応答で返されるデータ (1MB) が多すぎると思いますか? これはアンチパターンですか?それとも、すべてのデータが論理的に 1 つのグリッドの一部であることを理解するのは理にかなっていますか?

これは何よりも設計上の問題です。フィードバックをいただければ幸いです。

4

3 に答える 3

1

非 Ajax リクエストを使用してすべてのデータを一度ロードし、Ajax 経由で変更されたセルのみを更新することはできませんか?

于 2013-09-18T16:56:02.393 に答える
1

グリッドの「状態」をサーバーに保持するのは興味深いので、各フィールドを編集した後、新しいコンテンツをサーバーに送信します。これにより、サーバーの使用量と帯域幅が増加しますが、ユーザーが「送信」コマンドを送信したときの応答性が向上します。これにより、入力の検証も高速化されます (ユーザーがセルを変更したほぼ直後にエラー メッセージが表示されますが、30 分後ではありません)。

安全を確保するための改善として、「ダーティ」(変更された) フィールドのリストをメモリ (JS メモリ) に保持し、関連する ajax 応答がサーバーが ajax 呼び出しを確認したことを通知したときに値をリセットします。ユーザーが「送信」を押すと、まだダーティなすべてのフィールドがサーバーに再度送信されます。

そうは言っても、XML から離れている限り、負荷がそれほど重くなることはないと思います (もちろん、それはハードウェアとサービスを提供しなければならない同時ユーザーに依存します)。

于 2013-09-18T17:09:33.293 に答える
0

バッチでデータを取得することをお勧めします。つまり、最初の 20 ~ 25 行、またはビューポートを埋めるのに十分な行をフェッチし、ユーザーがスクロールするか、前のバッチの終わりに近づいたときに、次のバッチを徐々にロードします。それはそれをシームレスにするかもしれません。

すべてのデータを一度に取得することは、レコードの数を考慮すると選択肢にならない場合があります。

さらに、データが多すぎるということではなく、そのデータを取得するのにかかる時間です。(json 応答を操作する方法に応じて)、ブラウザーは任意の量のデータを処理できることを保証できます。

于 2016-09-26T13:53:09.993 に答える