13

私の質問を説明するために、JavaFXコードの簡単な部分を次に示します。

List list1 = new ArrayList();
list1.add("foo");
...

someListView = new ListView<>();
ObservableList someObservableList = FXCollections.observableList(list1);
someListView.setItems(someObservableList);
...

someObservableList.add("bar");

私が正しく理解していれば、setItemsメソッドを呼び出した後、リストの内容がGuiコンポーネントに表示されるだけでなく、その後インスタンスにListViewアイテムが追加された場合、は自動的に更新され、新しく追加されたアイテムが自動的に表示されます.追加のメソッドやメソッドを呼び出す必要はありません。ObservableListListViewaddrefresh

ここまでは順調ですね。しかし、元のリスト (つまり ) に何かを追加するとどうなるでしょうかlist1。これらの変更は自動的に反映されません。それは完全に理にかなっていますが、時には不便です。

もちろん、従来の Java アプリケーションでは、アプリケーションの Model はObservableCollectionインスタンスで構成されていません。そのため、モデルに何かを追加するたびにObservableLists、元のリストから派生したインスタンスを常に更新する必要があります。どうやらこれは必然ですよね？

これは私が疑問に思ったのですが、Model クラスのタイプの出現 (例えば、、、、...) を変更し、今後それらを代替に置き換えるのは賢明なCollectionアイデアListでしょCollectionうか? SetIterableObservableCollection

今までは、これらのObservableCollectionクラスはアプリケーションの GUI レイヤーでのみ使用されると考えていましたが、どこでも使用できると非常に便利なようです。

4

2 に答える 2

6

一般的に言えば、モデル層での GUI ライブラリへの依存は避けます。これにより、再利用の可能性が制限されます。これは、javafx の依存関係だけでなく、モデル クラスで (誤って) よく使用される Point / Rectangle などの AWT オブジェクトにも当てはまります。

理由は簡単です。コードはプラットフォームとフレームワークに限定されます。たとえば、Android は awt などの上記の Java UI レイヤーをサポートしていません。また、ORM は、ドメイン オブジェクト用のカスタム アダプターを必要とするような型で問題が発生する可能性があります。

MVVMパターンのわずかに変更されたバージョンを使用すると、javafx でもうまく機能することがわかりました。あなたの例では、通常の List と適切な propertychange イベントを使用してモデルを設計します。ViewModel はモデルのアダプタとして機能し、ビューをバインドできる ObservableList を提供します。

  • *.fxml ビューの使用: javafx コントローラーを使用する必要があります。これにより、ViewModel へのバインディングが作成されます。
  • コードを使用してビューを生成する: ビューにコンストラクターの依存関係を目的の ViewModel に追加し、ビューでプロパティにバインドするだけです。

ViewModel には定型コードが含まれていることがよくありますが、これは避けた方がよい場合があります。ただし、VM はいくつかの魔法を実行する機会も与えてくれます。つまり、リフレクションを使用して List + Events を ObservableCollection に自動的に生成します。

MVC についての最後の言葉: Swing と javafx は、MVC の方法で使用するように設計されていません (コントローラーがビューにマージされるため)。MVC はコンポーネントに適していますが、MVP と MVVM はアプリケーションに適しています。

于 2013-11-09T14:09:09.760 に答える