不久之前，我開始爲WPF編寫一個對接庫（類似於Avalon）。那時候我的目標是用MVVM的方式來學習。爲了讓事情順利進行，我決定首先設計模型零件的視圖和，並且認爲我稍後會在之間放入一些視圖模型。現在，我完成了所有視圖和模型的工作：視圖獲取模型並直接與它交談，而模型暴露一系列事件以盲目通知聽衆。而且，它的每個視覺方面都可以在XAML中進行重新設置/模板化。事情工作得很好。現在我被困在視圖模型部分。由於這種類型的庫的性質（內容變化和動態重新創建），還有很多代碼仍然要寫在視圖的代碼隱藏部分中，而且我真的沒有看到也有必要爲每個視圖編寫一堆視圖模型類。也許在幾個地方使用一些綁定/指令會很方便，但我並不認爲它能彌補完成純MVVM設計所需的所有重構。我真的需要MVVM嗎？
我明白MVVM設計的優點，我非常喜歡它，但在這種情況下，我無法看到視圖模型如何爲整個事物增加任何價值。
任何想法，建議或更正將不勝感激。
在此先感謝。
這裏的部分問題是，您正在有效地製作控件庫 - 因此，您正在開發的東西完全屬於MVVM中的「視圖」。儘管你可能會迫使一個MVVM-ish「模型」到位，但它可能會讓你的代碼渾濁起來。請記住，MVVM旨在將應用程序特定的邏輯和數據連接到View - 但在這種情況下，您的「邏輯和數據」就是View本身，就像您正在編寫控制庫一樣。從模型中分離視圖並沒有太多意義 - 因爲模型已經是視圖的一部分了。
我並不是說乾淨分離問題並不重要，但在這種情況下，根據MVVM考慮這個問題可能不太合適。該模型與視圖沒有分離，並試圖完全分離它並在其間添加另一個抽象層可能會增加複雜性而沒有收益。
如果您正在製作自定義控件庫，那麼目標不應該是使用MVVM編寫它，而是要確保您的控件在MVVM應用程序中使用時可以清理。這通常意味着確保你的控件都暴露出所有內容和設置的適當依賴屬性，並且它們與數據綁定等乾淨地工作。事實上，事件通常不是必需的，至少不是那麼多，並且具有單獨的「模型類」層次結構會阻礙用戶的使用 - 用戶希望能夠直接在該控件上放下控件並綁定到屬性，這幾乎可以保證您的控件將有代碼隱藏。
它是一個謬論，自動假定MVVM是恰當的，因爲你正在使用WPF或Silverlight。 MVVM適用於某些類型的應用程序，但控件（或控件庫）不一定就是其中之一。
+1我的想法正是如此。然而，一件重要的事情是：在適用的情況下，使控件「MVVM友好」。我已經處理了很多在MVVM上下文中很難使用的控件，並且最多隻需要子類化，或者最糟糕的是需要「違反規則」，這僅僅是因爲控件設計得不好。 – MetalMikester
@MetalMikester這是我的第4段的整點...;） –
我完全不知道我是如何錯過了第一次閱讀。 *看日曆*嘿，我可以在星期一責怪它！ – MetalMikester
如果代碼背後有很多代碼 - 你沒有以正確的方式使用MVVM，大部分事情都可以用MVVM方式完成 - 通過使用綁定或命令在View或ViewModel中實現。
我無法看到視圖模型如何爲整個事物增加任何價值。
視圖模型提供：
bool IsValid所以視圖c渲染綠色背景而不是紅色（簡化以顯示邏輯封裝和責任授權）我看到它的方式，視圖模型旨在擴展您的模型以迎合您的用戶界面，而不會讓您醜陋起來模型與一堆UI特定的代碼。如果你的模型按照定義被設計爲用於UI構建的對象，那麼它確實滿足模型和視圖模型的角色，並且沒有意義爲設計添加另一層。
我總是理解你的模型只是數據，就是這樣。沒有方法或類似的東西（我甚至沒有在我的模型中實現INPC）
您的視圖模型的目的是以友好的方式向您的視圖呈現數據。所以你不應該直接綁定到模型數據，而是永遠綁定到視圖模型上的數據。
我所做的就是讓我的模型，讓我們說模型是一個Person類，它只是保存這些值而已，如果我想用這個類來綁定，那麼我會創建它的一個實例在我的模型上。但是，如果需要INotifyPropertyChanged，我會創建一個DVM（數據視圖模型），它包含Person類的一個實例，並具有用於在person類中獲取/設置數據的屬性，但也會在需要時引發INPC。這個類還將包含我可能需要的任何UI特定數據。
所以我實現MVVM的樣子
型號> DVM（可選）>視圖模型>查看
的觀點從來沒有直接，只能通過視圖模型談判模型。
我也覺得後面的代碼應該儘量避免使用一個好的MVVM實現。
在回答你的問題是MVVM需要？可能不是，但做得很好我發現一個MVVM應用程序非常容易理解和維護。
我認爲你在MVVM方面的問題可能就是你接近設計的方式。我總是在創建視圖的同時創建空視圖模型類，這樣看起來並不是什麼大事。
有幫助的一件事是與模型沒有1對1映射的視圖。如果您想在一個視圖中顯示來自兩個相關實體的信息，那麼使用該數據填充視圖模型是有意義的。 – Garvin