バスで何を通知する必要があるか (JMS と概念は似ていますが、はるかに単純なアプリケーション全体のメッセージ システム)、直接リスナーを使用して何を通知する必要があるクライアント側のスイング アプリケーションを構築しますか?
バスを利用していると、いつも「誰がどこで使っているのかわからない」という気持ちが拭えません。また、決まった順序がなく、イベントを拒否するのが難しく、決まった時間に何が起こっているのかを正確に知るのが難しい.
一方、リスナーを使用するということは、ソース オブジェクトを直接参照する (カップリング) か、無数の変換 (A--b_listener-->B、B--c_listener-->C のみを介して参照を渡すこと) を意味します。 Cは言うことができますが、Bは興味がありません）。
それで、これに関する経験則はありますか？バランスをとる方法について何か提案はありますか？
私の経験では、Swing が設計されていないこと、または実行してほしくないことを Swing に実行させようとするのは、非常に苦痛です。
機能する最も単純なものを使用します。コードをきれいに保ち、問題が発生し始めるまで「Swing Way」を実行してください。
イベント バスは、特定のアーキテクチャでデカップリングを提供するための非常に便利なツールです。リスナーは簡単に実装できますが、オブジェクトと依存関係グラフが大きくなると、大きな制限があります。リスナーは、周期的な依存関係の問題に遭遇する傾向があります (イベントは奇妙な方法で「バウンス」する可能性があり、行き詰まらないようにするためにゲームをプレイする必要があります。ほとんどのバインド フレームワークはこれを行いますが、何か不快なことがあります。リスナー イベントが 100 万の場所に向けて発射されていることを知っています)。
このような決定は、プロジェクトのサイズとスケーラビリティに基づいて行います。それが大きなアプリであるか、動的にできるアプリの側面 (プラグイン モジュールなど) がある場合、バスはアーキテクチャをきれいに保つための良い方法です (OSGI のようなモジュール コンテナーは別のアプローチですが、より重い重量）。
バス アーキテクチャを検討している場合は、 Event Busプロジェクトを参照することをお勧めします。これは Swing と非常にうまく連携し、求めているものに対して堅牢ですぐに使用できるソリューションを提供します。
Java Swingの規則は、リスナーを多用することです。慣習に固執することは保守性を改善しますが、革新を抑制します。
Swingでバスのアプローチに出会ったことはありませんが、面白いと思います。
さて、モデルがBUSのようなシステムを使用して更新され、モデルからのイベントがリスナーを使用して委任されるアプローチを想像することができます。単純なシナリオ：データのプロデューサーを表すサーバー側を取得しました。次に、クライアント側で、すべての着信メッセージを消費し、それらを内部メッセージ/ DTOに変換してバスにプッシュし、アプリケーションモデルに配信するコンシューマーインターフェイスを取得します。これらのモデルは着信メッセージを処理し、リスナーを使用して関心のあるコンポーネントに通知することを決定します。