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更好地理解此框架的想法(利弊),我也将不胜感激。


我不会混合两者。只需跳一下,然后自己尝试完整的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一样,其中每个动作可以或不能拥有一个视图通常以动作命名。


克里斯,谢谢你的宝贵评论。这是对的,这意味着可以将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核心家族


来自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教程中的许多最佳注释被隐藏了。搜索隐藏内容,然后选择加载更多...


在您的第一段中的四个链接中,两个“剃刀页面”被打断了。微软削减谷壳?
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.