0

私はフレックスでのリモーティングに非常に慣れていません。私はflex4.5を使用しており、AMFを使用してチームの他の誰かが作成したWebアプリケーションと話し合っています。彼らはZend_AMFを使用してデータをシリアル化および非シリアル化しました。

私が現在直面している主な問題の1つは、多くのサービス（約60程度）と話す必要があるということです。

オンラインで見たリモーティングの例とadobeから、各サービスのリモーティングオブジェクトを定義する必要があるようです。

<mx:RemoteObject id="testservice" fault="testservice_faultHandler(event)" showBusyCursor="true" destination="account"/>

非常に多くのサービスがあるので、そのうちの約60を定義する必要があると思いますが、これはあまりエレガントではないと思います。

同時に、AMFエンドポイントをテストするためにPintaで遊んでいます。Pintaは、これらの制限なしに、任意の量のサービス、メソッド、およびパラメーターを定義できるようになっているようです。ソースを掘り下げてみると、彼らは実際にリモーティングを深く掘り下げており、多くの低レベルのものを処理していることがわかりました。

したがって、問題は、負荷やリモートオブジェクトを定義する必要がなく、深く掘り下げて低レベルのリモートイベントを自分で処理し始めることなく、この問題に取り組む方法があるかどうかです。

乾杯

4

1 に答える 1

1

アプリケーションがこれほど多くのRemoteObjectを必要とするのは珍しいようです。私は非常に大規模なアプリケーションに取り組んできましたが、通常、6〜10個のRemoteObject宣言しかありません。

RemoteObjectsのバリエーションについては、投稿に多くの詳細を記載していませんが、と混同RemoteObjectしている可能性がありますOperation。

通常、アプリケーションのすべてのエンドポイントに対してRemoteObjectインスタンスを宣言します。ただし、そのエンドポイントは、呼び出されるさまざまなメソッドを公開できます（通常は公開します）。これらのサーバー側の各メソッドは、クライアント側で結果を取得しますOperation。

Operation必要に応じてこれらを明示的に宣言できますが、宣言しない場合はRemoteObjectがsを作成します。

 var remoteObject:RemoteObject;
 // creates an operation for the saveAccount RPC call, and invokes it, 
 // returning the AsyncToken
 var token:AsyncToken = remoteObject.saveAccount(account); 
 token.addResponder(this); 
  //... etc

単一のサーバーレイヤーを操作している場合は、多くの場合、API上の単一の宛先を指す単一のRemoteObjectを使用して、多くのメソッドを公開できます。このアプローチは、APIファサードと呼ばれることが多く、APIへの確実な依存性注入の規律に裏打ちされている場合に非常に役立ちます。

もう1つの一般的なアプローチは、論理的なビジネス領域（AccountService、ShoppingCartServiceなど）ごとにAPIメソッドを分離することです。これには、サービス間でプロトコルを組み合わせて一致させることができるという利点があります（たとえば、AccountServiceはHTTPSで実行される場合があります）。

これらのRemoteObjectをどのように分割するかはあなた次第です。ただし、単一のアプリケーションで60を使用することは、私には少し疑わしいと思います。

于 2011-10-18T11:57:07.433 に答える