1

CQRSと依存性注入を使用しているプロジェクトがあります。システムのクエリ側は問題ありません。

システムのコマンド側では、キューを使用することを選択しました。

BlockingQueue<Command> commandQueue;

これにより、複数のスレッドから引数とともに受信されたコマンドが保存されます。すべてのコマンドは、executeメソッドを使用して共通のインターフェースを実装します。

public interface Command extends Serializable {
    void execute();
}

コマンドの引数は、コマンドインターフェイスの具体的な実装にデータとして保存されます。引数のタイプと潜在的な数は、それが表すコマンドによって異なります。この構造を使用すると、この詳細がすべてコマンドキューロジックからカプセル化されます。

アイデアは、コマンドが内部でどのコマンドであるかを気にせずに、各コマンドで順番にexecute（）を呼び出すワーカースレッドによって後で順番に実行されるということです。

コマンドは、実行の準備ができてキューから削除された後にのみ注入する必要があります（これは主に、コマンドをシリアル化できるようにしたいためですが、コマンドの実行には、受信してキューに入れるアプリケーションの部分とは異なるモジュールが必要なためです）彼ら）

私の問題はこれです： コマンドは依存関係を取得するためにキューから削除されるまで待機する必要があるため、オブジェクトグラフを作成できるように、軽くラップされたインジェクターを「execute」メソッドに渡すことになります。これは、依存性注入というよりもサービスロケーターパターンのように感じます。

public interface Command extends Serializable {
    void execute(**ExecutorLocator locator**);
}

私が見逃しているものはありますか、それともDIがスタックのある時点でサービスロケーターのように見える必要があるのは避けられませんか？

4

1 に答える 1

2

Java コードに手を出してからしばらく経ちましたが、優れたアーキテクチャーと設計は言語に限定されません。

最初: ServiceLocator はアンチパターンです。

2 番目:教えて、聞かないで。外部からコマンドを構築し、ロケーターに依存関係を要求させないでください。

3 番目: コマンドに登録され、コマンドにカプセル化された情報を処理する方法を知っているハンドラーを作成します。したがって、コマンドを挿入したり構築したりする必要はまったくありません。ハンドラーをセットアップし、コマンドがそこに到達することを確認します。

于 2012-08-13T20:52:24.420 に答える