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

从…起 this

MVC 大型控制器 它处理了许多不同的依赖项和视图模型,并返回了许多 不同的观点。这导致了很大的复杂性,并且经常导致控制器不遵循 Single Responsibility Principle 或 Open/Closed Principles 有效地

剃刀页面 解决这个问题 通过在web应用程序中封装给定逻辑页的服务器端逻辑来解决问题。没有服务器端逻辑的Razor页面可以简单地由Razor文件组成(例如Index.cshtml)。然而,大多数非平凡的Razor页面将具有关联的页面模型 类,按照约定,该类的名称与Razor文件的名称相同。cs扩展(例如,Index.cshtml.cs)。这个页面模型类结合了控制器和ViewModel的职责。与使用控制器动作方法处理请求不同,像OnGet()这样的页面模型处理程序是 执行,默认情况下呈现其关联页面。

Razor页面简化了构建过程 ASP中的单个页面。NET核心应用程序,同时仍提供ASP的所有架构功能。NET Core MVC。对于新的基于页面的功能,它们是一个很好的默认选择。

何时使用MVC

如果您正在构建web API,MVC模式比尝试使用Razor页面更有意义。 如果您的项目将只公开web API端点,那么您最好从web API项目开始 模板,但在其他方面它很容易添加控制器和相关的API端点到任何ASP。净核心 应用程序。如果重新迁移现有应用程序,还应该使用基于视图的MVC方法 来自ASP。NET MVC 5或更早版本到ASP。NET核心MVC,您希望使用最少的 气力完成初始迁移后,您可以评估采用 剃须刀页面的新功能,甚至作为一个批发迁移。

注: 无论您选择使用Razor页面还是MVC视图构建web应用程序,您的应用程序都将具有 相似的性能 并将包括对依赖注入、过滤器、模型绑定、验证等的支持。

更新: 我读了更多的原因 this github 问题评论人 scott sauber :

我们正在为一个[复杂的]健康保险门户网站使用Razor页面。。。我们有60多个页面,我可以说,对于服务器呈现的HTML,我永远不会回到MVC。这也不仅仅是为了简单的事情。健康保险领域本身就很复杂,再加上它是一个多租户应用程序(我们将产品出售给其他保险公司),这增加了复杂性,因为应用程序高度可配置,因为不同的保险公司做的事情略有不同。

为什么要使用它?

• 默认情况下,Razor页面更安全。 Razor页面默认为您提供AntiForgeryToken验证。此外,您还可以通过[BindProperty]选择要进行模型绑定的属性,这可以限制您受到过度发布攻击的风险。

• Razor页面默认具有更好的文件夹结构,可以更好地扩展。 在MVC中,默认的文件夹结构根本无法扩展。当三者最终紧密耦合时,为视图、控制器和视图模型(通常是ViewModels)提供单独的文件夹是一个巨大的PITA。你最终会跳转到所有3个文件夹,并在需要添加或更改功能的任何时候导航一堆。太可怕了。这就是我提倡使用功能文件夹的原因。使用Razor页面,您的页面模型(控制器+视图模型)与视图位于同一文件夹中。你可以点击F7在它们之间切换,这也非常方便。

• 有了MVC,用10个以上的动作就很容易让控制器膨胀。通常,这些动作甚至彼此没有任何关联(可能除了两者之间的重定向)。这使得导航控制器以查找代码非常困难。如果控制器中也有私有方法,情况会变得更糟,这进一步增加了方法的膨胀。使用Razor页面,几乎不可能使用与页面无关的方法来扩充页面模型。你在页面模型中放置的所有内容都与你的页面相关。

• 单元测试更容易。 对于控制器,您可能有8个动作,并且您注入的一些依赖项仅与一个或两个动作相关。因此,当对单个动作进行单元测试时,要么需要不必要地模拟这些动作,要么传递null,这两种情况都很糟糕(这可以通过构建器模式稍微解决)。对于Razor页面,您注入的依赖关系与您正在处理的GET和POST操作完全相关。感觉很自然。

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

更新2:

here MVC变得非常复杂,非常快, MVC在脸书上分崩离析 .

Razor页面针对基于页面的工作流进行了优化,可以在这些场景中使用,与传统MVC模型相比,移动部件更少。这是因为您不需要处理控制器、动作、路由、视图模型和视图(通常是这样)。相反,您的路由是基于约定的,您的页面模型集控制器、动作和视图模型于一体。当然,页面将替换视图。你也不必像MVC中那样有那么多的文件夹,进一步简化了你的项目。

从…起 ASP.NET Core - Simpler ASP.NET MVC Apps with Razor Pages ,2017年9月MSDN文章作者 Steve Smith

[剃须刀页面]提供

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

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

ASP.NET Core - Feature Slices for ASP.NET Core MVC ,一篇来自2016年9月的旧MSDN文章,描述了为什么组织视图和控制器的经典MVC约定对于大型项目可能有缺点。本文给出了四个松散相关的应用程序概念的示例: 忍者、植物、海盗和僵尸 . 本文概述了一种在默认文件夹约定之外构建它们的方法,即按功能或责任区域将文件组织到文件夹中。

微软正在回归WebForms方法,以简化项目结构,相信“约定优先于配置”的口号,同时对开发人员隐藏配置,使事情更快。但它的缺点是,一切都会再次混合。这看起来不是一个明智的组织举措。但是嘿一些新的东西必须引起开发者对微软的注意。

在大型项目中,模型和控制器在同一个文件中,维护将是一场噩梦。它适用于只有2个属性长的类,但违反了面向对象的开闭原则。您应该设计和使用一个架构,该架构可以随时间增长(可扩展),并且仍然是稳定和逻辑的(无需重新构建项目),只需使用相同的模式进行扩展即可。

作为一名软件架构师,我会自动使用设计模式。我最喜欢的是 外观 设计模式。您可以将与HomeController相关的所有内容隐藏在HomeController后面,并且可以对存储库执行相同的操作。

想知道一件有趣的事吗?一位导游解释了名字在哪里 从外面看,他们看起来很奢侈。但是从背后他们可以 凌乱的房子的正面隐藏了它后面的东西。设计模式 来自建筑界。那么,我的应用程序背后有什么 解释

对的支持如何 共享 和 分组 Razor页面中的操作。如果您查看MVC控制器,您可以看到可以根据功能对控制器动作进行分组。你可以说主页就是这样一种功能。然后你有一个HomeController,里面有About()和Contact(),但对于Razor页面,这将是不同的页面。也许你有一个大的HomeController,里面有5个其他视图。它们都可以在同一个HomeController中分组。

控制器有两个Razor页面没有的东西:

1. :您可以在不同页面之间共享控制器操作,有时控制器操作不仅绑定到一个页面,而且可以在多个页面之间共享。请记住,控制器操作也只能返回数据(JSON/XML/etc)。有时他们返回的内容也可以被不同的页面使用。
2. 分组 :您可以在一个控制器中将相关控制器动作分组在一起。好的,如果你是一个小控制器文件的球迷,你不会这样做。我愿意。我根据功能对控制器进行分组。这使得导航更加容易。

Razor pages的处理方式是什么:目录的使用我认为:

• 分组:

问题: 对于一个简单的家来说,这就足够了。但是假设我们有一个XController,用于同一存储库中的所有操作。您可以在XController的初始化器函数中初始化该存储库。但是对于X子目录中的页面,您必须再次对所有X操作执行该操作。那是干的吗?

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

问题

或Razor页面是否只适用于简单的网站,这是否可以作为这个版本的Razor页面的结论。

Blazor服务器的架构很奇怪。它看起来像是一个使用信号器的聊天应用程序。我对此类应用程序的经验是,事件可能会丢失。我不想丢失事件,更好的是它们是堆叠的,并保证像邮件一样处理。

2013年,开发者们在论坛上问“微软是什么意思,Silverlight不是推荐的……” 只是这一次,MVC将被宣告为死亡和长寿的MVVM。 你很可能期望MVC被扔进垃圾堆,慢慢地,但在18个月后会加速,你花在学习MVC上的任何时间都会被扔进同一个垃圾堆。