DDDおよび非同期リポジトリ
-
05-07-2019 - |
質問
RMIとJMSの両方を使用して、Javaバックエンドに接続されているリッチクライアント(Flexで作成)で作業しています。ドメインオブジェクトのCRUD操作用のリポジトリがあるように、クライアントをDDD形式で実装することを考えていました。
ただし、問題はすべてのバックエンド通信が非同期で行われ、クライアントが応答を受信するまで続行を待機させる方法がないことです。つまり、低レベルでは、リモートオブジェクトのメソッドを呼び出して、戻り値としてAsyncTokenを取得できます。その後、非同期トークンのイベントをリッスンして、呼び出しが成功したか失敗したかを確認できます。ただし、これはリポジトリの背後にある主なアイデアを壊し、クライアントから技術的な詳細を隠します。
2つのオプションがあると思います:
- リポジトリのメソッドにasynctokenを返すようにしますが、これは面倒な解決策のようです
- メソッドが空のコレクションを返すようにします(たとえば、findAllの場合)。これは、応答の受信時に満たされます。
どちらにも長所と短所がありますので、皆さんから意見を聞きたいと思います。
(これをさらに進めると、良いキャッシュ戦略は何でしょうか?状況によっては、すべてのエンティティをリクエストするたびにリポジトリがサーバーを呼び出すことは望ましくありません。リポジトリ。)
解決
FlexおよびFlash Remotingは本質的に非同期であるため、そのパラダイムとの戦いは多くのトラブルをもたらします。サービスデリゲートはすべてのメソッドからAsyncTokenを返しますが、問題はありませんでした。
アプリケーションが新しいビューをレンダリングしたり、結果/エラーが戻ってくるまで他のロジックを実行したりしないようにするには、次のようにします。
- "事後結果/障害コード"を呼び出すカスタムイベントのイベントリスナーを接続します
- 非同期呼び出しを行う
- 結果/障害の処理
- #1からリスナーをトリガーするカスタムイベントをディスパッチします
これは、非同期呼び出しを行うたびに多くの迷惑なボイラープレートコードにつながることに留意してください。同期実行パスが本当に必要かどうかを慎重に検討します。
他のヒント
空のコレクションを返すのは間違っていると感じるので、AsyncTokenを返すことをお勧めします。
キャッシュからデータを返す場合、COMPLETEイベントがサブスクライブされる(そしてハンドラーを削除する)たびに自動的にCOMPLETEイベントをデータで起動するCompletedAsyncToken(:AsyncToken)を返します。
public class CompleteAsyncToken : AsyncToken
{
public function CompleteAsyncToken(data : Object)
{
super(data);
}
public override addEventListener(type:String, listener:Function, useCapture:Boolean = false, priority:int = 0, useWeakReference:Boolean = false) : void
{
super.addEventListener(type, listener, useCapture, priority, useWeakReference);
if (type == Event.COMPLETE)
{
// Don't just execute listener as EventDispatcher is not that simple
super.dispatchCompleteEvent();
super.removeEventListener(type, listener);
}
}
1つの問題は、リポジトリの前にファサードを作成することです。クライアントは、ファサードに対して非同期呼び出しを行い、ファサードに対して同期呼び出しを行います。これにより、ファサードが呼び出しの非同期の側面を管理している間、リポジトリは同期的に動作し続けることができます。