Springの上にプラグインベースのアーキテクチャを開発する

Question

私の現在のアプリケーションの1つとして、Springの上に単純なプラグインベースのアーキテクチャを開発することに頭を悩ませてきました。 MVCのようなパターンを使ってどのくらい離れていても、カップリングが避けられないポイントに常に到達します。

したがって、私は計量オプションを開始しました。最初はフィルターが良いと思いました。私が作るすべてのプラグインはフィルターになります。次にフィルター・マップに挿入します。もちろん、これはすべてのフィルタを列挙してチェックするときに少しオーバーヘッドを発生させますが、コントローラはデータに到達する前に何が起こったのか気にする必要はありません。モデルを（DAOやその他のものを通して）取り出し、それらを返す。

この問題は、私のアプリケーションリクエストのすべてがHTTPベースであるとは限りません。いくつかは電子メールに基づいており、他のものは内部的にスケジュールされているため、フィルタはあまり役に立ちません。

もう1つは、アノテーションベースのAOPで、プラグインが特定の規則に基づいてメソッドをインターセプトするすべてのメソッドに注釈を付けることでした。私の問題は、最初は私がAOPによく慣れていないこと、そして第二に、すべての慣習を書いて、すでに少しのカップリングを提案していることです。

私の考え方に最も訴えるオプションは、イベントに基づいています。私のアプリケーション（Webコントローラ、電子メールハンドラなど）内のリクエストハンドラのすべてのタイプは、すべての主要なアクションでSpringイベントをディスパッチするイベントディスパッチャのようなものになります。一方、プラグインは単に特定のイベントが発生したときにリスンして何らかのロジックを実行します。これにより、ポイント＃1も利用できるようになります。そのようなプラグインの一部はフィルタでもある可能性があります。つまり、特定のコントローラアクションが完了したという通知を受け取ったときには、何もしないことを決定し、それらはフィルターチェーンによって呼び出されます。私はこれをやや良いアプローチと見ています。もちろん、ここでは、イベントをディスパッチするオーバーヘッドと、関連するすべてのクラスが永遠にSpringに結合されるという事実がありますが、これを必要な悪とみなしています。

Springイベントに関する私の主な関心事は、遅延、メモリフットプリントの両方のパフォーマンスです。

私はまだ専門家ではないので、ここでのフィードバックはすばらしい助けになるでしょう。この種のアーキテクチャーには春のイベントが最適ですか、私が見逃した別の解決策がありますか？すでにいくつかのサードパーティーのソリューションが存在する可能性があることを知っていますので、誰かが1つまたは2つの実証済みのものを指摘できれば嬉しいです。

ありがとうございました。

Answer 1

プラグインのコンセプトはSpring bean factoryで実現できます。共通インタフェースを作成する場合は、それを実装する複数のBeanを定義し、必要に応じてそれらをインジェクトすることができます。または、ファクトリービーンを使用して、ジョブのための適切なプラグインを提供することもできます。

イベントを使用するあなたの考えは、「イベント駆動アーキテクチャ」と呼ばれます。これはプラグインだけではなく、実装から分離するだけでなく、どのインスタンスが使用されているか（複数のハンドラ）、どの位置（複数のマシン）、およびリクエストが処理されるか（非同期取り扱い）。トレードオフは全体的な複雑さの増加、コンポーネントレベルの複雑さの低減、およびメッセージングインフラストラクチャの必要性です。多くの場合、JMSが使用されますが、単一ノードの設定が必要な場合は、SpringとMuleの両方で簡単なメモリー内モードも提供されます。

さらにお手伝いするには、満たすべき要件と必要なアーキテクチャーを少しでも拡張する必要があります。これまでのところ、プラグインを使用していくつかの可能な解決方法を説明していると述べましたが、達成しようとしていることは実際には説明していません。