为什么Razor Pages是在Asp.net Core 2.0中创建Web UI的推荐方法？

Question

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

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的推荐方法？

欢迎任何指示.

Answer 1

来自"使用asp.net核心构建现代Web应用程序"(pdf here):

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的所有体系结构功能.对于基于页面的新功能,它们是一个很好的默认选择(Razor Pages提供了一种非常简单的方法来构建基于页面的应用程序功能,例如非SPA表单).

何时使用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 Pages用于多租户健康保险门户网站,其中HR管理员可以对员工数据进行CRUD,运行报告,上传文档,下载文档,账单等等,被保险人员可以查看有关其健康保险的详细信息,更改它,下载文档等.

我们有60多页,我可以说,对于服务器呈现的HTML,我永远不会回到MVC.它更适合服务器呈现的HTML应用程序.它也不只是简单的事情.健康保险领域本质上是复杂的,并将其与多租户应用程序(我们将产品销售给其他保险公司)这一事实相结合,这增加了更多的复杂性,因为应用程序可高度配置,因为不同的保险公司做的事情有点不同.

为什么要用它？

• 默认情况下,Razor Pages更安全.Razor Pages默认为您提供AntiForgeryToken验证.此外,您可以通过[BindProperty]选择加入您希望成为模型约束的属性,从而限制您过度发布攻击的风险.

• Razor Pages默认具有更好的文件夹结构,可以更好地扩展.在MVC中,默认文件夹结构根本不会缩放.为视图,控制器和ViewModel提供单独的文件夹,当这三个文件夹最终彼此紧密耦合时,可以使用一个巨大的PITA.当您需要添加或更改功能时,您最终会弹回所有3个文件夹并导航.这太糟糕了.这就是我提倡功能文件夹的原因.使用Razor Pages,您的PageModel(Controller + ViewModel)与View位于同一文件夹中.您可以点击F7在它们之间切换,这也非常方便.

• 导致更易于维护的代码可以更好地扩展.使用MVC,可以非常轻松地使用10多个操作来控制控制器.通常,这些行动甚至不以任何方式相互关联(除了两者之间的重定向).这使得导航控制器很难找到代码.如果Controller中也有私有方法,那就更糟了,进一步增加了方法膨胀.使用Razor Pages,几乎不可能使用与页面无关的方法使页面模型膨胀.您在PageModel中放置的所有内容都与您的Page相关.

• 单元测试更容易.使用Controller,您可能有8个操作,并且您注入的某些依赖项仅与一个或两个Actions相关.因此,当单元测试单个Action时,您需要不必要地模拟它们或传递null,这两者都感觉很糟糕(这可以通过Builder模式解决一下).使用Razor Pages,您注入的依赖项与您正在使用的GET和POST操作100%相关.感觉很自然.

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

我认为这是重要的事情.

更新2:

这是关于MVC模式的一些复杂性,并没有直接回答问题,但可能很有用:Facebook的工程经理说(这里)他们的"足够"的大型代码库和大型组织,"MVC真的非常复杂,"得出结论认为MVC不能扩展.每次他们尝试添加一个新功能时,系统的复杂性都呈指数级增长,使得代码"变得脆弱且不可预测."对于某个代码库的开发人员来说,这已经成为一个严重的问题,因为他们害怕触摸代码,以免他们破坏一些东西.结果是MVC在Facebook上分崩离析.

Answer 2

Razor Pages针对基于页面的工作流程进行了优化,可以在这些场景中使用,与传统MVC模型相比,移动部件更少.这是因为您不需要处理控制器,操作,路由,ViewModel和视图(就像您通常那样).相反,您的路由是基于约定的,并且您的PageModel充当您的Controller,Action(s)和ViewModel.当然,该页面取代了View.您也不必拥有与MVC一样多的文件夹,从而进一步简化您的项目.

来自ASP.NET核心 - 更简单的ASP.NET MVC应用程序与Razor页面,2017年9月由史密斯史密斯的 MSDN文章:

[Razor Pages]提供

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

该文章提供了有关为什么将基于MVC的Razor Pages用于基于页面的工作流程的更多信息.显然,对于API,您仍然希望使用控制器.

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

ASP.NET核心 - 用于ASP.NET Core MVC的功能片段是一篇来自2016年9月的旧MSDN文章,它描述了为什么组织视图和控制器的传统MVC约定可能对较大的项目有缺点.本文给出了四个松散相关的应用概念的例子:Ninjas,Plants,Pirates和Zombies.本文概述了一种通过按功能或责任区域将文件组织到文件夹中来在默认文件夹约定之外构建它们的方法.

Answer 3

微软正在回归WebForms方法,以简化信任"约定优于配置"口号的项目结构,同时隐藏开发人员的配置以加快速度.但它的缺点是一切都将再次混合.我看起来并不是一个聪明的举动.但是......嘿!一些新东西必须引起开发者对微软的注意.

如果您的页面为REStful使用MVC Web API,那么使用Razor页面真的更容易.如果没有,我建议你使用Core MVC.

在大型项目中,模型和控制器在同一个文件中,维护将是一场噩梦.它适用于只有2个属性的clases,但它违反了OOP的Open Close Principle.您应该设计和使用可以随时间增长(可扩展)并且仍然是稳定和逻辑的架构(不重新构建项目),只需使用相同的模式扩展它.