demoshop

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

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

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

複合式資料傳遞

上一篇文章的最後提到了 RazorPage 與 MVC 資料傳遞容器長的不同，這裡要來看看內容物的差異，首先來看 MVC 的 ArticleListViewModel

使用的時候是這樣用的

RazorPage 則是這樣，我刻意把檔案路徑也擷取下來，讓各位看得出來這是一個檔案，也就是很類似之前 Web Forms 的設計，前端頁面為 Index.cshtml 後端則是 Index.cshtml.cs

眼尖的朋友可能看到兩個點了

1. 為什麼 RazorPage 最後沒有 return View()
2. 文章列表怎麼可能不是集合物件

關於第一點簡單解釋因為 RazorPage 自己就是一個檔案所以方法的最後是不需要回傳（除非你要換Page）上圖我們改變了 PageModel 的值依據 MVVM 的架構，自然就會反應在頁面上，用以前 Web Forms 習慣的用語就是雙向繫結 (Two-way binding)

第二點當然就是一個鋪陳先來看看 MVC 回傳的改成集合物件的寫法(我原本想要直接 toList)

那 RazorPage 呢？

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

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

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