我瞭解MVVM在大型團隊長時間開發收縮包裝應用程序的上下文中的實用性。但是在內部LOB應用程序的上下文中，MVVM看起來有點矯枉過正，而且我無法吞噬調試數據綁定的開銷，從一層一層跳到另一層，以及使用一兩個命令提取幾乎不超過模型的虛擬機。即使接受這種開銷，仍然留下了MVVM中像對話框一樣的空洞。有幾件事情我已經考慮是：適用於WPF的輕量級視圖模型
上述項目及其組合解決了一些問題，但不是全部。我意識到我可能會犧牲可測性。我還會遇到哪些其他技術（不是概念上的SOC）問題？
想到代碼重用性。正確編寫的虛擬機可以在Silverlight或WP7實現之後重新使用。
在這種情況下，這不太可能，但這是一個好的觀點。 –
在WPF或Silverlight中編寫代碼時，我總是使用MVVM，即使是小型的單頁應用程序。從長遠來看，它使測試和維護變得更加容易，我發現使用它創建應用程序比使用它更快。
我不介意在較小的應用程序中使用某些快捷方式，例如綁定到Model在ViewModel中公開Model的屬性，或者在DataTemplate而不是UserControl中定義視圖，或者在ViewModel中使用Window的對話框，但我絕不會考慮在沒有MVVM的情況下執行WPF或Silverlight應用程序。
如果你想，我有MVVM做了一個非常簡單的應用程序的一個例子here
我與包括這樣的所有樣本的鬥爭： –
我與所有樣本包括這樣的：http://msdn.microsoft.com/en-us/magazine/dd419663.aspx和這：http://code.msdn.microsoft.com/How-to-implement-MVVM-71a65441都是非常簡單的例子。諸如對話框，等待遊標等的東西正在被社區敲定，但即使在我找到一個可接受的解決方案的地方，我也無法將30行代碼添加到我的框架中，這些代碼可能是Winforms中的一行代碼環境。 –
雖然有像您在使用MVVM時得到的，記住，MVVM是關注和代碼複用分離的好處主要是關於能夠獨立於實際視圖測試您的業務邏輯。如果您的應用程序的單元測試對項目很重要，那麼MVVM是一個不錯的選擇，可能值得相關的「開銷」。 – Oppositional
我不同意。視圖模型不應該有業務邏輯，它們包含與ui相關的邏輯。我們的業務邏輯/模型層已經過單元測試。但是與在典型的收縮包裝或商業產品中發佈相關的成本幾乎不存在於內部LOB應用程序中，因此我們認爲單元測試UI幾乎沒有意義，這使我們在這個地方也想知道MVVM的有用性最純粹的形式。 –
我不同意，ViewModels絕不應該包含UI邏輯。任何與UI相關的內容（例如設置焦點或運行動畫）都應在後面的代碼中完成。 ViewModels應該包含業務邏輯，例如加載/保存數據，並且它們應該控制應用程序流程，例如更改ViewModel是當前活動屏幕還是返回錯誤消息。您的ViewModel是您的應用程序，而Views只是一個非常漂亮的UI，可以讓用戶輕鬆地與ViewModel進行交互。 – Rachel