demoshop

相信很多人是直接跳這裡看結論的，但我真的希望你結論看完以後回頭看看其他兩篇的文字與範例程式碼，你應該更可以感受到 Razor Pages 的優良之處，我現在一個專案開始的時候我會優先選擇使用  Razor Pages ， 除非我在初期就明確的知道這個專案在 MVC 會比較好寫，這兩者也不應該是堅持一種，應該看專案的不同與專案成員的能力來選擇，只會一種你就沒得選，會兩種你的機會就大，我們有在開設 Razor Pages 的課程，歡迎你來加大自己的版圖，讓你也有[選]的能力。

精準解析 RazorPages
https://skilltr.ee/razorpage            

以前 MVC 框架有人反應拆太細了，大多數專案其實不需要那麼龐大的架構，現在有了更聚焦更輕量化的 Razor Pages，或許對於我們是一個不錯的解法。

情境解說

在資料庫中的資料表欄位會依據資料面來設計，但往往會與「顯示」「新增」「編輯」時所需的欄位不同，可能有多也可能有少，得過且過的開發人員會一股腦的都用 DB Model 來傳遞資料，但這是一種浪費也可能造成資安問題，依據我們開發 MVC 的習慣會建立稱為 View Model 的傳遞物件，本篇文章就來示範此情境在 ASP.NET MVC 與 Razor Pages 我們會怎麼做。

為了讓範例可以達到不用解釋的目的，我們將以會員註冊這大家都寫過的東西來做範例。

在 RazorPage 中一個頁面（功能）需要的是多個集合的物件那就這一頁的 PageModel 自己建立就好，回想一下寫 MVC 的時候是不是會有一堆只用一次的 ViewModel ，一個物件只使用一次不是問題，問題在於很多功能很類似的 ViewModel 命名上是相當困難的，為了要明確的識別每一個 ViewModel 所以命名就會越來越長，到最後就難以維護。

RazorPage 資料傳遞的類別都會包在自己身上，對於前後端需要並行開發的專案來說會比 MVC 更簡單一點，開發過程中的調整也都不用擔心會有人共用，造成改A錯B的窘境，直接改就可以也再次呼應了上一篇講的，如果你的專案在開發的時候還不知道最後到底要做什麼，還沒有規劃完善那 RazorPage 會是你更好的選擇。

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

RazorPage 與 MVC 兩者設計的差異在於 MVC 完成一個功能會至少產生 Controller , View , Model(ViewModel)，而 RazorPage 則是就只有自己本體一頁，並不是說檔案少就比較好，檔案多就比較差，這就和遵循物件導向設計模式的檔案數一定會多過大無畏開發的檔案數，但我們是整天接觸實務的開發者，如果專案還沒長大就把架構想的太大是會造成開發過程複雜化。

RazorPage 的設計很適合敏捷開發與人力不足或經常流動的公司，因為每一個功能都是相對獨立的，抽換簡單，可快速面對市場變化。快速交付持續改善，是現在網路世界的不二法門！

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

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