我已經開發了幾年的web應用程序，使用了ASP.NET Webforms，我仍然喜歡它，首先是因爲RAD的可能性， 它提供。自兩年後，ASP.NET MVC現在可以作爲傳統ASP.NET的直接競爭對手。不知何故，我不想扔掉我所有的Webforms體驗，並轉移到ASP.NET MVC。一個原因是，我也處理桌面應用程序開發和ASP.NET Webforms更類似於它。作爲ASP.NET Webforms和ASP.NET MVC的共生作用的ASP.NET MVP
現在我發現有對ASP.NET開發第三種方法：ASP.NET MVP： http://webformsmvp.com/
有誰已經與該第三類ASP.NET的經歷？
這是微軟的官方做法，分別是微軟支持嗎？
是否值得對其進行更詳細的瞭解？
它是ASP.NET「世界」的有希望的組合嗎？
這顯然是一種主觀意見，它取決於你正在解決的特定問題。
如果你有一個簡單的應用程序，這將不需要大量的持續維護，並且顯示快速結果非常重要，我認爲使用MVP完全是你提到的原因是有意義的 - 利用團隊技能組合和RAD。
對於任何更復雜的事情，我不認爲這是個好主意。如你所說，MVP與桌面GUI模型類似; ASP.NET MVC被設計用於Web的請求響應特性。視圖體系結構（特別是EditorFor和DisplayFor的引入）經過優化，可用作從模型中提取數據的模板。
從可測試性的角度來看，MVC在允許您單元測試小型組件方面做得非常好。我認爲，隨着觀點和主持人的聯繫更加緊密，您將會因爲MVP而失去很多優勢。實質上，MVC採用了「低級對話框」模式的概念，該模式旨在最大限度地減少UI代碼，因爲它本質上是不可測試的。 （ASP.NET）MVC也包含了網頁，生成乾淨的HTML設計爲CSS樣式和用javascript（jquery）增強。我認爲MVP鼓勵你將這個視圖看作是一個「小部件」的畫布，它總是最終產生你必須與之戰鬥的標記。最後，我認爲無論何時您使用一個旨在支持一種方法（MVC）並略微改變它（MVP）的平臺，您最終都會向上遊游泳。您無法利用圍繞主流方法自然設置的建議，文章和技術開發。例如，我個人寧願使用替代視圖引擎和MVC來代替WebForms引擎。但是我沒有采取這一舉措，因爲它不符合標準。有時候「標準」比較好。