羅伯特馬丁說：「應該永遠不會有一個班級改變的原因」。
讓我們考慮綁定到視圖的ViewModel類。這是可能的（或者甚至可能），ViewModel由不相互關聯的屬性組成。對於小視圖，ViewModel可能非常連貫，但是當應用程序變得更復雜時，ViewModel將公開可能會因爲不同和不相關的原因而改變的數據。
我們應該擔心ViewModel類的SRP原理嗎？如何在MVVM中構建ViewModel不違反單一責任原則？
ViewModel的單一職責是提供查看所需信息。如果視圖需要不同的和不相關的屬性並不重要，因爲ViewModel只有一個改變的原因，那就是顯示不同屬性的視圖。所以你不應該太擔心。這就是說，如果ViewModel確實變得很龐大，也許你可以考慮將視圖分成幾個子視圖來提高可重用性並保持Views和ViewModel的可管理性。
是的，但這並不意味着糟糕的設計不能強迫你進入它。
我同意gcores。
一旦你看到ViewModel增長到超過兩個屏幕的文本，是時候考慮將ViewModel分成幾個子模型。另一個經驗法則是，我從來沒有在XAML文件中有兩層以上的嵌套 - 如果視圖的一部分變得太複雜，那麼視圖重構就是時間 - 將內部XAML提取到單獨的UserControl中並創建對應的ViewModel，它將作爲子視圖的默認數據上下文。
我同意用多個ViewModels將您的屏幕分割爲多個視圖是減少膨脹和複雜性所必需的。下面是我用來幫助使用MVVM堅持使用SRP的另一種模式：
以下是一種情況。我的ViewModel需要獲取數據並響應UI中的過濾器命令。我創建ViewModel是結構複合的。也就是說，有權訪問ViewModel的私有成員的子類執行線性任務，例如處理過濾。我可能還有另一個子類，它根據標準執行選擇項目的必要邏輯。你明白了。一旦ViewModel執行跨越幾種方法的某些功能，它可能是委派給子類的一個很好的候選者。子類仍然是主ViewModel的一部分，所以它只是減小ViewModel大小的一種方法，並使單元測試這些線性操作變得更容易。