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

72

SO上存在一个问题，为什么Razor Pages是在Asp.net Core 2.0中创建Web UI的推荐方法？史蒂夫·史密斯（Steve Smith）从减少文件数量的角度，亲切地解释了使用剃刀页面优于完整MVC的好处。

我使用Razor Pages已有一段时间，并注意到，尽管Razor Page简单性有优势，但在自定义路由，结构化文件夹和复杂的视图模型（页面模型看起来很杂乱）方面还是有点复杂。

因此，问题是：

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

如果某些经验丰富的人分享了您对使用Razor Pages更好地理解此框架的想法（利弊），我也将不胜感激。

asp.net-core-mvc  razor-pages 
— 伊万·扎鲁巴（Ivan Zaruba）
source
我不会混合两者。只需跳一下，然后自己尝试完整的MVC。没那么复杂。
— 杰森
4
@Jasen感谢您的回答，并对您的不清楚表示抱歉。在过去的三年中，我一直在使用完整的MVC，然后Microsoft提出了将Razor Pages用于UI应用程序的建议。因此，我想知道是否有人已经开始使用该框架并同意应遵循Microsoft的建议。
— 伊万·扎鲁巴
1
@Jasen说我不会将两者混在一起。为什么不？见github.com/Rick-Anderson/RP-vs-MVC/blob/master/README.md
— RickAndMSFT
1
微软对这两者的立场（来自此处的教程）似乎是，对于没有经验的ASP.NET Core开发人员而言，Razor Pages是更好的切入点，而对于资深开发人员，MVC Core是更灵活和可配置的范例。
— Extragorey
1
@RickAndMSFT Hit F7 in Visual Studio to toggle between them...我是ASP.NET的新手，那里的用于在Razor页面与其PageModel之间进行切换的小捷径使我在使用Razor页面上获得了更多收益。永远都是小事:-)
— 埃里克·穆塔

Answers:

62

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

当您的内容是围绕站点上实际“页面”的概念来组织时，页面范例会很好地工作。考虑一下诸如“联系我们”或“关于”甚至“登录”页面之类的问题。当然，可以通过MVC完成这些操作，但是MVC确实是不必要的。一个简单的页面就足够了。将控制器留给控制器更多的东西，例如产品目录或用户数据库。

如果您的MVC架构主要围绕视图结构旋转，则剃刀页面可能是一个很好的选择。您仍然可以将MVC位用于与API相关的内容，但是页面的好处是，您的前端结构变得更显式和更少隐式（“基于约定”），就像MVC一样，其中每个动作可以或不能拥有一个视图通常以动作命名。

— 克里斯
source
克里斯，谢谢你的宝贵评论。这是对的，这意味着可以将Razor页面和API控制器组合在一起，但是不适用于Razor页面和传统视图（由Controller服务）吗？
— 伊万·扎鲁巴
16
没有理由不能将两者结合。/about可能是包含公司背景信息的剃须刀页面，而/users/1/profile可能是显示用户信息的mvc视图。
— 克里斯（Chris）
1
如果比为什么要发布Asp.Net Core Razor Pages更好？看来这里的人们喜欢时尚，何时应该使用我们 ？ASP.NET Core MVCMicrosoftASP.NET Core MVCMVCASP.NET Core MVC
— Shaiju T
1
@Chris我是ASP.NET Core的新手，如何制作MVC和Razor Pages的项目？
— 只是一个学习者，
1
@OgrishMan参考nuget软件包，Microsoft.AspNetCore.Mvc.RazorPages以及Microsoft.AspNetCore.Mvc
— 克里斯
21

尽管Chris对于标准ASP.NET Core实现附带的框架提供了明确的意见。人们还必须注意，让MS推荐Razor Pages的原因更深了，因为我是剃须刀页面的忠实拥护者，这对我很清楚。

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

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

可以同时合并“剃刀页面”和“控制器/视图”吗？

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

我使用Razor Pages已有一段时间，并注意到尽管Razor Page简单性有优势，但在自定义路由，结构化文件夹和复杂的视图模型（页面模型看起来很杂乱）方面却有点复杂。

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

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

我希望您觉得这有趣有趣。

.Net核心家族

— 莫西亚·塔波（Mosia Thabo）
source
来自MVVM背景（WPF，Xamarin），我也喜欢RP。我实际上以为RP是Web的MVVM（仍然不确定我的假设是否正确！）
— Hassan Tareq
3

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

您听起来好像没有在MVC中做过真正繁重的应用程序

我看到剃刀页面（RP）在MVC与控制器和视图，当我移植的无显著优势开始使用ASP.NET MVC的核心开始到开始使用剃刀网页在ASP.NET核心启动。但直到我移植与EF核心在ASP.NET MVC的Web应用程序入门到与实体框架的核心在ASP.NET核心剃刀网页，我看到一个显著的生产力优势。MVC / EF绝不接近真正的生产应用程序，它要简单得多。然而，它具有足够的复杂性，足以证明RP优于MVC。

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

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

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

为什么在Razor Pages 上选择MVC教程中的许多最佳注释被隐藏了。搜索隐藏内容，然后选择加载更多...

— 里克·安德鲁
source
在您的第一段中的四个链接中，两个“剃刀页面”被打断了。微软削减谷壳？
— Extragorey
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.