MVC是編寫asp.net應用程序的最佳方式嗎？

Question

更新：我知道沒有最好的辦法來做任何事情。對不起，沒有說這一點。在數據訪問教程的上下文中，如果您必須執行他在該教程中所做的項目，那麼如果您必須選擇其中的一個，您會使用MVC嗎？

更新：是MVC更合適的方式來編寫asp.net應用程序，而不是在這裏找到教程：

http://www.asp.net/Learn/data-access/

原文：

我問，因爲我最初通過Java應用程序學習了MVC，然後學習了RoR和Django。這些其他項目和公司都認爲MVC已經存在了很長一段時間，並且從我發現的情況來看。然後微軟開始將MVC放入.net框架中。

我問，因爲我不知道如何設計的東西很好，並認爲我很好地模仿了Scott Mitchell的教程在asp.net網站上的內容。我認爲在BLL中創建抽象層是我發現MVC和現在的asp.net MVC的方法。

我真的不知道「正確」的做法是什麼。我只是創造我需要的東西，但我不禁感到我缺少一些東西。

MVC是在大型項目中開始做事的正確方法，具體來說我的意思是MVC和ASP.NET，但也意味着PHP和他們的MVC框架之一。

我想解決一個標準的做事方式......現在無論如何。

而出於好奇，爲什麼微軟現在纔開始做MVC？

更新： MVC比當前在asp.net上設置的教程更好嗎？

我指的是Scott Mitchell教程，他在那裏創建了抽象BLL。或者這也是一個linq問題。我應該說，我理解需要保持邏輯和表達分離，但不確定最好的方式。我正在使用asp.net教程。它運行良好。然後，我發現世界其他地方，正如我看到的那樣，正在使用MVC。然後微軟開始開發MVC，所以對我來說，另一種方法似乎已經過時並且是錯誤的做法。

Answer 1

不，它不是唯一最好的辦法。

MVC只是一種設計模式。所有設計模式的目標都很簡單。所以只要它讓你的設計更簡單，就隨它吧。如果它使事情對於特定應用程序更復雜，請嘗試不同的方法。

不幸的是，有些人認爲如果他們看到一種模式，他們應該使用它。這是不正確的。設計模式本身並不會使您的應用程序更好。他們不是目的。他們是達到目的的手段（這很簡單）。所以你應該只在他們值得的時候才使用它們。

在我看來，沒有一個好理由的過度架構的東西比編寫沒有任何特定設計的代碼更糟糕。

編輯：關於ASP.NET MVC：我對ASP.NET Web窗體有負面的個人偏見。在MVC之前，我通過編寫自定義處理程序對HTML進行細粒度控制，從而完成了高級項目的大部分動態方面。 Web Forms使Web開發變得非常簡單，但他們特別有一些很好但有時有問題的事情。其中第一個是ViewState，第二個是複雜的WebControl體系結構。不要誤解我的意思。這些都是ASP.NET的輝煌跡象。我還沒有看到像ASP.NET Web Forms一樣簡單的Web開發平臺，這只是因爲WebControl支持需要ViewState。但是，在某些項目中，您希望對呈現的HTML進行精確控制（特別是當您有一些客戶端邏輯時）。您還希望在大型項目中維護服務器端代碼。在這些領域，ASP.NET MVC真的很閃耀。但是我認爲ASP.NET Web Forms將會是一個更適用的優秀技術。畢竟，正如我所說的一般設計模式，您應該仔細評估您的設計，以查看哪一個更適合您的需求。

具體而言，關於數據訪問，MVC通常比Web Forms對應的代碼需要更多的代碼。爲了呈現表格數據（即GridView適用），我認爲ASP.NET Web Forms是完成任務的更簡單的方法。但是，大多數數據驅動的Web應用程序不僅僅是直接在數據庫中操作表。他們有複雜的佈局。 StackOverflow就是一個很好的例子。這當然是數據驅動的，但ASP.NET MVC更適合它。

Answer 2

MVC只是一種處事方式。我喜歡它，因爲它有助於提高可擴展性，並且允許測試和代碼重用。沒有銀彈，一種真正的做法，但我經常使用它。

關於微軟，我會說他們採用了這種模式作爲WebForms開發的替代方法，這是因爲我上面提到的原因。我會建議看看Rob Conery's MVC Storefront以及各種實例來看看它是如何工作的。

Answer 3

沒有「正確」的方式去做事情而不知道「事情」是什麼。 MVC是一個design pattern，它解決了一個特定的常見問題 - 表示和領域邏輯的分離。每種設計模式都是針對特定問題的普遍接受的「良好」解決方案。

這些解決方案與知識和經驗相結合是優秀設計的基石。做事的「正確」方式是研究您的問題領域，研究可能的解決方案並應用最適合解決問題的解決方案。犯錯誤也是這個過程的一部分，所以不要害怕嘗試，然後嚴謹地對待，直到你達到最好的解決方案。

Answer 4

MVC是開發應用程序的最糟糕的方法，除了所有其他嘗試過的方法。 :-)

開玩笑說，MVC是一種鼓勵我們不寫意大利麪代碼的應用程序設計。這是一條指引，提醒我們將業務代碼與演示代碼分開。隨着應用程序變得越來越複雜，這非常有用。

還有其他的變化，實現同樣的好處，但不是嚴格相同的MVC。 Presentation-abstraction-control（PAC）就是一個例子。至於爲什麼微軟採用MVC這麼晚了，我並不感到驚訝。他們非常知名（至少在最近幾年）是因爲保守而不是創新。他們更願意讓其他小公司在未經證實的市場中冒險，然後從錯誤中吸取經驗教訓，製造出過度工程化的競爭對手解決方案，並通過市場營銷主導。

示例：Microsoft Internet Explorer被認爲是瀏覽器市場的後來者。 Netscape已經非常流行，爲人們提供查看HTML的平臺提供了方式。一旦互聯網上的HTML內容數量達到了有用的水平，微軟就會大量使用它們的擬聲詞「IE」產品，並迅速佔據絕對的市場份額。

Answer 5

沒有「最好」的方式來編碼的東西。這取決於有問題的應用程序;有時MVC是正確的選擇，有時不是。一個良好的開發是能夠衡量他/她的選擇，選擇一個最好適合於手上的工作，而不是隻與方法去大談特談

Answer 6

如果MVC解決了管理的主要技術勢在必行在您的應用程序中的複雜性，那麼它可能是一個很好的解決方案，但它絕不是唯一的解決方案。

Answer 7

MVC是任何設計模式之一。無論是最好的技術，還是最簡單的，或者適合哪種類型的項目，都是有爭議的（參見其他SO線程）。無論如何，很少有人會反對普遍的共識，即在大多數情況下，它是「夠好的」。

但它有不可否認的好處，很多人在很多不同的平臺上使用它。

所以，如果你想使用一種方法，可能會在一段時間;或者你不想依靠一個供應商來支持和擴展和改進;或者你在一個小組中工作，他們希望通過聘請來自不同背景的人來快速培養一種共享的方法;或者如果需要的話，您希望最大化機會繼續前進，那麼MVC是支持這些目標的最佳途徑之一。

Answer 8

MVC爲「較好」或「較差」模式與項目有關。