4

基本的に、私は常に、公開されている基本型をいつでも返す必要があり、内部で実装の詳細を心配する必要があることを常に理解していました。これは理にかなっています...

しかし、ここで何をすべきかわかりません。基本的に、今私は持っています：

ReadOnlyObservableCollection<Foo> MyFoos {get; private set; }

内部的に観察可能な部分を実際に使用したり、コレクションに書き込もうとしたりすることは決してないため、それを aReadOnlyCollection<Foo>または anとして返す必要があるかどうか疑問に思っています。ICollection<Foo>WPFは私が返すものを気にしないようですが、それでもバインドし、コレクションが変更された通知イベントを適切にトリガーします。しかし、私はどこかで、ViewModel を処理するビューを実際に使用するようにこれを設計する必要があることを読みました。

だから私はここで少し引き裂かれています。ReadOnlyObservableCollection<T>プロパティを使用してできることとできないことを消費ビューに明示的に伝えるには、それを のままにしておくのが最も理にかなっていると思いますが、ダウンタイプをベースタイプに減らす必要があるという印象も受けています。できる。だから私はここで何をすべきかわからない。特に、WPF は私が返す型を気にしないという事実により、それが監視可能であることがわかります。

4

2 に答える 2

8

それReadOnlyObservableCollectionは、ViewModelのコンシューマーがコレクションに対して何を許可されているかを非常に具体的に示しているためです。また、WPFは実際にはコレクションに直接バインドするのではなく、CollectionViewSource.GetDefaultViewの戻り値にバインドします。これは。を返しますICollectionView。契約を結んでいますICollectionView。INotifyCollectionChanged

于 2011-07-29T14:51:07.713 に答える
2

パフォーマンスの観点からは、少なくともItemsソースをINotifyCollectionChangedを実装するコレクションとして使用する必要があります。MVVMには多くの利点がありますが、主に単体テストと関心の分離に関係しているため、ReadOnlyObservableCollectionを使用するかICollection {T}のようなインターフェイスを使用するかは、単体テストの目標に基づいて選択します。

于 2011-07-29T14:51:25.860 に答える