我最近對模型視圖體系結構的不同類型進行了一些調查，並且需要決定爲未來內部開發尋找哪一種體系結構。由於我目前在一家擁有ASP.NET技能的微軟商店工作，看起來我的選擇在ASP.NET MVC和WCSF之間（Monorail很可能不在，因爲它不會被Microsoft支持）。ASP.NET MVC與Web客戶端軟件工廠（WCSF）
閱讀the ASP.NET MVC framework, using the WCSF as a yardstick後，我拿起了以下幾點：
有什麼其他的考慮？
我誤解了什麼？
有沒有人使用過這兩個框架，並有任何建議？
ASP.NET MVC不能使用依賴於回發Web控件，而WCSF可以。
你應該想到WCSF作爲有關如何使用現有的WebForms基礎設施，特別是引入模型 - 視圖 - 演示，以協助執行分離關注指導。它還增加了結果代碼的可測試性。
你有過在ASP.NET MVC的網站網址，而不是一個WCSF網站更多的控制權。
如果您的目標是3.5 SP1，則可以將新的路由系統與傳統的WebForms站點一起使用。路由不限於MVC。例如，查看動態數據（也包含在3.5 SP1中）。
ASP.NET MVC站點可能比等效的WCSF版本更容易測試。
這是正確的，因爲它採用了新的抽象類的HttpContext，HttpRequest對象，HttpResponse對象，等有什麼本質上的可測試性的莫過於MVP模式MVC模式。它們都是「分離式演示」的實例，並且都提高了可測試性。
似乎WCSF在某些情況下仍然使用後面的代碼來控制UI事件，但ASP.NET不允許這樣做。
在Model-View-Presenter中，由於外部世界與視圖交互（即URL指向視圖），視圖自然會響應這些事件。他們應該儘可能簡單，無論是通過打電話給演示者，還是提供演示者可以訂閱的事件。
模型 - 視圖 - 控制器通過讓外部世界與控制器交互來克服了這個限制。這意味着你的觀點可能會對非演示事物產生很大的影響。
至於你應該使用它，我認爲答案歸結爲哪一個最適合你的項目目標。有時WebForms和豐富的第三方控件供應商的可用性將會更可取，並且在某些情況下，原始的簡單性和細粒度的HTML控制將有利於MVC。
爲什麼不把兩者都放在Northwind上，看看哪種方式最適合你和你的情況？
你也可以考慮開發者的背景（如果有的話）。
如果他們來自一個嚴格的asp.net的背景下，他們將圍繞WCSF更舒適的（雖然在我的經驗，它仍然把他們幾個星期，真正成爲各地MVP舒服）。如果他們來自java/rails背景，或者之前使用過其他MVC體系結構，那麼顯然他們會更開心（並且根據我的經驗，除了MVC之外，其他任何事情都會變得非常流行）。
我們在做完全相同的評估後選擇了WCSF。我們覺得MVP模式給了我們更多的選擇，例如使用服務器控件的能力。我們的開發團隊大多由來自多種學科（如C++，Biztalk和Web等）的程序員組成，但他們都專注於MS類型開發，所以採用模式的學習曲線並不像我們的團隊那麼重要。
我們非常滿意我們的選擇。
不開始一場火焰戰爭，但我發現WCSF是相當複雜的。 MVC的優雅和簡潔吹走了MVP，這感覺就像是剛剛移植到webforms上的模式。
MVC是一個更簡單的模式，更類似於所有其他框架怎麼做Web開發。 WebForms僅僅是太多的跳躍和過多的抽象層次來嘗試實現簡單性。 恕我直言，MVC將在幾年內成爲默認的ASP.NET架構，因爲越來越多的人意識到它帶給我們的簡單易用的開發和測試。我一直在做MVC開發一年半，甚至不會想到回到一個新項目的WebForms。
一個ASP.NET MVC的網站可能會更容易比同等 WCSF版本進行測試。
這是正確的，因爲它採用了新的抽象類 的HttpContext，HttpRequest對象，HttpResponse對象等沒有什麼本質上 更易測試的莫過於MVP模式MVC模式。 他們都是「分離演示文稿」的實例，並且都增加了可測試性 。
這可能是有爭議的，但有文獻表明，如果您有視圖是邏輯打包的，那麼使用MVP設計模型更容易進行單元測試，然後使用MVC設計模型。總而言之，在MVP設計模型中，Presenter正在處理可能由MVC設計模型中的View處理的工作。可能包含在MVC視圖中的邏輯不便於單元測試。以下是我已閱讀的文獻的一些參考資料，其中涵蓋了這個概念，以及爲什麼保持您的View輕量級更好的原因包括促進單元測試等多種原因。
http://martinfowler.com/eaaDev/uiArchs.html
你還滿意這個決定嗎？似乎WCSF已經被MS逐步淘汰，而MVC越來越受歡迎。謝謝。 – 2014-05-28 15:16:10