6

最初に:私はこの質問がここで尋ねられたことに気づきました:ExtJSでは、Model.save()またはStore.Sync()を呼び出す方が良いですか?-ただし、特にクライアントとサーバーの両方でXHRと不要なオーバーヘッドを最小限に抑えることに関して、これをさらに検討したいと思います。リンクされた質問では、これらの点のどちらも取り上げられていないと思います。

私は、エンタープライズリソース管理用に設計された、多くのモデル、ビュー、およびコントローラーで構成される、やや大きなアプリケーションを持っています。Ext.AjaxrequestCompleterequestExceptionイベントへのリスナーを確立することで、サーバーからのすべての応答を処理します。すべてのモデルのプロキシイベントに重複するイベントハンドラーを作成するのではなく、このアプローチを採用しafterRequestました。これにより、すべてのバックエンド(Zend Frameworkを使用)コントローラーが、、およびの3つのパラメーターで応答できるようになりsuccessます。messagedata

リクエストが成功すると(つまり、HTTP 200)、実行さrequestCompleteれるメソッドは、前述のパラメーターのJSON応答を検査します。の場合、に含まれるエラーメッセージがsuccess表示され、ユーザーに表示されます(たとえば、「その製品の保存に問題がありました。製品名が無効です」)。成功した場合は、リクエストのタイプ(作成、読み取り、更新、破棄)に応じてアクションが実行されます。成功すると、新しいレコードが適切なデータストアに追加され、削除すると、レコードが破棄されます。falsemessagecreate

syncXHRやその他のラウンドトリップを最小限に抑えるために、ストアにレコードを追加してストアのメソッドを呼び出すのではなく、このアプローチを採用することにしました。データを保存/更新する現在の方法は、リクエストをバックエンドに送信し、Extフロントエンドでの結果に反応することです。これを行うには、モデルにデータを入力し、create / updateリクエストの場合はmodel.save()を呼び出し、データを削除するにはmodel.destroy()を呼び出します。

ストアからレコードを追加/更新/削除してからstore.sync()を呼び出すと、サーバーの応答にぎこちなく反応する必要があることがわかりました。たとえば、レコードを削除するとします。

  1. まず、を介してストアからレコードを削除しますstore.remove()
  2. store.sync()ストアがにautoSync設定されているので呼び出しfalseます。
  3. これにより、ストアのモデルプロキシからAJAX破棄リクエストが発生します。
  4. ここがおかしなところです。データベースから行を削除しているときにサーバーでエラーが発生した場合、応答は返されますsuccess: falseが、レコードはすでにExtJSデータストアから削除されています。
  5. この時点でstore.sync()store.load()(両方とも往復が必要です)に電話するか、リクエストからレコードを取得してストアに追加し、その後にcommitChanges()追加の同期/読み込みを呼び出さないようにして、不要な往復を回避することができます。

レコードの追加についても同じことが言えます。データベースへのデータの追加中にサーバーがどこかで失敗した場合、レコードはまだExtJSストアにあり、またはとのラウンドトリップを回避するために手動で削除する必要がありstore.sync()ますstore.load()

この問題全体を回避するために、前に説明したように、モデルオブジェクトの1つ(Productモデルなど)をインスタンス化し、データを入力して、を呼び出しますmyModel.save()createこれにより、モデルのIDに応じて、またはプロキシが呼び出さupdateれ、適切なAJAXリクエストが実行されます。バックエンドに障害が発生した場合でも、フロントエンドストアは変更されません。リクエストが成功すると(success: trueHTTP 200ではなく読み取り:)、手動でレコードをストアに追加して呼び出しstore.commitChanges(true)、追加のラウンドトリップなしでストアをデータベースと効果的に同期し、不要なオーバーヘッドを回避します。すべてのリクエストに対して、サーバーは新規/変更されたデータと成功パラメーター、および条件付きでクライアントに表示するメッセージで応答します。

ここで何かが足りないのでしょうか、それともこのアプローチはXHRとサーバー/クライアントのオーバーヘッドを最小限に抑えるための良い方法ですか?必要に応じてサンプルコードを提供できてうれしいですが、これは基本的なコードを使用したかなり一般的な概念だと思います。

4

1 に答える 1

2

あなたは雄弁に自分の立場を主張したと思います。あなたの立場に問題はありません。私の唯一の非難は、編集可能なグリッドをバックアップするストアのautoSync設定は、制御が少ないとはいえ、タスクを実行するためのはるかに冗長な方法ではないことを指摘することです。

さらに、あなたが指摘するオーバーヘッドは、通常、予期しないものによるものです。または、特別な処理やデータの追加の更新が必要になる可能性のあるエッジケースを呼び出します。これらの特定のケースのリスナーを追加し、残りは簡潔なデフォルトで機能させることができます。

于 2012-10-31T17:50:54.547 に答える