demoshop

demo, trying to be the best_

在 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 課程時經常聽到這樣的問題,所以就想來寫個系列文說明我的經驗與我的主觀建議,預期會有多篇文章,從各種面向下去比較探討,但不會牽扯到實做的部分,畢竟身為一個開發人員是不會被框架限制的對吧😎