2011-06-13 65 views
2

我正在尋找確認/驗證我所做的事情是否遵循該模式,並且是最佳實踐,或者是有人以口頭形式濫用我提交的內容!做或不​​做。 MVVM中的價值轉換器

如果我在[insert control here]上執行Visibility綁定,我將它綁定到System.Windows.Visibility類型的屬性。然後根據業務邏輯將此值設置爲可見/摺疊。其中一個潛在的缺陷是,我的虛擬機屬性現在直接綁定到我可以看到被抽象爲值轉換器的類型。據說,我經常在MVVM的討論中讀到ValueConverters不應該被使用。

我可以得到一些反饋嗎?

謝謝!

SS

回答

0

我是轉換器的粉絲,但專門用於重複使用。在ViewModel中做這些轉換可能很容易,但是如果你想在許多ViewModel甚至15個不同的應用程序中進行相同的轉換呢?如果你僅限於ViewModel方法,那麼你會違反DRY。這就是說,我不能同意更多轉換器不應該包含業務邏輯,不應該用於「一次性」解決方案。

在上面提到的情況下,它需要在您的ViewModel中具有Visibility類型的屬性,這對我來說是一種代碼味道。恕我直言,ViewModels不應該反映視覺狀態,而是視圖的視覺狀態應該對ViewModel的數據狀態作出反應。

+0

「如果您僅限於VM only方法,那麼您將違反DRY」 - ftw。謝謝! – 2011-06-14 15:51:05

1

這是一個有爭議的話題,但我坐在軍營,在那裏,我認爲你不應該使用轉換器。 ViewModel被認爲是「類固醇轉換器」,所以你不需要任何轉換器。 (http://groups.google.com/group/wpf-disciples/browse_thread/thread/3fe270cd107f184f?pli=1)

如果使用轉換器,你會發現,他們在你的項目中無處不在結束了最平凡的事情。例如:想要顯示「3位顧客」,但如果是「1位顧客」,則沒有複數。在一個視圖模型中很容易做到,但在轉換器中非常繁瑣。

4

我認爲在常見的UI場景中使用值轉換器是完全可以的(例如將可見性綁定到布爾屬性)。但是,僅將它們用於純粹與UI相關的任務:不要在轉換器中放置任何業務邏輯,它不屬於此類。

1

視圖(XAML/WPF)和ViewModel負責不同的事情。因此,如果您操作ViewModel提供的數據,最好在ViewModel中進行轉換。但是,如果您需要純粹的UI元素轉換,那麼視圖是最適合它的地方。

E.G.我認爲可見性是ViewModel的責任,因爲可能存在一些關於正在顯示的業務規則。然而,如果您要更改標籤,複雜性可能應該是UI的責任。除此之外,你可能會決定使用觸發器而不是轉換器。這不應該是ViewModel的問題。

我不相信你不應該使用某些東西,因爲正在使用某種模式。這是一個關於何時應用它的判斷,以及它是否使得代碼可測試,可維護且易於理解,同時提供高質量的應用程序。