3

私の MVC パターンのモデルは、実行時にコンポーネントを生成し、 update() メソッドを介して画面に表示されるように View に渡します (モデルはオブザーバブルであり、ビューはオブザーバーです)。しかし、これらのコンポーネントにリスナーを追加する必要もあり、コントローラーにはリスナー メソッドがあり (MVC パターンはこのようなものであると彼らは言っているため)、この更新プロセスには関与していません。したがって、実行時にリスナーを追加することはできませんが、起動時にコントローラーのコンストラクターにのみ追加できます。

コントローラーをオブザーバーにしてから、データをビューに渡し、リスナーを追加するというアイデアがあります。これでいいと思いますか？

4

3 に答える 3

3

いくつかのワイヤーが交差しているのではないかと思います。

  1. モデルは観察可能です（チェックしてください！）
  2. ビューはモデルを観察しています（チェックしてください！）
  3. コントローラはビ​​ューにバインドされています（TODO！）

＃3は、ビューからのユーザーインタラクションが、コントローラークラスに登録されたリスナーを呼び出し、モデルの状態を更新することになっていることを意味します。

これは「クラシック」なSwingMVCです。 （出典：sun.com）代替テキスト

「変更された」SwingMVC（この質問に関する他のいくつかの回答で推奨されています）では、コントローラーがメディエーターの役割を果たします。

この設計では、ユーザーがアクションを実行すると、ビューはコントローラーの適切なメソッドを呼び出します。次に、コントローラーはモデルにアクセスします（おそらくモデルを更新します）。最後に、モデルが変更されると、関心のあるリスナー（この場合はコントローラー）に通知します。

これは「変更された」MVCです。 （出典：sun.com）代替テキスト

2番目の設計（「変更された」MVC）により、モデルとビューの非常に明白な分離が可能になります。

詳細については、JavaSwingMVCに関するこの記事を確認してください。すごいね。

于 2010-03-16T10:19:36.120 に答える
2

たとえば、スイングでは、コントローラー/アクションリスナーはビュー（ボタンなど）のオブザーバーであり、ボタンを呼び出すと（つまり、ビューが変更されたとき）、コントローラーが起動してモデルと対話し、ビューを再度更新します（新しいモデルの変更で）

だからあなたが最後に提案したことは私にとって理にかなっています:)

于 2010-03-16T10:02:52.233 に答える
2

ええ、コントローラーをモデル オブザーバーにして、ビューを更新できるようにすることは、私の考えでは、MVC の正統性に完全に適合します。

于 2010-03-16T10:00:42.983 に答える