ASP.NET Core MVC vs. Razor Pages – A quick comparison | Hacker News Reader

ASP.NET Core MVC vs. Razor Pages – A quick comparison

jonhilton.net

54 pointsjonhilton14 comments

Reminds me a lot of webforms.. Code behind per page. Page events (OnGet => Page_Load).

Agreed, not personally a fan. Maybe I've just been using MVC for too long to appreciate the benefits, though..

As someone who has really only learned MVC (I've done some old Webform Umbraco-based stuff which is terrible but I think that's probably more Umbraco's fault) from an organization standpoint this feels much cleaner. I think the only piece that's missing that I don't really understand is being able to manipulate the routing to my will.

I would agree... but perhaps I am looking at it code first. In the past a ThingController could return multiple Views (with possibly different models) for each action Get/Post/etc.

Get -> return View(GetResponseModel) -> Get.cshtml

Post -> return View(PostResponseModel) -> Post.cshtml

Can the Razor OnGet and OnPost only return one "model" to the "page"? It appears the page can only take one model.

OnGet -> ThingModel -> ThingPage

OnPost -> ThingModel -> ThingPage

The entry point Page (aka a View) seems to dictate the model returned and hence limits what type any "Action" can return. Am I reading this right?

And how about returning other types besides 'Pages' - like JSON (a la JSONResult).

It doesn't seem anything like webforms. This looks much more like most other server side templating systems. It just couples the standard HTTP verbs to the templates.

Webforms was this whole other beast that had UI controls connected to the backend which heavily relied on synching state between the backend (through page loads) and front end for user actions on those controls. It did mean you could write a lot of your UI code in your server side language ( C# / VB.NET ).

> UI controls connected to the backend which heavily relied on synching state between the backend...

This sounds like React with SSR or so-called Universal Web Apps.

So that feels like saying ASP.NET AJAX was way ahead of the game. And in some ways it was.

And in other ways you had this massive __VIEWSTATE hidden input field that would have to be sent in order to recreate state. But I will say, it was very cool technology at the time.

The closes thing I think would be a Java Servlet + request forwarding to a JSP page.

But I thought we've moved on from that.

Webforms was all about composition of rich components with an elaborate scheme to hide the fact that everything is playing out over http. This is completely different, it looks more similar to old school php than to webforms.

That was my first impression too. Feels a bit like Webforms done 'right', taking the best part of webforms (page organisation, view-to-code co-location) and the best part of MVC (closer to raw HTTP, no guff around viewstate or pretensions at not being stateless etc).

I didn't know MS was advocating it as the default choice for server side apps however. Does MVC just become a vehicle for exposing rest APIs then? MVC and Razer Pages can co-locate in the same project without issue.

In .NET Core with Razor pages requests just bypasses the Controller and hits the OnGet() and OnPost(). They just eliminated the Controller in their 'MVC'.

"the new kid on the block, Razor Pages"

I'm not sure that's actually true? I thought I did cshtml pages without all the MVC bits around MVC 3 or 4.

Is this perhaps just a branding/naming thing?

Update: Haven't found a good reference yet, but it seems to have been around when WebMatrix was still supported, but I don't think I actually had to use it to develop the site that was cshtml files.

Update 2: ASP.NET Web Pages with Razor Syntax was what it was called. https://docs.microsoft.com/en-us/aspnet/web-pages/overview/g...

I'm not going crazy!

Razor pages != razor syntax. I think Microsoft screwed up with the naming of them because, even within the .NET community, I see a lot of developers that conflate them. Microsoft should have named razor pages something different to avoid this confusion.

It's just a simplified MVC model where the controller boils down to OnGet()and OnPost() methods in a code-behind file. The code-behind file, in turn, reminds developers of web forms, but razor pages are really not similar at all.

ASP.NET Core has a lot of flexibility. You can go Web Api / SPA, classic MVC, or razor pages. Each has a sweet spot.

Yeah, I know the syntax is different, and I think you're right across the board. But I guess I kind of see it as just the next iteration of the old Web Pages w/ Razor functionality, just with better support for external models/code-behind, but also more package dependencies.

.NET Core definitely seems to be off to a great start, and once the tooling gets better I think I'll use it much more (EF support via VS is lacking, especially if you're trying to update a model going db-first).

So if the future of .NET is .NET Core first, I look forward to continuing to be a .NET developer.

Reply on news.ycombinator.com