ASP.NET Core Razor 页面与完整 MVC Core [关闭]答案

【问题标题】：ASP.NET Core Razor pages vs Full MVC Core [closed]ASP.NET Core Razor 页面与完整 MVC Core [关闭]
【发布时间】：2018-06-15 18:10:41
【问题描述】：

在 SO Why is Razor Pages the recommended approach to create a Web UI in Asp.net Core 2.0? 有一个问题，Steve Smith 从文件更少的角度解释了使用 Razor Pages 而非完整 MVC 的好处。

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

所以，问题是：

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

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

【问题讨论】：

@Jasen 感谢您的回答，很抱歉不清楚。在过去的 3 年中，我一直在使用完整的 MVC，然后 Microsoft 提出了将 Razor Pages 用于 UI 应用程序的建议。所以，我想知道是否有人已经开始使用该框架并同意遵循微软的建议。
@S.Serp 当然。我无法将 _ViewStart、_Layout、_ViewImports 移动到共享文件夹；如果我想将我的页面分组到一个文件夹中（这很明显），它会影响页面路由，并且覆盖常规路由的唯一方法是在 Startup.ConfigureServices 中配置 RazorPagesOptions（与我可以用属性装饰它的操作不同）。在某些情况下，我有很大的 ViewModel，里面有一些与 VM 相关的逻辑；如果我将页面的逻辑与 VM 的逻辑和属性结合起来，与 MVC 模型结构不同，页面看起来很丑（似乎违反了 SRP）。当然，所有所说的都是恕我直言。
@Jasen 表示我不会将两者混为一谈。为什么不？见github.com/Rick-Anderson/RP-vs-MVC/blob/master/README.md
微软对两者的立场 (from the tutorial here) 似乎是 Razor Pages 是经验不足的 ASP.NET Core 开发人员的更好切入点，而 MVC Core 是资深开发人员更灵活和可配置的范例.
@RickAndMSFT Hit F7 in Visual Studio to toggle between them...我是 ASP.NET 新手，那里用于在 Razor 页面及其 PageModel 之间切换的小快捷方式让我更多地使用 Razor 页面。总是小事:-)

标签： asp.net-core-mvc razor-pages

【解决方案1】：

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

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

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

【讨论】：

克里斯，感谢您的宝贵意见。你的意思是说可以将 Razor 页面和 API 控制器结合起来，但它不适用于 Razor 页面和传统视图（由控制器提供服务），这对吗？
没有理由不能将两者结合起来。 /about 可以是带有公司背景信息的剃须刀页面，而/users/1/profile 可以是显示用户信息的 mvc 视图。
如果Asp.Net Core Razor Pages 比ASP.NET Core MVC 好，为什么Microsoft 发布了ASP.NET Core MVC？看来here 的人喜欢MVC 风格，请指导我们何时应该使用ASP.NET Core MVC？
@Chris 我是 ASP.NET Core 的新手，如何同时创建 MVC 和 Razor Pages 项目？
@OgrishMan 引用 nuget 包 Microsoft.AspNetCore.Mvc.RazorPages 和 Microsoft.AspNetCore.Mvc

【解决方案2】：

尽管 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 Page 简单的优点，它有点复杂涉及自定义路由、结构化文件夹和复杂视图模型（页面模型似乎杂乱无章）。

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

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

我希望你觉得这篇文章很有趣。

.Net Core 系列

【讨论】：

来自MVVM背景（WPF，Xamarin），我也喜欢RP。我实际上认为 RP 是 Web 的 MVVM（仍然不确定我的假设是否正确！）
@HassanTareq 是的。 RP 确实是一个 MVVM。
控制器不应该“堆满代码”，因为它们本来就没有业务逻辑。在我看来，Razor Pages 似乎在鼓励人们再次将业务逻辑放回表示层，在代码隐藏中，在行业走上了避免这种情况的路线之后，例如洋葱架构和领域驱动设计. 叹息多么令人困惑...
不！让我提醒您，应用程序可能变得如此复杂，以至于有 70 种不同的操作（思考方法）与特定控制器相关。然后怎样呢？你真的要把这些动作的实现放在同一个控制器中吗？嗯……想一想。而且你说“Razor Pages 是一种鼓励人们将业务逻辑再次放回表示层”也是错误的，因为 razor 页面模型只是相当于控制器操作方法。因此，无论您在操作方法中做什么，都适用于剃须刀页面模型。这取决于你作为程序员。
关于 RazorPages 的非常好的、诚实和有用的想法。

【解决方案3】：

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

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

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

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

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

Razor Pages vs ASP.NET Core MVC 和 Why choose MVC tutorials over Razor Pages 提供更多信息并添加所有最佳 MVC VS 的链接。 RP 内容。

Why choose MVC tutorials over Razor Pages 中许多最好的 cmets 都被隐藏了。搜索 hidden 并选择 Load more...

【讨论】：

链接的 GitHub 问题对于试图在完整 MVC 和 Razor 页面之间做出决定的人来说不是一个好的资源。该线程充满了 MVC 狂热者，他们在关于 RP 的谎言之后不断地吹嘘。对于以前使用过 RP 的人来说，很明显这些原教旨主义者从未真正使用过 RP。但是，如果你没有使用 RP，它们会让它听起来很糟糕。如果我在看到那个帖子时没有使用 RP 一年多，那已经足以吓跑我了。

【解决方案4】：

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

【讨论】：

什么是 asp.net core MVC 中的“功能文件夹”，您如何创建它们以及路由问题是什么？您是指区域（它们只是更加复杂）？