我們是否正在使用.Net 3.5中的MVC框架轉向傳統的ASP？

Question

看着MVC框架，似乎我們需要更多的經典ASP知識，然後ASP.NET回發和Viewstates。我們是否在實際的前端HTML標記中向後移動到複雜的UI +代碼邏輯？

Answer 1

我們正在迴避不要抽象掉HTML和HTTP請求等基本概念。在用戶界面上，這意味着視圖與輸出更緊密地結合在一起，這不是一件壞事。將經典的ASP模型翻譯成具有與輸出緊密結合的一切，其中是的壞事。

Answer 2

這很有趣，你提到這個......我今天和同事進行了同樣的談話。

它是向後移動的一步嗎？我不這麼認爲......雖然在經典的asp中，在UI中有一些複雜的邏輯，但從MVC中可以看出，複雜的邏輯應該仍然存在於業務對象中，並且與對象的任何複雜交互都應該通過控制器完成。

從我所能看到的目標來看，我們的目標是在實際的業務邏輯中保持UI的修剪和適合度。任何額外的膨脹都會導致使用戶界面更友好，比如AJAX和JQuery。

這只是我關於MVC的初步觀察。這是一項非常酷的技術，尤其是它在REST之上的地位，使得使用其他技術非常容易。

我期待在未來的幾個項目中嘗試它！

Answer 3

MVC的全部要點是代碼分離。模型應該包含所有的業務邏輯，View應該只處理輸出給用戶，而Controller應該將這兩個部分粘合在一起。

Answer 4

有人可能會爭辯說，如果您認爲ASP.NET範例向前邁進了一步，那麼MVC範式是一個倒退。就我個人而言，我一直認爲用傳統的ASP編寫乾淨的分離代碼要容易得多，而不是使用標準HTML編輯器無法訪問的顯示輸出文本通常被嵌入代碼塊的.NET。我一直認爲ASP.NET架構更關注推動.NET，而不是改進應用程序的整體結構，因此從這個意義上說，MVC是向前邁出的一步。

Answer 5

如果您在視圖中看到與模型和控制器相關的複雜代碼邏輯，那麼您可能以錯誤的方式接近它。

在純粹的意義上，你應該能夠以最少的工作將視圖（XML而不是HTML）說出來。這隻有在數據邏輯包含在模型中並且業務邏輯包含在控制器中時纔會發生。

因此，如果您正在顯示購物車，則該視圖可能只有寫出產品數量和總計的代碼。模型類將保存產品數據，控制器將執行所有處理，如添加產品和檢出。