8

最新の MVC パターン (2.0?) が Swing フレームワークでどのように見えるべきかの例を示す記事またはチュートリアルを探しています。

また、階層化されたアーキテクチャに慣れているので、ドメイン オブジェクトまたは POJO がどのように図に収まるかを知りたいです。それらが別々であり、モデルによって呼び出されると仮定するのは正しいですか? パターン自体に関しては、クラスをパッケージにグループ化するという点で広く使用されている規則はありますか?

ティア、

ジェームス P.

4

1 に答える 1

26

それは大きな質問です。このテーマについて私が持っているいくつかの考えをあなたと共有し、それから何が生まれるかを見ていきます。

Swingは、Model->View->ControllerよりもModel->Viewです。Model-> Viewの問題は、通常、SwingアプリケーションがViewオブジェクトをサブクラス化し、そのオブジェクトがViewとそのビューのControllerの両方になり、1つにまとめられることです。大規模なアプリケーションでの時間の経過は、多くの問題とスパゲッティコードにつながります。

私がここ数年やっているのは、UIクラスを拡張しないControllerと呼ばれる別のオブジェクトを作成することです。この点では、これは昔ながらのオブジェクトです。このコントローラーは、ビューのトップレベルコンポーネントのインスタンス化、リスナーをビューに接続してユーザーに応答すること、モデルを振り返って呼び出して作業を完了することを担当します。

ビューはSwingをサブクラス化します。ビューは、マウスイベント、キーボードイベントなどに応答する責任があります。あらゆる種類のSwing固有のイベントがビューで処理されます。また、コントローラーがUIを更新するためにコールバックするために使用するビューを更新するための高レベルのメソッドも提供します。コンポーネントの選択は使用するモデルに非常に関連しているため、クラシックスイングモデルもビューの一部です。ビューは、高レベルのイベントをコントローラーにディスパッチすることも担当し、コントローラーはそれらの高レベルのイベントに応答することを担当します。これらのイベントは、UserEvent.ADD、UserEvent.EDIT、AuthenticationEvent.LOG_IN、AuthenticationEvent.LOG_OUTなどです。これらのイベントはアプリケーションイベントであり、製品マネージャーが認識する可能性のあるものに似ています。コントローラがマウスやChangListenerなどに応答しません。Swingを拡張して効果的に使用するのは非常に難しいため、実際にこれらのイベントフレームワークを独自に構築しました。ビューは次のように機能します。

public void mouseClicked( MouseEvent evt ) {
   User u = getUserAt( evt.getPoint() );
   dispatch( new UserEvent( UserEvent.EDIT, u ) );
}

私のコントローラーには、これらのイベントに接続された簡単なメソッドがあります。これがその一例です。

@EventCallback( command = "exit" )
public void exit( AppEvent evt ) {
    onExit();
}

@EventCallback(command = "help.about")
public void showAbout(AppEvent evt ) {
    audioFinderFrame.showAboutDialog(engine.getLicenseInfo());
}

@EventCallback( command = MediaSourceEvent.START_REFRESH )
public void refreshStarted(final MediaSourceEvent event) {
   if( frame != null ) frame.refreshMediaSource( event.getSource(), true );
}

アノテーションは、EventDisptachソースにイベントリスナーメソッドをすばやく追加する必要がある拡張機能です。ただし、重要なのは、コントローラー上の各メソッドが、高レベルのイベントを使用してビューから呼び出されることです。これにより、コントローラーをビューの表示方法からある程度分離することができます。コントローラのログイン方法では、ビューを構成するコンポーネントを気にする必要はありません。彼はただイベントを受け取り、仕事をします。コントローラーは、アプリケーションのフローを担当します。

イベントシステムはSwingから切り離されているため、モデルレイヤーで再利用して、モデルがイベントをコントローラーにディスパッチし、コントローラーがそれらの変更をUIに中継できるようにします。

モデルとコントローラーはPOJOです。彼らは出来事を理解していますが、それだけです。モデルは、DAOのレベル、バックグラウンドジョブを実行する可能性のあるサービス、サーバーと通信するサービスレイヤー、およびほとんどの人がDTOであると言う可能性のあるオブジェクトを含むアプリケーションのロジックです。私は、DTOが単純なゲッター/セッター構造体であるべきだという概念を規定していません。それらはすべてのレイヤーの間に浮かぶ唯一のものであるため、私はそこにいくつかのロジックを許可します。すべてのレイヤーがそれらにアクセスできるため、各レイヤーが再利用できるロジックを一元化するための優れた場所を提供します。View、Controller、およびModelはこれらのメソッドにアクセスできるので、それらの間を移動するオブジェクトにそれらを配置してみませんか。

通常、このロジックはビジネスロジックまたはモデルメンテナンスロジックに近いものです。大規模なアーキテクチャシステムをこれらのメソッドに結合することに注意しています。これらのメソッドは、データベースと通信したり、サーバー側のメソッドを呼び出したりしないため、より大きなアーキテクチャ部分への参照を持ち帰ることはありません。これらには、DTOのすべての利点があります。つまり、軽量で、構築が容易で、依存関係が少ないですが、オブジェクト指向設計の原則であるカプセル化、再利用、および情報隠蔽を維持します。

また、Springを使用して、モデルのパーツと、コントローラーがモデルに持つ依存関係および依存関係を配線することも開始しました。このモデルは非常にうまく機能し、使用しないよりもはるかに快適であることがわかりました。また、Spring JDBCテンプレートやJMSテンプレートなどのテクノロジーを使用している場合は、それらのテクノロジーにアクセスできるのも便利です。ただし、これはオプションです。

コントローラーを再利用することはありません。コントローラーはシステム内で最も具体的なものであり、一般性によってコントローラーの保守が難しくなるだけです。一般性は、開発を容易にするため、ビューとモデルに属します。そのため、デザインパターンはそれらの側にある傾向がありますが、コントローラーにはめったにありません。コントローラーは、前後の単純なメソッド呼び出しです。

これを行うことで、Swing UIの構築がはるかに簡単になり、より簡単になることがわかりました。2つのコントロールを同時に聞いて操作することで、無限のイベントループに陥る可能性は低くなります。また、私のロジックの多くはSwingの把握の範囲外にあるため、システムをテストして分解する方が簡単だと思います。これにより、巨大なツールキットがマウスクリックなどをシミュレートすることなく機能テストが可能になります。

申し訳ありませんが、ここに多くのコードはありませんが、これがお役に立てば幸いです。

于 2010-02-26T01:11:37.197 に答える