demoshop

在 .NET Core 的環境中開發 Web Application 的選擇分為 RazorPage 和 MVC 兩種模式，技術上這兩種模式是相輔相成的，但實務上為了維護方便開發時還是會選擇一種作為主力，等到合適的情境時才會混者用。那開發者一開始建立專案的時候到底該選 RazorPage 還是 MVC 呢？在我教 RazorPage 課程時經常聽到這樣的問題，所以就想來寫個系列文說明我的經驗與我的主觀建議，預期會有多篇文章，從各種面向下去比較探討，但不會牽扯到實做的部分，畢竟身為一個開發人員是不會被框架限制的對吧😎

demo 從開始寫程式的時候就是接觸 ASP.NET （我是半路出家的）最早是寫 Web Forms ，後來接觸到 MVC 以後全面 MVC ，目前是依據專案特性挑選 RazorPage 或 MVC ，所以我應該是能夠理解 Web Forms 開發人員轉 MVC 的無力😭，也可以體會 .NET Framework 轉到 .NET Core 的痛苦😖。

如果你是跟隨者時間改變，那你改變的時間軸應該就會和我一樣

ASP.NET Web Forms ➡ ASP.NET MVC ➡ ASP.NET Core MVC ➡ ASP.NET Core RazorPage

這樣的時間軸改變我們就不談了，因為你會這樣改的想必你是對於新技術有歇斯底里的興趣，才會這樣自虐，我們要談的是跳者改的開發人員。

ASP.NET Web Forms

ASP.NET Web Forms 的開發時代有兩種撰寫程式的方式，分別稱為 Code Inline 和 Code Behind ，不管你是喜歡哪一種 RazorPage 都可以讓你保有那個開發習慣。

以下是 Code Inline 的示範，你可以看到這是一個 cshtml 檔案，對應的 Get 和 Post 方法是寫在同一頁的，你說這樣檔案不是很長？我想這是一種選擇，當你的單一功能（頁面）只有一個方法而且程式碼很少的時候寫在同一頁並沒有什麼不好。

當功能是比較完整或複雜的時候就可以選擇類似 Code Behind 的方式開發，以下例子第一張圖是前端頁面

後端的部分就和寫在同一頁是大同小異的

ASP.NET MVC

MVC 的開發人員當然也是可以保有相同的開發習慣（前端是一樣的就不貼了） 

ASP

如果你是個 ASP 的傳統派喜歡用老招也是沒問題的

RazorPage 允許開發者使用各式各樣的開發習慣來實做你的 Web Application ，規範你的只有團隊限制與個人喜好，所以在 RazorPage 出現後我就大力的鼓吹原有 .NET Web 開發人員要進入 .NET Core 世界最該選的就是 RazorPage ，保留的東西夠（習慣與語法），改變的觀念少（都是必要改變的），但如果你一開始就選擇了 MVC 開發方式，可能光是必要的改變就讓人想退坑了。

對於 RazorPage 開發有興趣的朋友可以參考 SkillTree 的課程😎