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

Question

在SO上有一个问题为什么Razor Pages是在Asp.net Core 2.0中创建Web UI的推荐方法？史蒂夫史密斯从少量文件的角度解释了使用Razor Pages而不是完整MVC的好处.

我一直在使用Razor Pages,并注意到尽管Razor Page简洁的优点,但在自定义路由,结构化文件夹和复杂视图模型(页面模型似乎混乱)方面有点复杂.

所以,问题是:

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

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

Answer 1

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

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

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

Answer 2

尽管 Chris 对随标准 ASP.NET Core 实现一起提供的框架提供了明确的意见。人们还必须注意，MS 推荐 Razor Pages 有更深层次的原因，因为我是 Razor Pages 的忠实粉丝，所以他们对我来说很清楚。

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

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

同时结合 Razor Pages 和 Controllers/Views 是否可以接受？

• 嗯，就 .NET 而言，MVC 是 WebAPI 的巅峰之作。所以这两者可以随时混合。Razor 页面真正类似于“真实页面”，但它们可以灵活地适应任何内容，无论是目录还是您想要构建的任何内容。每个页面都可以处理它自己的请求 GET、POST 等...因此，您可以使用剃刀页面做任何您想做的事情。还必须清楚的是，Razor Pages 的路由并不复杂。它的工作方式和 MVC 一样灵活......

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

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

除非你开始使用 Razor 页面，否则你会听到很多关于它的意见，有些会影响你使用它，有些像 Chris 会给你真实的反馈。但我的建议是，Razor 页面已经发展并在任何规模的任何应用程序中表现最佳......

我希望你会觉得这很有趣。

.Net 核心家族

Answer 3

我已经经历了一些企业级应用程序的整个 Webforms、MVC、SPA 生命周期。这些是我的想法：

• Webform 变得对 html 过于抽象。简单的演示很容易使用，但自定义最后一个标签却很棘手。

• MVC 打破了一切都留给开发人员的模式。想法是将一切分开并将控制权交还给开发人员。不幸的是，它也变得更加复杂，简单的页面分散在三个不同的位置（模型、视图和控制器）。删除功能变得很棘手，因为它位于不同的位置，因此人们开始使用功能文件夹将所有 MVC 组件分组为单个功能。

• 在我看来，Razor 页面是一个更加标准化的功能文件夹，它们合并了控制器和模型以简化生活。我喜欢功能文件夹，出于同样的原因，我喜欢 Razor 页面。当功能位于一个位置时，它可以更轻松地删除功能，这对于更大的解决方案来说是关键。简化工作流程。

Answer 4

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

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

我看到剃刀页面（RP）在MVC与控制器和视图，当我移植的无显著优势开始使用ASP.NET MVC的核心开始到开始使用剃刀网页在ASP.NET核心启动。直到我将ASP.NET MVC Web 应用程序中的 EF Core 入门移植到Razor Pages with Entity Framework Core in ASP.NET Core 后，我才看到了显着的生产力优势。MVC/EF 绝不接近于真正的生产应用程序，它要简单得多。然而，它有足够的复杂性来证明 RP 相对于 MVC 的优势。

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

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

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

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