我正在爲我的客戶端在經典的ASP應用程序上進行一些維護，並且在瀏覽ASP時，會想到以下問題 - 將傳統的ASP應用程序轉換爲ASP.NET MVC還是更容易一些？ ASP.NET WebForms？遷移經典ASP - Webforms或ASP.NET MVC？
從很多方面來看，似乎至少ASP的HTML可能更容易轉換爲MVC，而不是將HTML塊拆分並轉換爲ASP.NET控件，中繼器，數據網格等。必須添加ViewState的處理和邏輯等，可能會增加工作量。
我不認爲我的客戶會要求這樣的升級，所以這只是理論上的。
我們假設這個ASP代碼編寫得很好（當然並不總是這樣），問題是，一個設計良好的ASP網站會比WebForms更好地遷移到MVC嗎？ （請注意，我對ASP.NET MVC非常陌生，所以我可能會錯過這裏至關重要的東西）。
這很大程度上取決於經典asp應用程序的結構。
與HTML混合在一起的服務器標籤與asp.net mvc類似，但是MVC不會太雜亂（或不應該是）。您可以將經典的ASP演示文稿代碼移動到MVC視圖，而不是Web窗體。另外經典的asp應用程序通常是在考慮到web的無狀態的情況下開發的。您的經典asp可能沒有與postabacks或viewstate匹配的任何內容。經典ASP也使用普通的html元素，而不是asp.net webform控件。在這些方面，它比MVC更接近webforms。
如果你不知道asp.net webforms或asp.net mvc，我會說MVC是要走的路。
如果你很瞭解webforms並且對MVC知之甚少，那麼我會說webforms是最好的選擇。
但是，如果您的客戶由於某種原因確實希望重新開發網站，我會說與MVC去。只要您能夠交付，讓客戶爲您的體驗開發的一部分付費總是不錯的。
另一方面，當我遇到一位希望我在他們的經典asp網站上工作的客戶時，我總是感到吃驚。在每一個案例中，該網站都是一團糟。更糟糕的是，他們通常充滿了巨大的安全漏洞。
ASP.NET-MVC比視圖代碼和ASP內聯代碼之間的明顯相似性還要多。要考慮所有的模型和控制器部分，這與大多數ASP編寫的方式有很大不同。
這就是說我會說MVC將是最好的開始。
IMO WebForms嘗試爲我的喜好過多地隱藏HTML，並可能導致您的項目花費比您想要的更長的時間，因爲將大量html轉換爲webforms控件。
另一方面，MVC允許您重複使用某些邏輯，同時使您的應用程序更易於維護，並且使用適當的架構模式，您的應用程序可以比任何WebForms項目更快地開發和重構。
我說MVC一路！
我認爲在很多情況下，轉換爲MVC可能比Webforms更容易。大多數傳統的ASP應用程序顯示的問題很少分離，所以最大的任務可能就是將數據訪問，業務邏輯，業務實體和UI組件的邏輯分開。在此過程中，將內聯ASP代碼轉換爲視圖，將業務邏輯轉換爲控制器以及將業務實體轉換爲模型會更容易。
我不認爲一個會更容易轉換然後另一個。
如果您希望在代碼隱藏中放入一些可以在aspx中訪問的關鍵元素，則可以將ASP.NET編碼與代碼ASP幾乎相同。沒有數據綁定，沒有gridview，也沒有中繼器。視圖狀態可以幫助您輕鬆搞清楚，如果您不想使用它，則無需使用它，並且可以在web.config中關閉該視圖狀態並使用頁面屬性打開它。 Web表單也有一個AspCompat模式允許訪問請求和響應對象或asp，這將允許逐頁轉換，如果需要的話。
對於MVC.net，顯示HTML的方法非常相似。在我看來，這是相似之處的結局。你仍然需要將你所有的邏輯分解到MVC模型中。
來自ASP並轉到Web.Form和現在的MVC。網絡我可以告訴你，WebForms有點令人討厭/令人沮喪，90％的MS教程告訴你IE最糟糕的習慣（頁面上的SQL連接，在設計器中拖動數據集）。然而，一旦你過去了，那個人可以更快地做很多事情，然後在asp中（分頁或者編輯一個簡單的數據表，例如編輯），但是我仍然沒有看到過一個n層的大型webforms項目我認爲易於遵循的設計，實施和使用。
MVC.NET就像天賜之物。它迫使你的喉嚨模式和做法，它有嚴格的規則，大部分都堅持。它允許簡單的代碼覆蓋和關注點分離。在多年的webform感到沮喪之後，它終於覺得我在試圖做某些事情時不會一起竊取一切，因爲我不能拖動工具欄。
我個人會嘗試webforms，所以你會知道當你開始使用它時MVC有多好。
無論哪種方式，總是最好從頭開始，只實現邏輯。我開始使用ASP很久以前（超過12年前），並且只是在2006年我轉移到了ASP.NET 2.0，即使在今天我都知道，但我確實知道我在日常工作中所做的很多事情。
在我看來，回想起我對ASP的瞭解，我會選擇使用Web Forms而不是MVC，首先，它是一種語言，它現在在一些yeras的「市場」中，在世界各地非常流行，而MVC仍然處於測試階段，所以不適合生產環境（微軟說 - 即使這個網站是用MVC編寫的）。
我的確傾向於與MVC圖形混淆，如果我需要快速更改一個ASP項目，還有更多技巧比我想學的更多。
這取決於。 ASP.NET MVC不是銀彈，而且在很多方面從開發人員的生產力方面來看，都向後退了幾步。
如果你的預算緊張，而且需要快速完成這項工作，我相信ASP.Net是一條可行之路，因爲它擁有豐富的網格，分頁，驗證等控件，你可以直接使用。使用這些控件無疑會節省大量的開發時間。所有這些現在在ASP.NET中最常見的控件都必須從頭開始創建，或者在使用ASP.NET MVC項目時從互聯網上創建。另一方面，如果你現在和將來都有時間和預算，並且你希望有一個堅如磐石的解決方案，並且更容易適應測試驅動開發，那麼ASP.NET MVC可能就是最好的選擇。
毫無疑問，ASP.NET MVC在風格上更好。一般（這就是說，你不有使用中繼器和其他傻控制在Web窗體應用程序，你可以簡單使用內嵌代碼，就像你在MVC會。）
MVC雖然是一個更方便的港口，給你更好的結構和更愉快的體驗。
ASP.NET MVC比用於UI的自動化單元測試的Web Forms更好。但是，自動化單元測試通常是不好的做法，對於用戶界面來說更是如此。手動測試是構建高質量應用程序並充分利用開發時間的最佳方式。創建自動化的單元測試是浪費時間，並且最終會產生垃圾代碼以保持核心代碼。很多開發者喜歡自動化的單元測試，因爲他們認爲他們證明了他們的應用程序是有效的，這是錯誤的他們也試圖避免使用UML設計應用程序，因此他們使用測試驅動開發來設計使用負責設計不佳的應用程序的代碼。通過TDD，您可以重構您編寫得很差的代碼，而不用考慮首先使用模型的大圖。
所以MVC是沒用的。 Web Forms使用更好的面向對象的模型，而MVC更像老式的經典ASP和其他舊的設計模式。這是2010年，MVC已經死了。 Web窗體就像UI的ORM。
Web窗體更加面向對象，而MVC就像.NET代碼之上的經典ASP。使用Web窗體或MVC的模型設計應該是相同的。唯一的區別是Web窗體對UI有一個面向對象的抽象，而MVC使用函數和代碼片段來代替類來組織UI代碼。