2017-02-26 65 views
0

我使用MVVM作爲表示模型並允許用戶與之交互的WPF客戶端。我一直迴避在實際模型中使用ObservableCollection類(在該模型中選擇IList等通用集合,然後在底層集合發生更改時將該IList轉換爲ViewModel上的實際數據綁定ObservableCollection)。理由是MSDN將該類呈現爲WPF和以UI爲中心的類:我應該在MVVM模型中使用ObservableCollections嗎?

您可以枚舉實現IEnumerable接口的任何集合。但是,要設置動態綁定,以便集合中的插入或刪除操作自動更新UI,集合必須實現INotifyCollectionChanged接口。這個接口暴露了CollectionChanged事件,這是一個在底層集合發生變化時應該引發的事件,應該是 。 WPF提供了 ObservableCollection類,它是實現INotifyCollectionChanged接口的 數據收集的內置實現。

問題:我的區別實際上是否有必要?這是額外的工作和額外的代碼。我明白這個話題可能對於SO來說太模糊和主觀,但也許每個人都有明確的,普遍公認的約定。

回答

4

是的我認爲你做得對。可觀察的集合屬於表示層。將它們添加到您的視圖模型,而不是您的域模型。

This question may be of some help

但也許有明確的,普遍商定的約定每個人都遵循。

請讓我知道,當你找到他們,THX。

+1

很好的回答。這是那些情況下,你不能說絕對沒有,但它是一個非常強烈的「代碼味道」如果我在MVVM模型看到一個ObservableCollection。 –

2

我的區別實際上是否有必要?

這取決於在這種情況下真正的模型是什麼,或者更確切地說是如何定義模型。

如果它是在您的業務或服務層引用的程序集中定義的某種類型的業務對象,並且可能在整個域中使用,則它不應該實現任何類型的客戶端特定接口,例如作爲INotifyCollectionChanged

然後,您應該更喜歡使用泛型類型,如IList,然後在綁定到視圖元素的客戶端應用程序中創建包裝類。

但是,如果模型是僅在您的客戶端應用程序中使用而不在應用程序的任何其他層中使用的類,那麼您還可以將集合屬性定義爲ObservableCollection並直接綁定到此類。

問題是,域業務對象不應該有任何WPF知識或客戶端應用程序可能綁定到它的事實。這就是爲什麼在WPF應用程序中直接綁定到這些對象而沒有將它們首先包裝在WPF感知視圖模型類中是很有意義的。

這確實增加了一些額外的工作和額外的類,但同時它有助於保持這通常是很好的維護問題分離。

在企業場景中,業務對象可能包含不希望公開給客戶端的業務邏輯也很常見,並且它也可能包含其他屬性,因此暴露給視圖是沒有意義的。這樣的話,你仍然需要把它包在另一大類即使集合屬性實際上應該返回ObservableCollection

所以,如果你的問題是「我應該用ObservableCollections在業務對象」的答案是否定的。

相關問題