ASP.NET Core Razor页面 vs 完整的MVC Core

Question

ASP.NET Core Razor页面 vs 完整的MVC Core

93

有人在Stack Overflow上提出了一个问题为什么Razor Pages是创建Asp.net Core 2.0 Web UI的推荐方法？，Steve Smith友善地解释了使用 Razor Pages 相对于完整的 MVC 来说有较少文件数量的优势。

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

所以，问题是：

除了页面简洁性之外，是否还有其他原因可以优先选择Razor Pages而不是Controllers/Views - 具体来说，我对这两个框架的性能很感兴趣？
同时使用Razor Pages和Controllers/Views是否可行？

我也希望一些有经验的人分享一下关于使用Razor Pages的想法（利与弊），以更好地理解这个框架。

- Ivan Zaruba

5

@Jasen，谢谢你的回答并感到抱歉我表述不清。在过去的三年中，我一直在使用完整的MVC，然后微软建议使用Razor页面来进行UI应用程序开发。因此，我想知道是否有人已经开始使用这个框架，并赞同应该遵循微软的建议。 - Ivan Zaruba

1

@S.Serp 没问题。我无法将 _ViewStart、_Layout 和 _ViewImports 移动到 Shared 文件夹中；如果我想要将页面分组在文件夹中（这是很明显的），它会影响页面路由，而覆盖常规路由的唯一方法是在 Startup.ConfigureServices 中配置 RazorPagesOptions（与操作不同，我可以用属性来修饰）。在某些情况下，我的 ViewModel 很大且包含一些与 VM 相关的逻辑；如果我将页面的逻辑与 VM 的逻辑和属性结合起来，页面看起来很丑陋（似乎违反了 SRP），不像 MVC 模型结构。当然，以上都是我的个人意见。 - Ivan Zaruba

1

@Jasen说我不会混合使用这两个。为什么？请参见https://github.com/Rick-Anderson/RP-vs-MVC/blob/master/README.md - RickAndMSFT

2

微软对于这两种编程范式的看法（来自于此教程：https://learn.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/start-mvc?view=aspnetcore-3.1&tabs=visual-studio）似乎是，对于没有经验的ASP.NET Core开发者而言，Razor Pages 是更好的入门选择，而 MVC Core 则是更为灵活且可配置的编程模式，适合有经验的开发者。 - Extragorey

3

在Visual Studio中按F7键可以在Razor页面和其PageModel之间切换。我是ASP.NET的新手，这个小技巧让我更倾向于使用Razor页面。有时候就是这些小细节能够起到关键作用 :-) - Eric Mutta

显示剩余8条评论

4个回答

39

Chris已经阐明了标准ASP.NET Core实现中提供的框架的清晰观点。但人们必须注意，对于微软来说，推荐Razor Pages有更深层次的原因，因为我是Razor Pages的忠实粉丝，这些原因对我来说很清楚。

如果除了页面的简单性外，还有其他原因可以优先选择Razor Pages而不是Controllers/Views - 具体而言，我对两个框架的性能特别感兴趣？

要回答这个问题，看起来你可能还没有用MVC开发过一个真正“重”的应用，否则就不会问这个问题了。控制器会充斥着大量的代码，因为并不是所有的程序员都遵循良好的编程习惯（注释和适当的代码管理），所以它可能会变得非常混乱。如果一个控制器有几个带有各自逻辑的页面方法，那么结果就是你很容易就会得到一个由400多行代码组成的控制器，而这些代码其实可以按照不同的部分进行拆分（例如不同的页面或方法）。那么，把这300多行代码根据其功能进行分离怎么样？这就是Razor Pages的整个想法。你只需要将与特定页面相关的代码放到其自身的模型中，而不是将与10个页面相关的代码混合在一个文件中。当然，其他人可能会认为你可以创建外部类来存放这些逻辑，以保持控制器的整洁，但是为什么要走这条路呢？其次，性能根本不是问题。我认为在这一点上，并不重要。Razor Pages在处理基于表单的页面时表现得非常出色，因为它的模型绑定非常顺畅。

在.NET中，MVC是WebAPI的巅峰。因此，两者可以在任何时候混合使用。Razor页面确实类似于“真正的页面”，但它们很灵活，可以适应任何内容，无论是目录还是任何您想构建的东西。每个页面都可以为其自己的请求(GET,POST等)提供服务，因此由于这一点，您可以对Razor页面做任何想做的事情。同时，必须清楚的是，路由在Razor页面中并不复杂。它的灵活性与MVC一样...

我已经使用Razor页面一段时间了，并注意到尽管Razor Page简单易用，但在自定义路由、文件夹结构和复杂的视图模型方面有些复杂(page model似乎很混乱)。

我不太同意这个观点。Razor页面的路由非常灵活，只是您还没有熟悉它。另外，在不需要任何额外工作的情况下，Razor页面可以构建非常复杂的视图，因为您可以将许多视图模型绑定到其中。通过注释规则[BindProperties]或[BindProperty]，您可以将任意数量的字段导入到视图中...请记住绑定是双向的。

除非开始使用Razor页面，否则您会听到很多关于它的观点，有些会让您远离使用它，有些像Chris这样会给您真实的反馈。但是我的建议是，Razor页面已经发展成为在任何大小的应用程序中表现最佳的工具...

希望您对阅读这篇文章感到有趣。

.Net Core家族

- Mosia Thabo

1

@HassanTareq 是的，RP确实是MVVM。 - Mosia Thabo

3

控制器不应该变得“代码臃肿”，因为它们的设计初衷是不含业务逻辑的。看起来 Razor Pages 似乎在鼓励人们将业务逻辑再次放回到表现层中，在代码后置中，而行业已经采用了像洋葱架构和领域驱动设计等方法来避免这种情况。叹气真令人困惑... - Jez

4

不！让我提醒你，应用程序可能变得非常复杂，一个特定控制器可能涉及70个不同的操作（即方法）。那么呢？你真的要在同一个控制器中实现这些操作吗？嗯...好好想想。而且你说“Razor Pages有点鼓励人们将业务逻辑放回表示层”，这也是错误的，因为Razor页面模型只是控制器操作方法的等效物。所以，无论你在操作方法中做什么，在Razor页面模型中同样适用。这取决于你作为程序员的选择。 - Mosia Thabo

1

关于RazorPages的非常好、诚实和有用的想法。 - S. M. JAHANGIR

1

刚刚使用 Razor Pages 从零开始构建了一个大型项目。非常喜欢它。如果可以的话，我不想回到 MVC。我曾经经历过巨大的臃肿控制器，不是很喜欢。此外，Razor Pages 在 .Net 6 中似乎快了几个数量级。 - Norbert Norbertson

显示剩余2条评论

12

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

你听起来好像还没有在MVC中做过一个真正的重型应用程序

当我将使用ASP.NET Core MVC入门转换为使用ASP.NET Core Razor Pages入门时，我没有看到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 vs ASP.NET Core MVC和为什么选择MVC教程而不是Razor Pages提供更多信息，并添加了所有最佳MVC VS. RP内容的链接。

为什么选择MVC教程而不是Razor Pages中的许多最佳评论都被隐藏了。搜索“hidden”，然后选择加载更多...

- RickAndMSFT

2

链接的GitHub问题不是一个好的资源，供那些试图在完整MVC和Razor Pages之间做出决定的人使用。该线程充满了MVC狂热者，他们对RP发表了一个又一个错误的言论。对于任何曾经使用过RP的人来说，这些原教旨主义者从未真正使用过RP是非常明显的。但是，如果你没有使用过RP，他们会让它听起来非常糟糕。如果我在看到那个线程时没有使用RP一年以上，那就足以吓退我了。 - Patrick Tucci

1

我喜欢 RP 的一件事是按 F7 键在页面和代码之间切换。试试在 MVC 中这样做。 - Norbert Norbertson

8

我曾经经历过整个Webforms、MVC、SPA生命周期的一些企业级应用程序。以下是我的想法:

Webforms对html进行了太多的抽象。对于简单的演示使用很容易，但很难自定义到最后一个标记。
MVC是一种突破，将一切留给开发者。想法是分离一切，将控制权交还给开发者。不幸的是，它也变得更加复杂，简单的页面分散在三个不同的位置(模型、视图和控制器)。由于功能位于不同地方，因此删除功能变得棘手，因此人们开始使用功能文件夹将单个功能的所有MVC组件分组。
在我看来，Razor Pages是一个更标准化的功能文件夹，其中合并了控制器和模型以简化生活。我喜欢功能文件夹，也喜欢Razor Pages的原因相同。当功能位于一个位置时，更容易删除功能，对于较大的解决方案而言非常关键。简化工作流程。

- Daniel Ovaska

1

在ASP.NET Core MVC中，“特性文件夹”是什么，如何创建它们，以及路由问题是什么？你是指区域吗（它们只会更加复杂）？ - Mike

@Mike 是的，他的意思是将特性文件夹分配到相应的区域。 - Mosia Thabo

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Chris · Accepted Answer

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

当您的内容围绕着网站上实际的“页面”构建时，页面范例会很好用。考虑像联系我们、关于我们或登录页面这样的东西。当然，这些都可以通过 MVC 完成，但 MVC 真的是不必要的。一个简单的页面就足够了。将控制器留给更像控制器的事情，如产品目录或用户数据库。

如果您的 MVC 架构主要围绕视图结构展开，Razor Pages 可能是一个很好的选择。您仍然可以使用 MVC 的部分来处理 API 相关的内容，但页面的好处在于您的前端结构变得更加明确，而不像 MVC 那样隐含（“基于约定”），其中每个操作可能或可能没有一个通常以操作命名的视图。