gwt-rpc 呼び出しを新しい GWT2.1 RequestFactory cal に移行する必要があるかどうかを判断しようとしています。
Google のドキュメントでは、RequestFactory が「データ指向サービス」のためのより優れたクライアント サーバー通信方法であると漠然と述べています。
ドキュメントから抽出できるのは、通信を簡素化する新しい Proxy クラスがあることです (実際のエンティティをやり取りするのではなく、プロキシのみをやり取りするため、軽量で管理が容易になります)。
それが要点ですか、それとも全体像で何か他のものを見逃していますか?
GWT RPC と RequestFactory の大きな違いは、RPC システムが「具体的なタイプごとの RPC」であるのに対し、RequestFactory は「インターフェースごとの RPC」であることです。
RPC は、より少ないコード行を記述し、クライアントとサーバーの両方で同じクラスを使用するため、使い始めるのに便利です。Person一連のゲッターとセッターを備えたクラスを作成し、Personオブジェクト内のデータをさらに細かく分割するための単純なビジネス ロジックを作成することもできます。これは、クラス内にサーバー固有で GWT と互換性のないコードが必要になるまでは、非常にうまく機能します。RPC システムは、クライアントとサーバーの両方で同じ具象型を持つことに基づいているため、GWT クライアントの機能に基づいて複雑さの壁にぶつかる可能性があります。
PersonDTO互換性のないコードの使用を回避するために、多くのユーザーは、サーバーで使用される実際のPersonオブジェクトをシャドウするピアを作成することになります。には、サーバー側の「ドメイン」オブジェクトのPersonDTOゲッターとセッターのサブセットがあります。ここで、 andオブジェクトと、クライアントに渡す他のすべてのオブジェクト タイプとのPerson間でデータをマーシャリングするコードを記述する必要があります。PersonPersonDTO
RequestFactory は、ドメイン オブジェクトが GWT 互換ではないことを想定して開始します。Proxy インターフェイスでクライアント コードによって読み書きされるプロパティを宣言するだけで、RequestFactory サーバー コンポーネントがデータのマーシャリングとサービス メソッドの呼び出しを処理します。「エンティティ」または「ID とバージョンを持つオブジェクト」という明確に定義された概念を持つアプリケーションの場合、EntityProxy型を使用して、データの永続的な ID セマンティクスをクライアント コードに公開します。ValueProxy単純なオブジェクトは、型を使用してマップされます。
RequestFactory を使用すると、GWT RPC が簡単にサポートするよりも複雑なシステムに対応するために、初期費用を支払う必要があります。RequestFactoryは、インスタンスServiceLayerを追加することでその動作をカスタマイズするための大幅に多くのフックを提供します。ServiceLayerDecorator
RPCからRFへの移行を経験しました。まず、私の経験は限られていると言わざるを得ません。私は0と同じ数のEntityProxiesを使用しました。
GWT RPCの利点：
GWT RPCの欠点：
RequestFactoryのデメリット：
RequestFactoryの利点
一般的にGWTの他の欠点を考慮する：
提供されたJUnitサポートを使用して統合テスト（GWTクライアントコード+リモートサーバー）を実行することはできません<=すべてのJSNIをモックする必要があります（例：localStorage）。SOPが問題です。
テストセットアップのサポートなし-ヘッドレスブラウザ+リモートサーバー<=GWT、SOPの単純なヘッドレステストはありません。
はい、セレン統合テストを実行することは可能です（しかし、それは私が望んでいることではありません）
JSNIは非常に強力ですが、会議で行われるこれらの輝かしい講演では、JSNIコードの記述にはいくつかのルールもあるということについてはあまり話しません。繰り返しになりますが、簡単なコールバックを作成する方法を理解することは、真の研究者にとって価値のある作業でした。
要約すると、GWT RPCからRequestFactoryへの移行は、RPCがほとんどニーズに合っている場合、WIN-WINの状況からはほど遠いものです。最終的に、クライアントドメインオブジェクトからプロキシへ、またはその逆に大量の変換を書き込むことになります。ただし、ソリューションにはある程度の柔軟性と堅牢性があります。そして、フォーラムでのサポートは、土曜日にも素晴らしいです！
今述べたすべての長所と短所を考慮すると、これらのアプローチのいずれかが実際にソリューションと開発セットアップに大きなトレードオフなしで改善をもたらすかどうかを事前に考えることは非常に有益です。
すべてのエンティティのプロキシクラスを作成するというアイデアは非常に面倒です。私のHibernate/JPA pojoは、データベースモデルから自動生成されます。RPC用にそれらの2番目のミラーを作成する必要があるのはなぜですか？pojoの「冬眠解除」を処理する優れた「推定」フレームワークがあります。
また、サーバー側サービスをJavaコントラクトとして完全には実装しないが、メソッドを実装するサービスインターフェイスを定義するというアイデアは、私には非常にJ2EE 1.x/2.xのように聞こえます。
エラー処理とテスト機能が貧弱な RequestFactory とは異なり (GWT のフードの下でほとんどのものを処理するため)、RPC ではよりサービス指向のアプローチを使用できます。RequestFactory は、複雑なポリモーフィック データ構造を呼び出す必要がある場合に便利なアプローチを提供できる、より最新の依存性注入スタイルのアプローチを実装します。RPC を使用する場合、データ構造をよりフラットにする必要があります。これにより、マーシャリング ユーティリティが json/xml と Java モデルの間で変換できるようになります。Google の Web サイトの gwt dev セクションから引用されているように、RPC を使用すると、より堅牢なアーキテクチャを実装することもできます。
「シンプルなクライアント/サーバー展開
サービス定義を考える最初の最も簡単な方法は、サービス定義をアプリケーションのバックエンド全体として扱うことです。この観点から、クライアント側のコードは「フロント エンド」であり、サーバー上で実行されるすべてのサービス コードは「バック エンド」です。このアプローチを取る場合、サービスの実装は、1 つの特定のアプリケーションに密接に結合されていない、より汎用的な API になる傾向があります。サービス定義は、JDBC または Hibernate またはサーバーのファイル システム内のファイルを介してデータベースに直接アクセスする可能性があります。多くのアプリケーションでは、このビューが適切であり、階層の数が減るため非常に効率的です。
多層展開
より複雑な多層アーキテクチャでは、GWT サービス定義は、J2EE サーバーなどのバックエンド サーバー環境を呼び出す軽量ゲートウェイにすぎない場合があります。この観点から、サービスはアプリケーションのユーザー インターフェイスの「半分のサーバー」と見なすことができます。サービスは汎用ではなく、ユーザー インターフェイスの特定のニーズに合わせて作成されます。サービスは、たとえば J2EE サーバーのクラスターとして実装された、より汎用的なサービスのバックエンド層への呼び出しをつなぎ合わせることによって作成される「バックエンド」クラスの「フロントエンド」になります。この種のアーキテクチャは、バックエンド サービスを HTTP サーバーとは物理的に別のコンピューターで実行する必要がある場合に適しています。」
また、単一の RequestFactory サービスをセットアップするには、6 つほどの Java クラスを作成する必要があることにも注意してください。RPC では 3 つしか必要としないためです。
RequestFactory は、データ プロキシと実際の Java モデルの間でシリアライゼーションをマーシャリングする必要があるため、リクエスト処理中のオーバーヘッドも少し大きくなります。この追加されたインターフェイスにより、エンタープライズ環境または実稼働環境で実際に追加される可能性のある余分な処理サイクルが追加されます。
また、RequestFactory サービスが RPC サービスのようなシリアル化であるとは思いません。
全体として、しばらく両方を使用した後、私は常に RPC を使用します。より軽量で、テストとデバッグが容易で、RequestFactory を使用するよりも高速です。RequestFactory は RPC の対応部分よりもエレガントで拡張性があるかもしれませんが。複雑さが増したからといって、より優れたツールが必要になるわけではありません。
私の意見では、最適なアーキテクチャは、2 つの Web アプリ、1 つのクライアントと 1 つのサーバーを使用することです。サーバーは、servlet.jar ライブラリを使用するシンプルで軽量な汎用 Java Web アプリケーションです。クライアントは GWT です。クライアント Web アプリケーションのサーバー側に GWT-RPC を介して RESTful 要求を行います。クライアントのサーバー側は、サーバー サーブレット Web アプリケーションで単一のサーブレットとして実行している要求ハンドラーへの永続的なトンネルを使用する apache http クライアントへの単なるパスです。サーブレット Web アプリケーションには、データベース アプリケーション層 (hibernate、cayenne、sql など) が含まれている必要があります。これにより、データベース オブジェクト モデルを実際のクライアントから完全に切り離すことができ、アプリケーションを開発および単体テストするためのはるかに拡張可能で堅牢な方法が提供されます。確かに、初期設定には少し時間がかかりますが、しかし最終的には、GWT の外部にある動的なリクエスト ファクトリを作成できます。これにより、両方の長所を活用できます。gwt クライアントをコンパイルまたはビルドすることなく、サーバー側をテストおよび変更できることは言うまでもありません。
唯一の注意点は、RequestFactory が通常の GWT-RPC ではなく、バイナリ データ トランスポート (deRPC かな?) を使用することです。
これは、SyncProxy、Jmeter、Fiddler、または HTTP 要求/応答の内容を読み取り/評価できる同様のツール (GWT-RPC など) を使用して重いテストを行っている場合にのみ重要ですが、deRPC や RequestFactory ではより困難になります。
Hibernate や JPA エンティティを使用している場合など、クライアント側に重い pojo がある場合は非常に役立つと思います。非常に軽量なエンティティを備えた Django スタイルの永続化フレームワークを使用して、別のソリューションを採用しました。
10 ～ 20 個の CRUD 可能なビジネス オブジェクトと、それぞれが 1 ～ 10 個のプロパティを持つ限定的な MIS アプリケーションを検討する場合、どのルートを使用するかは個人の好みにかかっていると言っても過言ではありません。
もしそうなら、アプリケーションがどのようにスケールするかを予測することが、GWT RPC または RequestFactory のルートを選択する際の鍵となる可能性があります。
私のアプリケーションは、比較的限られた数のエンティティにとどまると予想されますが、その数は大幅に増加します。10 ～ 20 個のオブジェクト * 100,000 レコード。
私のアプリケーションは、エンティティの幅が大幅に増加しますが、それぞれに関連する相対的な数は低いままです。5000 オブジェクト * 100 レコード。
私のアプリケーションは、その比較的限られた数のエンティティにとどまることが期待され、さらに、比較的少数の、たとえば 10 ～ 20 オブジェクト * 100 レコードにとどまることが期待されます。
私の場合、私はこの決定をしようとするまさに出発点にいます。トランスポートの選択だけでなく、UI クライアント側のアーキテクチャを変更する必要があるため、さらに複雑になります。以前の (大幅に) 大規模な GWT UI は Hmvc4Gwt ライブラリを使用していましたが、これは GWT MVP 機能に取って代わられました。
私たちのプロジェクトには、GWT-RPC の非常に大規模な実装があります。実際には、それぞれ多くのメソッドを持つ 50 の Service インターフェイスがあり、コンパイラによって生成される TypeSerializers のサイズに問題があり、JS コードが巨大になります。そのため、RequestFactory に向けて分析しています。私は数日間、ウェブを掘り下げて、他の人が何をしているのかを見つけようとして読まれてきました. 私が見た最も重要な欠点は、おそらく私が間違っている可能性があることですが、RequestFactory を使用すると、サーバー ドメイン オブジェクトとクライアント オブジェクト間の通信を制御できなくなることです。必要なのは、制御された方法でロード/保存パターンを適用することです。たとえば、クライアントは特定のトランザクションに属するオブジェクトのオブジェクト グラフ全体を受け取り、更新を行い、全体をサーバーに送り返します。サーバーは検証を行い、古い値と新しい値を比較し、永続化を行います。異なるサイトの 2 人のユーザーが同じトランザクションを取得し、いくつかの更新を行った場合、結果のトランザクションはマージされません。私のシナリオでは、更新の 1 つが失敗するはずです。RequestFactory がこの種の処理のサポートに役立つとは思えません。
よろしくダニエル