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 ).
This sounds like React with SSR or so-called Universal Web Apps.
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.
But I thought we've moved on from that.
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.
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).
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!
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.
.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.