为什么推荐使用Razor Pages在Asp.net Core中创建Web UI？

学习新事物需要投入时间，空间和精力。我目前正在学习Asp.Net Core MVC 2.0。此ASP.NET Core教程概述指出：

Razor Pages是使用ASP.NET Core 2.0创建Web UI的推荐方法。

这些信息使我感到困惑，因为我决定是否必须停止学习Asp.net Core MVC并开始学习Asp.net Core Razor Pages。

• 为什么推荐使用Razor Pages在Asp.net Core 2.0中创建Web UI？

欢迎任何方向。

剃刀页面针对基于页面的工作流程进行了优化，可在这些情况下使用，其运动部件比传统MVC模型少。这是因为您不需要像通常那样处理Controllers，Actions，Routes，ViewModels和Views。相反，您的路由是基于约定的，并且PageModel可以同时用作Controller，Action和ViewModel。该页面当然会替换视图。您也不必像在MVC中那样拥有那么多文件夹，从而进一步简化了项目。

来自ASP.NET Core- Steve Smith于2017年9月发布的MSDN文章，带有Razor Pages的更简单的ASP.NET MVC应用程序：

[剃刀页]提供

• 一种在ASP.NET Core应用程序中组织代码的简单方法，使实现逻辑和视图模型更接近视图实现代码。
• 他们还提供了一种更简单的方法来开始开发ASP.NET Core应用，

该文章提供了有关为什么要在基于页面的工作流上使用基于MVC的Razor页面的更多信息。显然，对于API，您仍然需要使用Controller。

第三方编辑-经典MVC文件夹组织的缺点

ASP.NET Core-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（）”，默认情况下呈现其关联页面。

剃刀页面简化了在ASP.NET Core应用程序中构建单个页面的过程，同时仍提供ASP.NET Core MVC的所有体系结构功能。对于基于页面的新功能，它们是很好的默认选择。

何时使用MVC：

如果要构建Web API，则MVC模式比尝试使用Razor Pages更有意义。如果您的项目仅公开Web API终结点，则理想情况下，您应该从Web API项目模板开始，否则，很容易将控制器和关联的API终结点添加到任何ASP.NET Core应用程序。如果要将现有应用程序从ASP.NET MVC 5或更早版本迁移到ASP.NET Core MVC，并且您希望用最少的精力做到这一点，则也应该使用基于视图的MVC方法。进行初始迁移后，您可以评估将Razor Pages用于新功能还是作为整体迁移是否合理。

注意： 无论您选择使用Razor Pages还是MVC视图来构建Web应用程序，您的应用程序都将具有 类似的性能，并将包括对依赖项注入，过滤器，模型绑定，验证等的支持。

更新：我在scott sauber评论的这个github问题上阅读了更多原因：

我们正在将Razor页面用于[复杂的]健康保险门户网站...我们有60多个页面，我可以说对于服务器渲染的HTML，我将永远不会回到MVC。这也不只是简单的事情。健康保险领域本质上是复杂的，并将其与多租户应用程序（我们将产品出售给其他保险公司）这一事实结合在一起，由于应用程序的高度可配置性（不同保险公司的做法有所不同），这增加了更多的复杂性。

为什么要使用它？

• 默认情况下，Razor Pages更安全。Razor Pages默认为您提供AntiForgeryToken验证。另外，您可以选择通过[BindProperty]绑定哪些属性以进行模型绑定，从而限制了您过度发布攻击的风险。

• 默认情况下，Razor Pages具有更好的文件夹结构，可以更好地缩放。在MVC中，默认文件夹结构根本无法缩放。当三个，三个控制器最终彼此紧密耦合时，具有用于View，Controller和ViewModel的单独文件夹是一个巨大的PITA。您最终会跳到所有3个文件夹，并在需要添加或更改功能时随时浏览一堆。这太糟糕了。这就是为什么我主张使用功能文件夹的原因。使用Razor Pages，您的PageModel（Controller + ViewModel）与View在同一文件夹中。您只需按F7即可在它们之间切换，这也非常方便。

• 导致可扩展性更好的代码。使用MVC，用10个以上的动作膨胀一个控制器非常容易。通常，这些动作甚至根本不相关（除了两者之间的重定向）。这使得导航Controller很难找到代码。如果Controller中也有私有方法，情况将变得更糟，进一步增加了方法膨胀。使用Razor Pages，几乎不可能用与页面无关的方法来膨胀您的Page Model。您放入PageModel中的所有内容都与您的Page相关。

• 单元测试更容易。使用Controller时，您可能有8个动作，并且您注入的某些依赖项仅与一个或两个动作相关。因此，当对单个Action进行单元测试时，您要么需要不必要地模拟它们，要么传递null，这两者都感觉很麻烦（可以通过Builder模式来解决）。使用Razor Pages，您插入的依赖项与您正在使用的GET和POST操作100％相关。感觉很自然。

• 路由比较容易。默认情况下，在Razor Pages中，路由仅与您的文件夹结构匹配。这使嵌套文件夹的方式更容易实现。例如，我们所有的HR Admin页面都在该/Administrator文件夹下，而所有Employee页面都在该/Employee文件夹下。我们可以授权整个文件夹，并说该人必须是管理员才能访问的任何子文件夹/Administrator，这比使用组成管理员功能的多个控制器要容易得多。

我认为那是大事。

更新2：

这是关于一些MVC模式的复杂性，并没有直接回答这个问题，但可能是有用的：一个工程经理在Facebook上说，（在这里）为他们的“足够”大的代码库和大型组织，“MVC得到了非常复杂真的很快，”结论是MVC无法扩展。每当他们尝试添加新功能时，系统的复杂性就会成倍增长，从而使代码“易碎且不可预测”。对于刚接触某个代码库的开发人员而言，这已成为一个严重的问题，因为他们害怕触摸代码，以免破坏某些内容。结果是MVC对于Facebook崩溃了。

Microsoft将重新使用WebForms方法来简化项目结构，该方法信任“ Convention over configuration”的口头禅，同时向开发人员隐藏配置以加快处理速度。但它的缺点在于一切都会再次混合。我看起来不太明智。但是...嘿！新事物必须引起开发人员对Microsoft的关注。

如果您的页面使用MVC Web API来实现REStful，则仅使用Razor页面确实要容易得多。如果没有，我建议您使用Core MVC。

在大型项目中，模型和控制器位于同一文件中，维护将是一场噩梦。它对于仅2个属性长的clase效果很好，但是它违反了OOP的Open Close原则。您应该设计和使用可以随时间增长的结构（可扩展），并且仍然保持稳定和逻辑（不重新构造项目），只需使用相同的模式对其进行扩展即可。

作为软件架构师，我会自动使用设计模式。我非常喜欢的是Facade设计模式。您可以将与Home相关的所有内容隐藏在HomeController后面，也可以对Repositories进行相同操作。

想知道一件有趣的事吗？一位导游解释了Facade这个名字的来历。在阿姆斯特丹，您有横跨水域的大房子。从外面看，他们看上去很奢华。但是从后面看，它们可能会很混乱。房子的外墙隐藏了它后面的东西。设计模式来自建筑世界。嗯，我的应用程序中的内容看起来也不错，但是很高兴从导游那里了解到有关解释。

如何支持Razor页面中的“共享和分组”操作。如果您查看MVC控制器，您会看到可以基于功能对控制器操作进行分组。您可以说主页就是这样的功能。然后，您将拥有一个带有About（）和Contact（）的HomeController，但是对于Razor Pages，它将是不同的页面。可能是您有一个很大的HomeController，其中有5个其他视图。它们都可以分组在同一个HomeController中。

控制器具有剃刀页面没有的两件事：

1. 共享：您可以在不同页面之间共享Controller动作，有时Controller动作不仅限于一个页面，还可以在多个页面之间共享。记住，控制器动作也只能返回数据（JSON / XML / etc）。有时它们返回的内容也可以由不同的页面使用。
2. 分组：您可以将一个控制器中的相关控制器动作分组在一起。好吧，如果您喜欢小型Controller文件，则不会这样做。我做。我根据功能对控制器进行分组。这使导航更加容易。

Razor页面处理此问题的方式是什么：我认为使用目录：

• 分组：如果有HomeController，则可以创建一个子目录Home，其中包含所有Home页面。

问题：对于一个简单的房屋就足够了。但是可以说我们有一个XController，它对所有操作使用相同的存储库。您可以在XController的Initializer函数中初始化该存储库。但是对于X子目录中的页面，您将不得不再次对所有X动作执行此操作。那是干吗？

• 共享：您可以创建一个“共享”子目录，在该目录下，具有应在页面之间共享的功能的目录。

问题：如果您查看我的修复程序，则可以看到我使用目录来解决Razor页面的共享和分组问题。

你会怎么做？

或...仅仅是用于简单网站的Razor页面，这可能是此版本Razor页面的结论。

Blazor服务器的架构很奇怪。通过使用SignalR，它看起来像是一个聊天应用程序。我对类似应用程序的经验是事件可能会丢失。我不想丢失事件，最好是将它们堆叠起来并保证像邮件一样进行处理。

2013年，开发人员在论坛上发问：“微软是什么意思，不建议您使用Silverlight ... ???” 只有这一次，MVC才会被宣告失效，而MVVM却可以长寿。您可能会期望将MVC缓慢地扔到废料堆中，但是从现在开始大约18个月就会加速，并且您花在学习MVC上的所有所有时间都将用于同一废料堆。另外，MVVM看起来很简单，但要花上一年才能真正掌握并正确完成。