ResultSet一般に、GWTサーバーとクライアントの通信の一部であるGWT-RPC経由で送信できる形式にaを変換する効率的な方法を探しています。JSON と RequestFactory を使用する利点と欠点は何ですか? 上記のように使用したい場合に備えて、誰かが説明してくれませんか?
単一のエントリだけでなく、データベースの大部分をクライアントで処理したいと言うことは重要かもしれません。一度に何百ものエントリについて話しているので、基本的にはデータを効率的に転送する方法が必要だと思います。
一度に 1 つのエントリを要求すると、大きなオーバーヘッドが発生しませんか?
同様のチュートリアルをいただければ幸いです。
通常、大量のデータを移動するのは非常に悪い考えであり、クライアント/サーバー アーキテクチャでは一般的ではありません。ですので、リデザインをお勧めします。
GWT-RPC はサービス指向です。すべての RPC フレームワークはどれですか。主な目的は、メソッド呼び出しをシリアライズ/デシリアライズすることです。つまり、サーバーとクライアントが通信しているのはメッセージであり、明確に定義する必要があります。GWT では基礎となるトランスポート メカニズムは JSON であり、SOAP (たとえば) では XML ですが、メカニズムは同じです。
RequestFactory は、はるかにデータ中心です。URL /getCustomers を使用した単純な HTTP 要求によってトリガーされるサーブレットを想像してください。サーブレットは単純にデータベースにアクセスして結果を返します。RequestFactory はそれに非常によく似ていますが、追加の機能を提供します。たとえば、RequestFactory は、エンティティ オブジェクト Customer をサーバーに作成し、プロキシ オブジェクト CustomerProxy をクライアントに作成することに依存しています。フレームワークは、これらのオブジェクト間のデータの転送を処理します。より具体的には、RequestFactory は個々のプロパティ (つまり「フィールド」) を更新できるため、状態の違いのみを送信することで効率を高めることができます。
重要なアーキテクチャ上の違いは、GWT-RPC がより機能的なレベルで動作することです。RequestFactory はデータ レベルで動作します。典型的な実装は、RequestFactory を使用して CRUD インターフェイスをセットアップすることです。このような設計は、GWT-RPC を使用すると非常に不適切です。
決定を下す前に、これら 2 つのフレームワークについて詳しく読むことをお勧めします。ただし、 RequestFactory が問題の最良の解決策のようです。
このユース ケースが 1 つしかない場合は、独自のサーブレットを実装するだけで十分でしょう。GWT コードで RequestBuilder を使用して、サーブレットからデータを要求します。データベースにアクセスし、ResultSet を JSON に変換し、クライアントで応答を JavaScriptObject に変換して戻します。これにより、RequestFactory とすべてのエンティティ、プロキシ、およびロケーターを設定する作業が節約されます。
データ中心のアプリケーションを使用し、サーバー側で JPA を使用する必要がある場合は、JSON よりも RequestFactory を使用することをお勧めします。(例: Hibernate、Spring など)。さらに、転送するデータの種類によって異なります。
一度にすべてのデータを転送するのは正しい考えではないかもしれません。シリアライズとデシリアライズに時間がかかるためです。ブラウザもハングする可能性があります（私の経験から）。ユーザーは、すべてのデータがロードされるまで待つ必要があります。
代わりに、データをブロック形式でクライアントに転送できるため、ユーザーが最初の部分を編集しているときに、2 番目の部分をバックグラウンドで読み込むことができます。