為什麼 Razor Pages 是在 Asp.net Core 中創建 Web UI 的推薦方法？
學習新事物需要時間、空間和精力的投入。我目前正在學習 Asp.Net Core MVC 2.0。此ASP.NET Core 教程概述指出：
Razor Pages 是使用 ASP.NET Core 創建 Web UI 的推薦方法
這些資訊讓我在決定是否必須停止學習 Asp.net Core MVC 並開始學習 Asp.net Core Razor Pages 時感到困惑。
- 為什麼 Razor Pages 是在 Asp.net Core 中創建 Web UI 的推薦方法？
歡迎任何方向。
Razor 頁面針對基於頁面的工作流進行了優化，並且可以在這些場景中使用，其移動元件比傳統 MVC 模型少。這是因為您不需要處理控制器、操作、路由、視圖模型和視圖（就像您通常那樣）。相反，您的路線是基於約定的，並且您的 PageModel 可作為您的 Controller、Action(s) 和 ViewModel 合而為一。當然，頁面取代了視圖。您也不必像在 MVC 中那樣擁有盡可能多的文件夾，從而進一步簡化您的項目。
來自ASP.NET Core - Simpler ASP.NET MVC Apps with Razor Pages ， Steve Smith於 2017 年 9 月發表的 MSDN 文章：
[Razor Pages] 提供
- 一種在 ASP.NET Core 應用程序中組織程式碼的更簡單方法，使實現邏輯和視圖模型更接近視圖實現程式碼。
- 它們還提供了一種更簡單的方式來開始開發 ASP.NET Core 應用程序，
那篇文章有更多關於為什麼在 MVC 上使用 Razor Pages 進行基於頁面的工作流的資訊。顯然，對於 API，您仍然希望使用控制器。
第 3 方編輯 - 經典 MVC 文件夾組織的缺點
ASP.NET Core - Feature Slices for ASP.NET Core MVC是 2016 年 9 月的一篇較早的 MSDN 文章，描述了為什麼用於組織視圖和控制器的經典 MVC 約定可能對大型項目不利。本文給出了四個鬆散相關的應用程序概念的範例：忍者、植物、海盜和殭屍。本文概述了一種在預設文件夾約定之外建構它們的方法，方法是按功能或責任區域將文件組織到文件夾中。
從Microsoft 文件中的這篇文章：
MVC：使用控制器和視圖，應用程序通常擁有非常 大的控制器，這些控制器處理許多不同的依賴項和視圖模型並返回許多不同的視圖。這導致了很多複雜性，並且經常導致控制器沒有有效地遵循
Single Responsibility Principle或Open/Closed Principles。Razor Pages通過將給定邏輯“頁面”的伺服器端邏輯封裝在 Web 應用程序中來解決此問題。沒有伺服器端邏輯的 Razor 頁面可以只包含一個 Razor 文件（例如“Index.cshtml”）。但是，大多數重要的 Razor 頁面都會有一個關聯的頁面模型類，按照慣例，它的名稱與帶有“.cs”副檔名的 Razor 文件相同（例如，“Index.cshtml.cs”）。這個頁面模型類結合了 Controller 和 ViewModel 的職責。不是使用控制器操作方法處理請求，而是執行諸如“OnGet()”之類的頁面模型處理程序，預設情況下呈現它們關聯的頁面。
Razor 頁面簡化了在 ASP.NET Core 應用程序中建構單個頁面的過程，同時仍提供 ASP.NET Core MVC 的所有體系結構功能。對於新的基於頁面的功能，它們是一個很好的預設選擇。
何時使用 MVC：
如果您正在建構 Web API，則 MVC 模式比嘗試使用 Razor 頁面更有意義。如果您的項目將僅公開 Web API 端點，則理想情況下您應該從 Web API 項目模板開始，否則很容易將控制器和關聯的 API 端點添加到任何 ASP.NET Core 應用程序。如果要將現有應用程序從 ASP.NET MVC 5 或更早版本遷移到 ASP.NET Core MVC，並且希望以最少的工作量完成此操作，則還應該使用基於視圖的 MVC 方法。完成初始遷移後，您可以評估將 Razor Pages 用於新功能甚至作為批發遷移是否有意義。
注意： 無論您選擇使用 Razor Pages 還是 MVC 視圖建構 Web 應用程序，您的應用程序都將具有 相似的性能，並且將包括對依賴注入、過濾器、模型綁定、驗證等的支持。
更新：我在這個 github問題上讀到的更多原因由scott sauber評論：
我們正在將 Razor Pages 用於 [複雜] 健康保險門戶……我們有 60 多個頁面，我可以說對於伺服器渲染的 HTML，我永遠不會回到 MVC。它也不僅僅是簡單的事情。健康保險領域本質上是複雜的，並將其與它是一個多租戶應用程序（我們將產品出售給其他保險公司）這一事實相結合，這增加了更多的複雜性，因為該應用程序是高度可配置的，因為不同的保險公司做事略有不同.
為什麼要使用它？
- **預設情況下，Razor Pages 更安全。**Razor Pages 預設為您提供 AntiForgeryToken 驗證。此外，您還可以通過 [BindProperty] 選擇要綁定到模型的屬性，這會限制您遭受過度發布攻擊。
- **預設情況下，Razor Pages 具有更好的文件夾結構，可以更好地擴展。**在 MVC 中，預設文件夾結構根本無法縮放。當所有三個最終緊密耦合時，為視圖、控制器和通常的視圖模型擁有單獨的文件夾是一個巨大的 PITA 工作。您最終會跳到所有 3 個文件夾並在需要添加或更改功能的任何時候導航一堆。這太糟糕了。這就是我提倡功能文件夾的原因。使用 Razor Pages，您的 PageModel (Controller + ViewModel) 與您的視圖位於同一文件夾中。您只需按 F7 即可在它們之間切換，這也非常方便。
- **導致更可維護的程式碼，更好地擴展。**使用 MVC，用 10 多個動作來膨脹控制器是非常容易的。通常，這些操作甚至沒有以任何方式相互關聯（可能除了兩者之間的重定向）。這使得導航控制器以查找程式碼變得非常困難。如果 Controller 中也有私有方法，情況會變得更糟，進一步增加了方法膨脹。使用 Razor 頁面，幾乎不可能使用與頁面無關的方法來膨脹頁面模型。您放入 PageModel 的所有內容都與您的 Page 相關。
- **單元測試更容易。**使用控制器，您可能有 8 個操作，並且您注入的一些依賴項僅與一兩個操作相關。因此，當對單個 Action 進行單元測試時，您要麼需要對它們進行不必要的模擬，要麼傳遞一個 null，這兩者都感覺很糟糕（這可以通過 Builder 模式稍微解決）。使用 Razor Pages，您注入的依賴項 100% 與您正在使用的 GET 和 POST 操作相關。只是感覺很自然。
- **路由更容易。**預設情況下，在 Razor Pages 中，路由只匹配您的文件夾結構。這使得嵌套文件夾更容易完成。例如，我們所有的 HR Admin 頁面都在該
/Administrator文件夾下，而所有 Employee 頁面都在該/Employee文件夾下。我們可以授權整個文件夾，並說此人必須是管理員才能訪問 的任何子文件夾/Administrator，這比使用組成管理員功能的多個控制器要容易得多。我認為這是大事。
更新 2：
這是關於 MVC 模式的一些複雜性，不能直接回答這個問題，但可能很有用：Facebook 的一位工程經理說（這裡）他們“足夠”的大型程式碼庫和大型組織，“MVC 很快就變得非常複雜，”得出結論，MVC 無法擴展。每次他們嘗試添加新功能時，系統的複雜性都會呈指數級增長，從而使程式碼“脆弱且不可預測”。對於剛接觸某個程式碼庫的開發人員來說，這已成為一個嚴重的問題，因為他們害怕接觸程式碼，以免破壞某些東西。結果是MVC 在 Facebook 中分崩離析。
