83

SO为什么推荐使用 Razor Pages 在 Asp.net Core 2.0 中创建 Web UI 的方法有一个问题？史蒂夫史密斯从文件更少的角度友好地解释了使用 Razor Pages 而不是完整 MVC 的好处。

我使用 Razor Pages 已经有一段时间了，注意到尽管 Razor Pages 具有简单性的优点，但在自定义路由、结构化文件夹和复杂的视图模型（页面模型似乎杂乱无章）方面有点复杂。

所以，问题是：

  1. 如果除了页面的简单性之外还有什么比控制器/视图更喜欢 Razor 页面 - 特别是我对这两个框架的性能感兴趣？
  2. 是否可以同时组合 Razor 页面和控制器/视图？

如果一些有经验的人分享你关于使用 Razor Pages 更好地理解这个框架的想法（优点和缺点），我也将不胜感激。

4

4 回答 4

81

我们最近推出了一个相当大的应用程序，使用 Razor Pages 作为前端，使用 MVC 控制器作为客户端组件的 API。我的经历是这样的：

当您的内容围绕网站上的实际“页面”的概念构建时，页面范式运作良好。想想诸如“联系我们”或“关于”甚至“登录”页面之类的东西。当然，这些可以通过 MVC 完成，但 MVC 确实没有必要。一个简单的页面就足够了。将控制器留给更多控制器的东西，例如产品目录或用户数据库。

如果您的 MVC 体系结构主要围绕您的视图结构，剃刀页面可能是一个不错的选择。您仍然可以将 MVC 位用于 API 相关的东西，但页面的好处是您的前端结构变得更加明确和不那么隐含（“基于约定”），就像 MVC 一样，其中每个操作都可以或不可以有一个视图通常以动作命名。

于 2018-02-17T18:15:15.857 回答
33

尽管 Chris 对标准 ASP.NET Core 实现所附带的框架提供了明确的意见。人们还必须注意，MS 推荐 Razor Pages 有更深层次的原因，因为我是 Razor Pages 的忠实粉丝，所以我对此很清楚。

如果除了页面的简单性之外还有什么比控制器/视图更喜欢 Razor 页面 - 特别是我对这两个框架的性能感兴趣？

  • 要回答这个问题，如果您问这个问题，您听起来好像您根本没有在 MVC 中完成过真正繁重的应用程序。考虑到并非所有程序员都遵循良好的编程实践（评论和适当的代码管理），控制器变得蜂拥而至，它可能真的很混乱......所以想象一个控制器有几个 Page 方法和逻辑都放在里面. 好吧，结果是你很容易最终得到一个包含超过 400 多行代码的控制器，这些代码很容易被拆分，因为它引用了应用程序的不同部分（页面或方法）。那么如何打破这 300 多行代码并根据它们的作用将它们分开呢？这是剃刀页面背后的全部想法。您只需将与特定页面相关的代码放到它自己的模型中，而不是将与 10 个页面相关的代码混合在一个文件中。出色地，其他人可能会争辩说您可以创建外部类，您可以在其中放置此逻辑以保持控制器清洁，但为什么要加倍努力呢？其次，性能根本不应该成为问题。我认为这在这一点上并不重要。Razor Pages 在基于表单的页面方面蓬勃发展，因为模型绑定非常流畅。

是否可以同时组合 Razor 页面和控制器/视图？

  • 嗯，当谈到 .NET 时，MVC 是 WebAPI 的巅峰之作。因此，两者可以在任何时候、任何时间混合。Razor 页面确实类似于“真实页面”，但它们可以灵活地适应任何内容，无论是目录还是您希望构建的任何内容。每个页面都可以提供它自己的请求 GET、POST 等……因此，您可以使用剃须刀页面做任何您想做的事情。还必须清楚的是，Razor Pages 的路由并不复杂。它的工作方式与 MVC 中一样灵活......

我使用 Razor Pages 已经有一段时间了，注意到尽管 Razor Pages 具有简单性的优点，但在自定义路由、结构化文件夹和复杂的视图模型（页面模型似乎杂乱无章）方面有点复杂。

  • 我宁愿不同意这一点。Razor 页面的路由很灵活，您只是没有自己解决它。剃刀页面也可以构建一个非常复杂的视图，因为您可以将尽可能多的视图模型绑定到它而无需任何额外的努力。使用注释规则[BindProperties]or [BindProperty]，您可以将任意数量的字段导入到视图中......并记住绑定是双向的。

除非你开始使用 Razor 页面，否则你会听到很多关于它的意见，有些人会让你放弃使用它，有些人像 Chris 会给你真实的反馈。但我的建议是，Razor 页面已经发展并在任何大小的任何应用程序中表现最佳......

我希望你觉得这很有趣。

.Net 核心家族

于 2019-10-23T23:13:02.340 回答
9

Chris 和 Mosia 给出了很好的答案。克里斯写道

你听起来好像你根本没有在 MVC 中完成一个非常重的应用程序

当我将Get started with ASP.NET Core MVC移植到Get started with Razor Pages in ASP.NET Core时，我没有看到 Razor Pages (RP) 与带有控制器和视图的 MVC 相比没有显着优势。直到我将ASP.NET MVC Web 应用程序中的 EF Core 入门移植到ASP.NET Core 中使用 Entity Framework Core 的 Razor Pages 后，我才看到了显着的生产力优势。MVC/EF 绝不接近真正的生产应用程序，它要简单得多。然而，它具有足够的复杂性来展示 RP 相对于 MVC 的优势。

在与客户的访谈中，我听到坚持使用 UI 控制器和视图的最常见原因是他们拥有现有的控制器/视图代码库。

选择 RP 而不是 MVC 的最常见原因是防止臃肿的控制器以及更好地集成页面和视图。

Razor Pages 与 ASP.NET Core MVC和 为什么选择 MVC 教程而不是 Razor Pages提供了更多信息并添加了指向所有最佳MVC VS的链接。RP内容。

为什么选择 MVC 教程而不是 Razor 页面中的许多最佳评论 都被隐藏了。搜索隐藏并选择加载更多...

于 2020-06-26T02:25:37.017 回答
5

我经历了一些企业级应用程序的整个 webforms、mvc、SPA 生命周期。这些是我的想法：Webforms 对 html 变得过于抽象。易于用于简单的演示，但很难自定义到最后一个标签。MVC 打破了一切都留给开发人员的局面。想法是将所有内容分开并将控制权交还给开发人员。不幸的是，它也变得更加复杂，简单的页面分散在三个不同的位置（模型、视图和控制器）。删除功能变得很棘手，因为它位于不同的位置，因此人们开始使用功能文件夹将所有 MVC 组件分组为一个功能。Razor pages 在我看来是一个更加标准化的功能文件夹，它们将控制器和模型合并在一起以简化生活。我喜欢功能文件夹，出于同样的原因，我喜欢 Razor 页面。当它位于一个位置时，它可以更容易地删除功能，并且对于关键的更大的解决方案。简化工作流程。

于 2021-08-18T13:31:58.543 回答