我很喜歡ASP.NET MVC在很多層面上正在做的事情。什麼是ASP.NET MVC不適合？
我即將參與重建一個流量非常高的網站，我不是哪個框架最好（如果有的話）。
該網站將需要以下內容：
據我所知，沒有理由不使用ASP.NET MVC。
但是使用MVC有沒有潛在的缺點，我沒有考慮過？
我不想成爲挑選技術的人，因爲它很酷，但後來發現它不適合這項工作。
當你所做的一切都是在製作一個需要服務器端代碼的網站時（但對於ASP.NET也是這樣），ASP.NET MVC並不好。
在你的情況，我認爲MVC將是一個偉大的路要走。 MVC已經在高流量的網站（例如這個網站）上證明了自己。但是你必須記住，MVC是新的和變化的。圖書館可能不存在執行特定的任務，這意味着您必須自己編寫該代碼。
祝你好運！
根據你對項目的評價，你很高興與MVC合作。
就我而言，ASP.NET MVC實際上只適用於WebForms中有大量代碼的情況（意味着您有很多ASP.NET用戶控件，自定義控件等）。如果你打算讓那些不知道這是什麼的人工作，那也不好。除此之外，這是一項相當不錯的技術。
我不喜歡ASP.NET MVC的原因如下：
1. 醜陋路由API，有http://ayende.com/Blog/archive/2008/11/05/a-case-study-of-bad-api-design-asp.net-mvc-routing.aspx 是什麼是錯的描述。 順便說一句，友好的URL可以輕鬆無MVC http://demo.liveui.net/bugtracker/Tasks/7
2. 可憐的對象模型來實現。證明好的軟件應該包含可重用的組件。沒有什麼可以在基於ASP.NET MVC的網站中重用。例如，如果您實施了智能下拉列表，則很難再次使用它（即使在同一網站上）。
3. 缺乏控制。某些功能（如TreeView或Menu）已經作爲控件實現，使用mvc重新實現它們將浪費時間。
如果我是你，我會嘗試找到一些CMS並根據WebSite的需要進行自定義。
回覆： 是的。我知道ASP.NET控制的缺點，但問題是關於ASP.NET MVC。可以寫一本關於ASP.NET的好東西和壞東西的書，但我認爲在這裏討論它不合適。
如果它是像這個問題一樣的社區wiki，我會低估它，它的答案應該是。你沒有真正解決他的問題。控件往往有不好的標記。您可以輕鬆地創建可重用組件（嘗試使用Spark而不是Webforms視圖引擎）。您可能在路由API上有一點意思。它可能很醜，但它確實工作得很好。 – 2009-08-04 03:55:22
我的兩分錢：
ASP.NET MVC是一個很好的選擇，但是這牽涉到一點的學習曲線，所以一定要確保你的項目計劃/時間表有這個處理。您的團隊中可能有不熟悉ASP.NET MVC的開發人員，這可能會導致延遲（很多開發人員仍在使用ASP.NET 1.1！）。
@Alex：缺乏控制。某些功能（如TreeView或Menu）已經作爲控件實現，使用mvc重新實現它們將浪費時間。
IMO在ASP.NET MVC中使用控件的想法沒有多大意義。你可以很容易地使用jQuery創建一個treeview控件。經典的ASP.NET服務器控件包含很多行李（視圖狀態等），因此ASP.NET MVC沒有使用任何這些控件（儘管您可以使用助手）。
最後，ASP.NET MVC是替代，而不是Web窗體的替代品。我不會使用ASP.NET MVC，因爲它仍在不斷髮展，我的團隊對此並不是很滿意，但我認爲越來越多的程序員會慢慢轉向這個（更好的）選項。
沒有使用asp.net MVC，有更好的方法來實現MVC。我之前做過，甚至在asp.net MVC上線之前。 MVC是一種模式，而不是技術，我不明白爲什麼有些人稱之爲技術。您可以通過從webforms中移除代碼隱藏並創建您自己的控制器和路由器來分離所有關注點，並且您仍然可以使用大多數asp.net開發人員所使用的webform控件等。 asp.net mvc適合那些沒有時間在webforms環境中正確創建MVC應用程序的人以及那些沒有時間去構建更好解決方案的人。儘管如此，asp.net mvc還不錯，但還有更好的方法，最後，MVC不是一項技術。
加一個這個！ :); – 2013-10-22 07:54:20