NET 核心剃刀页面与完整的 MVC 核心

在 SO为什么 Razor Pages 是在 Asp.net Core 2.0中创建 Web UI 的推荐方法？中有一个问题，Steve Smith 从文件较少的角度，友好地解释了在完整的 MVC 中使用 Razor Pages 的好处。

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

所以，问题是:

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

如果一些有经验的家伙分享你的想法(利弊)关于使用 Razor Pages 来更好地理解这个框架，我也会非常感激。

49370 次浏览
小开
最佳答案

We've recently launched a pretty decent sized app using Razor Pages for the front end and MVC controllers for the API for client side components. My experience has been this:

The pages paradigm works well when your content is structured around the idea of actual "pages" on the site. Think about things such as a Contact Us or an About or even a Login page. Sure, those could be done via MVC, but MVC is really unnecessary. A simple page will suffice. Leave the controllers to more controller'ish things like a product catalog or a user database.

If your MVC architecture revolves heavily around your view structure, razor pages is probably a good fit. You can still use the MVC bits for API related stuff, but the benefit of pages is that your front end structure becomes more explicit and less implicit ("convention-based") like with MVC where each action could or could not have a view that is typically named after the action.

小开

Although Chris has provided a clear opinion on the frameworks being shipped with a standard ASP.NET Core Implementation. People must also note that for MS to recommend Razor Pages there's rather deeper reasons for that and they have been clear to me since I'm a big fan of razor pages.

If there is anything else except simplicity of a page to prefer Razor Pages over Controllers/Views - specifically I'm interested in performance of the two frameworks?

  • To answer this, You sound like you simply haven't done a really heavy app in MVC if you're asking this question. Controllers become flocked with code, and it could be really messy, considering that not all programmers out there are following good programming practices(commenting and proper code management)... So imagine a controller with a few Page methods with logic all put in it. Well, the result is you'd easily end up with a controller consisting of over 400+ lines of code that could easily be split as it refers to different pieces of the app(pages or methods). So How about breaking those 300+ lines of code and separating them based on what they do? This is the whole idea behind razor pages. You only put code related to a specific page to it's own model rather than mixing code related to 10 pages in one file. Well, others could argue that you can create external classes where you'd put this logic to keep the controllers clean, but why go the extra mile? and secondly performance shouldn't be an issue at all. I don't think it matters at this point. Razor Pages thrives when it comes to form-based pages since model binding is so smooth with it.

Is it acceptable to combine Razor Pages and Controllers/Views at the same time?

  • Well, MVC is the pinnacle of WebAPI's when it comes to .NET. So the two can be mixed at any point, anytime. Razor pages truly resemble "true pages" but they're flexible to fit anything, either a catalog or whatever you wish to build. each page can serve it's own requests GET, POST etc... so due to that you can do whatever you want with a razor page. It must also be clear that routing isn't complicated with Razor Pages. It works just as flexible as in MVC...

I've been using Razor Pages for a while and noticed that despite an advantage of a Razor Page simplicity, it is a bit complicated when it comes to custom routing, structuring folders and complex view model (page model seem to be cluttered).

  • I'd rather disagree with this. Routing is flexible with Razor pages, you just haven't worked yourself around it. Also a razor page can build a very complex View because you can Bind as many View Models to it without any extra-effort required. With the annotation rule [BindProperties] or [BindProperty], you can import as many fields you want into a view... and remember that the binding is Two-Way.

Unless you start working with Razor pages, you'll hear a lot of opinions about it, some will sway you away from using it, some like Chris will give you true feedback. But my advise is, Razor pages has evolved and performs best in any application of any size...

I hope you find this interesting to read.

.Net Core Family

小开

Chris and Mosia give good answers. Chris writes

You sound like you simply haven't done a really heavy app in MVC

I saw no significant advantage of Razor Pages (RP) over MVC with controllers and views when I ported Get started with ASP.NET Core MVC to Get started with Razor Pages in ASP.NET Core. It wasn't until I ported Get started with EF Core in an ASP.NET MVC web app to Razor Pages with Entity Framework Core in ASP.NET Core that I saw a significant productivity advantage. MVC/EF is by no means close to a real production app, it's much simpler. Yet it has enough complexity to demonstrate the advantages of RP over MVC.

In interviews with customers, the most common reason I hear for sticking with controllers and views for UI is that they have an existing controller/view code base.

The most common reasons for preferring RP over MVC is preventing bloated controllers and better integration between pages and views.

Razor Pages vs ASP.NET Core MVC and Why choose MVC tutorials over Razor Pages provides more information and adds links to all the best MVC VS. RP content.

Much of the best comments in Why choose MVC tutorials over Razor Pages are hidden. Search for hidden and select Load more...

小开

I've been through the whole webforms, mvc, SPA life cycle with some enterprise sized apps. These are my thoughts:

  • Webforms became too much abstraction over the html. Easy to use for simple demos but tricky to customize to the last tag.

  • MVC was a break to that where everything is left to the developer. Idea was to separate everything and give back control to the developer. Unfortunately it also became a lot more complex and the simple page was scattered in three different locations (the model, the view and the controller). Removing functionality becomes tricky since it's in different places, hence people start to use feature folders to group all of the MVC components for a single feature.

  • Razor pages is in my eyes a more standardized feature folder where they have merged the controller and the model to simplify life. I liked feature folders and I like the Razor pages for the same reason. It makes it easier to remove functionality when it's located in one spot and for larger solutions that is key. Simplifies workflow.


提交答案