在代碼背後使用Presentation Model的主要缺點是什麼？

我正試圖爲自己準備好面對以下問題提出挑戰：在代碼背後使用Presentation Model的主要缺點是什麼？

「爲什麼我們不能在後面的代碼中實現演示模型？

其實我已經在這裏我們使用的是在代碼實現之後的演示模型的一個項目工作。它工作得很好，我們甚至可以對它進行單元測試。是的，你在單元測試中依賴於WPF ......但它確實有效！

那麼，使用代碼背後的主要缺點是什麼？

我更喜歡獨立ViewModel（MVVM）的想法，但目前我覺得無法爲客戶辯護。

來源

2010-01-31 Schneider

您回答了問題的第一部分，必須在單元測試期間引導wpf應用程序。另一個是可移植性，你是否希望能夠將不同的視圖實現附加到相同的表示模型。（弱，但我知道它的你得到）

而且技能形式的分離，只有知道XAML開發人員將在視圖中的實際creartion參與。允許您利用不知道wpf的家庭天賦。

來源

2010-01-31 13:52:08

直接的答案是principle of separation of concerns。當然，有人可能會爭辯說，通過將代表模型置於代碼隱藏中，它與視圖（XAML）是分開的，但我不同意這一點。代碼隱藏可以「查看」視圖的所有內部細節，因爲它的是的視圖。 xaml和代碼隱藏都被編譯到一個類中成爲視圖。他們根本不分離。

有很多的例子，你必須進入後臺代碼做視圖相關的東西，這樣你就不能在XAML中指定控件之間掛鉤的相互作用。一旦你這樣做了，你現在已經將你的視圖邏輯與你的表示邏輯混合了。

ViewModel的概念非常強大。視圖模型可以在沒有視圖彼此「交談」的情況下彼此「交談」，甚至沒有ViewModel「知道」視圖的任何內容。

來源

2010-01-31 15:21:52

不錯，但我到目前爲止沒有找到任何答案*非常*引人注目......似乎有一個很大的心理方面。據推測，後面的紀律代碼會正常工作？猜猜這會是迫使較少的高級開發人員做正確的事情的好方法 – Schneider 2010-01-31 23:36:07

@Schneider：就像你可以直接用C語言而不是C++或C＃編寫面向對象的代碼一樣，是的，它可以正常工作。 ;） – 2010-02-02 01:02:21

查看這兩個視頻來得到一些想法。這兩個視頻都顯示了開發應用程序，從代碼背後的所有內容開始，然後重構爲MVVM模式。

Mike Taulty's series of videos（其實有總共10個視頻，檢查至少第一和第二）
Jason Dolinger on Model-View-ViewModel

另外，請參見對多個鏈路此SO問題：MVVM: Tutorial from start to finish?

來源

2010-01-31 15:43:50 zendar

它當您使用ViewModel-First的方法時，成爲一個缺點。在主應用程序中實例化ViewModel對象圖，將其分配給根視圖datacontext，然後讓視圖根據ViewModel通知呈現其相關子對象。

爲什麼它是一個缺點？你可以使用你的代碼背後的事實，但你會以tricks和forgot your application security一段時間結束。但實際上，這種方法是最理想的方法，您的視圖模型完全無知，即使您可以通過程序的第一個皮膚來反轉您的開發過程。在另一方面（開玩笑）

如果使用查看，首先的方法，那麼就沒有缺點，因爲視圖模型坐在上面。 ~~因爲控制仍然在視圖中，如果你需要一些棘手的東西像使用密碼框那麼就自然而然就像微軟命運我們一樣。~~

希望它有幫助。

來源

2010-08-12 06:57:17 ktutnik

在代碼背後使用Presentation Model的主要缺點是什麼？

回答

相關問題