約 20 のモデルとコントローラーを含むアプリケーションがあり、特定のフレームワークは使用していません。Flex のパフォーマンスに関して複数のリモート オブジェクトを使用するためのベスト プラクティスは何ですか?
1) 方法 1 - コンポーネントごとに 1 つ- 各コンポーネントはそれ自体の RemoteObject をインスタンス化します。
2) 方法 2 - アプリケーション ルートで複数- 各コントローラーはルートで RemoteObject によって処理されます。
3) 方法 3 - アプリケーション ルートに 1 つ - すべてのコントローラーを 1 つのクラスに結合し、それらを 1 つの RemoteObject で処理する
3 は最高のパフォーマンスを発揮しますが、面倒すぎて維持できず、1 は最もクリーンですが、パフォーマンスに影響を与えると思います。どう思いますか？
ベスト プラクティスは、「上記のいずれでもない」ことです。ビューは、コントローラーまたはコマンド コンポーネントがサービスを呼び出すために使用するイベントをディスパッチし、データが返されたときにモデルを更新する必要があります。ビューはデータにバインドされ、ビューは新しいデータで自動的に更新されます。
私の好みは、取得するデータの異なる部分またはタイプごとに 1 つのサービス クラスを持つことです。複雑なサーバー設定、スキニングに取り組んでいる開発者はモックを使用します)。しかし、実際には、それをどのように行うかは個人の好みの問題です。
では、コントローラーやコマンドが到達できるように、サービスはどこにあるのでしょうか? Robotlegs や Swiz などの依存性注入フレームワークを使用する場合、モデル オブジェクトとサービス オブジェクトのインスタンスのインスタンス化、保存、および返しを処理する別のオブジェクトが作成されます (Robotlegs の場合、コマンド オブジェクトも作成されます)。 Mediator と呼ばれるビュー管理オブジェクトを作成できます)。これらのフレームワークのいずれも使用しない場合は、「自分で作成する」必要があります。これは、アーキテクチャに関心がない場合は少し難しい場合があります。
自分でロールバックする方法を知らない人々 (古いバージョンの Cairngorm を作成した人々など) が頼りにする傾向があるのは、Singleton です。これらは、特に自分の作業の単体テストに興味がある場合は特に、この時代では良い習慣とは見なされません。http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
純粋なパフォーマンスに関しては、これら 3 つすべてがほぼ同じパフォーマンスを発揮するはずです。もちろん、RemoteObject のインスタンスを増やすことでメモリの使用量が少し増えます。また、特定の RemoteObject インスタンスを使用してサーバーに行った最初のリクエストと一緒に送信される余分なバイトがいくつかあります (AMF プロトコルの一部)。 ）。ただし、これらの影響は無視できます。そのため、パフォーマンスではなく保守のしやすさに基づいて選択する必要があるという Amy の意見は正しいです。
所有しているデータの量、サーバーから更新される回数、および更新とクエリをサポートする必要があることに大きく依存します。
番号 3 (および 2) は基本的にシングルトンです。これは、大規模なアプリケーションや大規模なデータセットに最適です。はい、自分で維持するのは複雑ですが、それが人々がフレームワーク (puremvc、cairgorm など) を使用する傾向がある理由です。複雑さの多くは処理されます。フレームワーク内でデータをキャッシュすると、パフォーマンスと応答時間も向上します。
1 の問題は、コンポーネントごとにデータの更新を調整する必要がある場合、基本的にステートレス UI を記述し、各コンポーネントの可視性でサーバーから常にデータを取得する必要があることです。
編集: 私は cairgorm を使用しています - 〜 30 のドメイン モデル (200 程度のリモート コール) があり、ビュー モデルも使用します。一部のモデル (リモート オブジェクト) には数万のオブジェクト インスタンス (レコード) があり、/ ライトバックでキャッシュを保持しています。複雑さはすべてコントローラー/コマンドにカプセル化されています。パフォーマンスは許容範囲です。