ASP.NET Core 2.0 Razor页面与完整的MVC Core

Question

在SO Why is Razor Pages the recommended approach to create a Web UI in Asp.net Core 2.0?有一个问题，史蒂夫史密斯从文件较少的角度解释了使用Razor Pages而不是完整MVC的好处。

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

所以，问题是：

1. 除了页面的简洁性之外还有什么其他的东西比控制器/视图更喜欢Razor页面 - 特别是我对这两个框架的性能感兴趣吗？
2. 同时组合Razor Pages和Controllers / Views是否可以接受？

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

Answer 1

我们最近推出了一个相当不错的应用程序，使用前端的Razor Pages和客​​户端组件的API的MVC控制器。我的经验是：

当您的内容围绕实际＆＃34;页面＆＃34;的概念构建时，页面范例很有效。在网站上。考虑诸如联系我们或关于甚至是登录页面之类的事情。当然，这些可以通过MVC完成，但MVC实际上是不必要的。一个简单的页面就足够了。将控制器留给更多控制器，例如产品目录或用户数据库。

如果您的MVC架构围绕您的视图结构大量展开，那么剃刀页面可能非常合适。您仍然可以将MVC位用于API相关的东西，但页面的好处是您的前端结构变得更加明确且不那么隐含（＆＃34;基于约定＆＃34;），就像MVC一样，每个动作都可以或者可以没有通常以操作命名的视图。

Answer 2

尽管Chris对于标准ASP.NET Core实现附带的框架提供了清晰的意见。人们还必须注意，让MS推荐Razor Pages的原因更深，自从我很喜欢剃须刀纸页以来，他们就对我很清楚了。

  

如果除了页面的简单性之外还有其他方面更喜欢Razor   控制器/视图上的页面-我特别感兴趣   两个框架的性能？

• 要回答这个问题，如果您要问这个问题，您听起来好像没有在MVC中做过真正繁重的应用程序。考虑到并不是所有的程序员都遵循良好的编程习惯（注释和适当的代码管理），所以控制器变得无处不在，代码可能真的很混乱。因此，想象一下一个控制器，其中包含一些带有逻辑的Page方法。好的，结果是您很容易就可以得到一个由超过400行代码组成的控制器，这些代码可以很容易地拆分，因为它涉及不同的部分（页面或方法）。那么，如何打破这300余行代码并根据它们的作用将它们分开呢？这是剃须刀页面背后的整个想法。您只将与特定页面相关的代码放入自己的模型中，而不是将与10个页面相关的代码混合到一个文件中。好吧，其他人可能会争辩说，您可以创建外部类，并在其中放置此逻辑以保持控制器整洁，但为什么还要花大力气呢？其次，性能根本不应该成为问题。我认为目前不重要。

  

在以下位置合并Razor页面和Controllers / Views是否可以接受？   同一时间？

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

  

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

• 我宁可不同意这一点。 Razor页面的路由很灵活，您只是还没有解决这个问题。剃刀页面也可以构建非常复杂的视图，因为您可以将许多视图模型绑定到该视图模型而无需任何额外的工作。使用注释规则[BindProperties]或[BindProperty]，您可以将所需的任意字段导入视图...并记住绑定是双向的。

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

希望您阅读这篇有趣的文章。

.Net核心家族

Answer 3

克里斯和莫西亚给出了很好的答案。克里斯写道

您听起来好像没有在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的控制器和视图的最常见原因是他们具有现有的控制器/视图代码库。

与MVC相比，首选RP的最常见原因是可以防止过大的控制器以及页面和视图之间更好的集成。

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

Why choose MVC tutorials over Razor Pages中的许多最佳注释都被隐藏了。搜索隐藏的内容，然后选择加载更多...