MVC ||的實際應用何時使用或不使用MVC

Question

我見過ASP.NET社區關於MVC的嗡嗡聲。我知道它的起源基礎知識，並且基於ASP.NET MVC有很多網站（除非我錯了，堆棧溢出本身）。

從我聽過和關於MVC的所有內容看來，它似乎是ASP.NET開發的未來。但是因爲我通常不會涉足.NET Web開發，所以我還想知道以下幾點：什麼時候適合使用MVC，什麼時候不使用，爲什麼？ MVC的巨大（和可怕的）使用的例子會很有趣。
雖然我意識到還有其他MVC實現查看RoR等其他語言，但我更感興趣的是它對.NET程序員的影響。

如果這已經過去了，我的道歉！

Answer 1

這是我的2美分關於MVC的Web應用程序。對於MVC最初設計的那種GUI應用程序，需要「偵聽器」代碼，以便在事件更改模型數據時可以更新UI。

在Web上的MVC中，這是不必要的，您可以免費獲得您的監聽器：Web服務器和HTTP請求是事件。所以真正的網頁MVC應該更簡單。事實上，它可以歸結爲Mediator模式，Controller在模型和視圖之間進行中介。

有兩件事情有很多困惑。無論傳統的「智慧」：

框架= MVC

數據庫數據=「模型」

「全棧」 Web開發框架通常會添加大量功能，並可能會或可能不會是MVC！以他們的核心爲導向。許多框架添加的功能之一是數據庫訪問或對象關係映射功能，並且由於框架和MVC會感到困惑，隨後數據庫數據和MVC的模型面也會變得混亂。通常可以將該模型視爲應用程序的基礎數據，但它不一定來自數據庫。一個很好的例子可能是wiki，其中底層模型/數據由文件修訂數據組成，例如來自RCS。

希望這可以幫助，我相信別人會有很多補充。

Answer 2

ASP.NET MVC不是ASP.NET開發的未來，它只是一種開發ASP.NET網站的新方法。微軟已經明確表示，他們將來會繼續支持和改進WebForms和MVC。

我想不出任何網站，是不是適合使用MVC。你也可以爲WebForms爭辯。

無論你選擇哪一個都是個人選擇，並且取決於開發團隊的經驗和偏好。

在幾個大項目中使用MVC後，我個人絕不會回到WebForms開發。在我看來，WebForms通過http和html放置了一個不必要的抽象層。對於快速原型，您可以使用WebForms更快地獲得拼湊起來的東西，但在此之後，抽象的複雜化使事情變得更加困難而不是簡單。在我看來，使用WebForms的唯一令人信服的理由是當前可用的第三方控件的豐富級別。但是你可以混合使用WebForms和MVC，所以它很容易獲得兩全其美。

Answer 3

我在一家同時擁有ASP.NET和MVC應用程序的商店工作。我認爲最初我偏向於網絡形式，因爲我與他們合作了幾年，但在完成一些MVC項目之後，我更喜歡它。

然而，需要考慮的是，如果您有一個經驗豐富的Web表單開發人員團隊，由於學習曲線的原因，MVC應用程序中的初始進度將會變慢，因此如果項目的時間表非常緊湊，不是轉換的最佳時機。

除此之外，我想不出任何情況下，我更喜歡網頁形式超過MVC在這一點上。

Answer 4

根據我自己的經驗，我可以告訴你，如果你沒有任何Winforms或Webforms背景，你可能會覺得在MVC下更加舒適，因爲你並不是「期望」ASP.NET Webforms中的任何東西世界。另一方面，作爲建議，我鼓勵您查看其他MVC框架，比如Django或RoR，它們在MVC思維方式上更「成熟」。我對ASP.NET MVC感到滿意，但看看其他解決方案可以幫助您更好地理解框架背後的範例。

Answer 5

我會說一個非常引人注目的使用MVC的場景是，如果你有一羣經驗豐富的.NET開發人員不有WebForms的經驗。

我自己從這種情況出發（很少有網絡體驗）我發現它在WebForms上使用MVC的效率和舒適度要高得多。

由於前面提到的抽象，我發現很難提取WebForms - （我認爲WebForms複雜性的證明是我從來沒有遇到過任何人，我會認爲WebForms「專家」即知道頁面生命週期的心臟/數據綁定回到前端等）。

使用MVC實際上允許我使用我的.NET和軟件體驗，而無需大量投資學習WebForms框架。不僅如此，我對HTTP有了更好的理解，而且我認爲這將允許更高質量的解決方案。

恕我直言，MVC允許你比WebForms更好地分解代碼，所以我認爲有很多「模式」體驗的開發人員在MVC中會更加舒適。