Aspnetcore.docs: Why choose MVC tutorials over Razor Pages

[Rick-Anderson]

This issue is for feedback of why you follow a ASP.NET Core MVC tutorial over the Razor Pages version.

Content moved to https://github.com/Rick-Anderson/RP-vs-MVC

[Rick-Anderson]

Per @wcski
I have already done the Razor pages tutorial. I am doing the MVC tutorial because the projects I will be working on at work are MVC and not Razor pages.

[Staartvin]

I have never worked with ASP.net Core before, but I prefer to start with a design (MVC) I'm familiar with to get to know the fundamentals of C# and ASP.net before plunging in Razer.

[dmillzilla]

I'm far more familiar with MVC. With that said, the instructions for the Razerpages are shown with Visual Studio for Windows. The tutorial that linked the razer instructions was a Visual Studio for Mac tutorial..

[kshorod]

I have glanced over the razor pages tutorial. I think for beginners it is indeed better than the MVC one. However, as an experienced MVC developer and somebody who will have to help interns learn programming:

1. Razor Pages is a spiritual successor (fairly or not) of Web Forms, which we moved over from to MVC and the skepticism towards anything resembling web forms is still there,
2. Right now you kind of need to be able to develop both MVC5 and core, and there is no pages in MVC5,
3. It is easier to move to developing APIs after doing stuff in MVC rather than pages,
4. Myself having experience with MVC makes it that much easier to help teach it.

Overall, to me, Razor Pages is in a place where it is cool to know it, it may be cool to use it, but you absolutely need to know MVC anyway, so might as well start with that.

Keep up the good work!

[racouster]

The Razor Tutorial requires VS and I've only got VS Code installed right now. Also why do I need Razor pages I don't like papercuts. Also isn't it just more overhead if I'm using React or Angular or similar (I mean I know they're client side, but it's more bloat. Guess I should just use WebApi and react or whatever.

[Rick-Anderson]

@racouster The VS Code

[meision]

It was very pity for me that ASP.net core team introduced Razor page. As we know, Microsoft technology lost developer in last years. Why we introduce WF/WPF/WCF, and then tell that those technology out of date.
The WebForm, tell it was out, the "MVC is new thing", and currently, tell "MVC was out, Razor page is new thing", what about tomorrow? "Razor page is out, what is new thing?". The elder developers must continue study that "new" but not the key technology -- that is why a lot of .net developer transfer to Java, why not make some stable framework for developers?

secondary, we have a lot of optimizing or quickly developing framework on MVC framework, like ABP framework ect. If change to new razor page, the whole pattern should be refactored, that is sucks and waste a lot of resources.

[JAugustoGuimaraes]

Razor pages is not MVC, is a block, post page style, a moving back to old .aspx style, it is dead!
MVC is Clean, is freedom, is easy to do App and easy to do live controls and you can do page style also.
I hate Razor Pages, it is old style with new clothes!

[gyurisc]

MVC is a clean and proven paradigm. While Razor page approach feels like a step backward. I also feel that MVC plays better when you want to support mobile clients or Angular and React in your app. Razor pages does not seem to offer any of that.

Maybe it would help developers if there would be explanations when to use Razor Pages and when MVC is appropriate. My guess is that Razor Pages can be good for developing small one-off internal tools and sites inside the enterprise and MVC is better for public facing web sites.

[davidfowl]

@JAugustoGuimaraes @gyurisc have you used Razor Pages?

[gyurisc]

@davidfowl I must confess I didnot worked with Razor Pages yet. I just skimmed through the tutorial. It is hard for me to see why this approach is better than MVC. Razor pages really reminds me the old ASP.NET Webform approach

[JAugustoGuimaraes]

I start with Razor Pages at https://docs.microsoft.com/en-us/aspnet/core/security/authorization/secure-data?view=aspnetcore-2.1

[rseyf]

I'm developing web applications professionally for about 7 years and I had experience in Symfony and J2EE frameworks. there is an unwritten law about programming professional web applications, laws like tools you use for code editors, web servers , load balancers, in-memory storages, documentation ,and even in development methods such as standard design patterns (like abstract, DI , MVC, front controller...).

So , please note that if you want coders to move to Microsoft web development platforms , you have to offer more and respect the rules! we are developers, not users. You SHOULD NOT ignore standards for sake of ease of use. Razor IS NOT STANDARD in real-world developers world.
for example , some of developers common preferences are:

• "Gnu/Linux" , "Unix", "Unix-likes" rather than "Microsoft Windows".
• "Vim", "Sublime Text" ,"VS Code" or other code editors nor "Jetbrains IDEs" rather than "Visual Studio Enterprise" because of price and freedom.
• "NGINX" or "APACHE" web servers rather than "IIS" or "Kestrel".
• "MariaDB" / "MySQL" or "PostgreSQL" rather than "MS SQL".

That's why I personally prefer "MVC web app with Visual Studio Code on macOS or Linux" tutorial to others, because it makes sense as a standard way to do the job.

it's like users expectations in Microsoft Windows applications:

No windows user expects to see "Exit" option under the "Help" menu, they look for this option under the "File" menu!

Thank you for the docs!

[davidfowl]

@rseyf have you given razor pages a try?

[rseyf]

@davidfowl Yes of course I did, Razor is ASP.NET Core application plus extra configurations. My answer is about the documentation and what developers expected to read for the first topic.

I'm suggesting to start "Cross platform tutorials" section with "MVC web app with Visual Studio Code on macOS or Linux" instead of Razor pages.Because Razor pages are based on Visual Studio IDE and it's confusing to start with for other platforms developers.

Any Ideas?

[Rick-Anderson]

.Because Razor pages are based on Visual Studio IDE and it's confusing to start with for other platforms developers.

That's not correct.

[rseyf]

@Rick-Anderson
The first link is:
https://docs.microsoft.com/en-us/aspnet/core/tutorials/razor-pages-mac/?view=aspnetcore-2.0

Prerequisites: Visual Studio for Mac

[Rick-Anderson]

Follow the VS Code version

[rseyf]

@Rick-Anderson , @davidfowl ,
I know that there is a VS Code tutorial for it, I have no problem with starting with MVC with vs code nor VS Enterprise, and I know the difference of VS code & Visual Studio IDE. That's not what I mean to say.

Imagine a person who is a Python and Django developer and wants to read about .Net Core MVC itself. (let's ignore Razor as a new term for him/her), documentation categories are so confusing and the first cross-platform tutorial starts with Visual Studio / Visual Studio Code . He/She cannot find any tutorials just about the framework itself. it's a really HUGE problem.

I'm trying to say it's COMPLETELY WRONG to create a web framework documentation on a special IDE or code editor specifications. it should start with an independent tutorial just about the MVC framework itself.

That's why I'm suggesting to change the order of the "cross platform topics" links to make it less confusing.

Can you find any IDE or Editor names in a documentation of other professional web frameworks?

• https://symfony.com/doc/current/index.html
• https://projects.spring.io/spring-framework/
• https://docs.djangoproject.com/en/2.0/intro/tutorial01/

???

[davidfowl]

Unlike those frameworks, most of our frameworks have tooling that come with it. The moral equivalent to that is the CLI scaffolding that most of those frameworks offer.

Symphony has composer:

Spring has guides based on various package managers or IDE:

The java ecosystem is most similar to .NET which is why you see things that look similar.

So it's not odd to create a tutorial based on the tool and it's not uncommon to see that in other language ecosystems.

[JAugustoGuimaraes]

@davidfowl Ok, build tools for MVC!! ...Give to us the freedom!! I will never be locked with Microsoft way any more!

[JAugustoGuimaraes]

Why not the standard MVC? Microsoft don't like standards?
Please, tell me what is wrong with MVC!!?? You don't like controllers?? It's too hard??
Whats is the advantage of RazorPages (.aspx style) ? Show us a reason to change!!

[Rick-Anderson]

Please, tell me what is wrong with MVC!!?? You don't like controllers?? It's too hard??
Nothing is wrong with MVC, it's all about what RP (Razor Pages) do better.

Whats is the advantage of RazorPages (.aspx style) ? Show us a reason to change!!
Having migrated MVC with EF Core to RP with EF I found many advantages:

No more passing data with messy ViewData. Use the build-it view model you get with PageModel.

No more weird overloads to disambiguate Get/Post methods

Razor pages give less fragmented code than MVC - No more hunting several folders over for a matching view to a controller method.

BTW, MVC is not a standard.

[rseyf]

@JAugustoGuimaraes Please don't spam in this github issue. As you know, one of the .NET framework cross platform architects is Miguel de Icaza, one of the most notable developers of linux kernel/Gnome/Mono/Wine and other OSSs so if you don't like the Microsoft , please express your emotions outside of this issue page.

If you want to start a discussion with me about this or spam , my email address is [email protected] .

So please just submit technical issues about documentation here.

Thanks.

[JAugustoGuimaraes]

I have a lot of projects on VS2013 and the tecnical issue is the need to remake all applications because the standard MVC has no future any more and the reason to change is not acceptable. I was expectating and believing a lot in Asp.Net Core. I don't like this kind of Microsoft bahavior.
I will not spam this issue anymore and I will not wait for any thing bether from Microsoft.
I lost my time waiting for ASP.Net Core to update the all applications and I will move all applications to PWA (React, Vue, Angular, etc). Thank you all to make clear the direction to follow.

[davidfowl]

@JAugustoGuimaraes you'll be happy to know that Razor pages is part of MVC. They are built from the same core and share 80% of the features. If you prefer to use the MVC pattern with views feel free to continue doing so, it's not going anywhere.

[JAugustoGuimaraes]

@davidfowl, Thank you. Yes, a litle bit more of life. As you know, the first ASP still working today, but without any new feature or tools. With focus only on RazorPages (like many examples in Asp.Net Core Docs) MVC will be like ASP soon. Have you tryied to migrate a usefull real MVC application that uses OAuth2 from Asp.Net core 1.1 to 2.1 without tools? ...and about migrate from Asp.Net 4.6/7? My read from Microsoft is forget the path to grow of current things and bring back the old ones ( ..like Web Matriz/.aspx pages). Lets wait for Asp.Net Core 3 to see whats is the way!!

[davidfowl]

@davidfowl, Thank you. Yes, a litle bit more of life. As you know, the first ASP still working today, but without any new feature or tools.

Except that's completely untrue we invest in both since it's the same framework.

Have you tryied to migrate a usefull real MVC application that uses OAuth2 from Asp.Net core 1.1 to 2.1 without tools? ...and about migrate from Asp.Net 4.6/7?

We made breaking changes from 1.1 -> 2.1 in auth and it is hard to convert and we're not going to be doing that again any time soon. That was one of the big breaks we made.

However, it's completed unrelated to RazorPages.

[JAugustoGuimaraes]

you're right!

[mmcconnell1618]

Razor Pages mix code and presentation and I'm more familiar with MVC style. When getting up to speed with Core vs. Framework I find it easier to map Framework MVC to Core MVC rather than adding a whole new model with Razor Pages.

[davidfowl]

Razor Pages mix code and presentation and I'm more familiar with MVC style.

Have you tried razor pages or are you just extrapolating from looking at a few samples? I'm asking because thats the usual thing people say when they haven't taken a deeper look.

[mmcconnell1618]

Yes, just looked at a few examples. I haven't tried building a new project with Razor Pages so I'm sure I don't have a 100% grasp of everything. I'm just providing initial impressions based on the Docs.

[davidfowl]

Yes, just looked at a few examples. I haven't tried building a new project with Razor Pages so I'm sure I don't have a 100% grasp of everything. I'm just providing initial impressions based on the Docs.

Give it try on the next project (even if it's a toy), we've seen a bunch of people flip when they realize what is really is.

[gyurisc]

@David, Would you mind to explain what Razor page really is? It would be
nice to hear a qualification. It seems we completely misunderstood what
Razor pages are and I would not mind some clarifications.

On Fri, May 25, 2018 at 6:55 PM, David Fowler [e-mail]
wrote:

Yes, just looked at a few examples. I haven't tried building a new project
with Razor Pages so I'm sure I don't have a 100% grasp of everything. I'm
just providing initial impressions based on the Docs.

Give it try on the next project (even if it's a toy), we've seen a bunch
of people flip when they realize what is really is.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-392118529, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAwRJZxkTyijq_5zvJevD3KC-NtWrCVoks5t2DefgaJpZM4TtY4A
.

--
twitter - twitter.com/gyurisc
blog - http://www.littlebigtomatoes.com/

[Rick-Anderson]

Would you mind to explain what Razor page really is?

See Introduction to Razor Pages

[EntityAdam]

The issue at hand is "Why choose MVC tutorials over Razor Pages" not, "Why choose MVC over Razor Pages" and I see why this issue is full of Razor Pages hate.

The bullet following the link to this issue makes a dangerous statement.

Is the preferred approach for new application development.

What makes it dangerous is what is not being said, which is that Razor Pages and MVC are not mutually exclusive like MVC / WebForms were. Razor is a view engine and you should not have to depend on a Controller. Razor Pages facilitates better architecture and are (as they should be) an implementation decision. etc.

Old MVC5 would have Views, Models and Controllers all in one project. Whereas now, you can build a REST API using the Web API template, and then create new Razor Pages project to sit on top of it as the UI, and if the requirements change, you can swap out Razor Pages for one of the SPA template projects.

Each tutorial is showing a full application being built and each of which has multiple layers of abstraction. I think what is being missed is how much it is much easier it is to separate the layers of abstraction because those who have been using older versions of MVC for many years haven't had that option, or it was difficult to accomplish with the framework at the time.

In my humble opinion, I think it would be better to take the time to explain why MSFT and team are leaning towards Razor Pages, and what value it provides the devs.

[Rick-Anderson]

@EntityAdam thanks for the comments. We're working on a doc to explain our recommendation. I think that will help once we link to the RP v MVC doc.

[ttutisani]

I am leaning towards using MVC over Razor pages, because:

Razor pages seems (and clearly is) sort of resurrection of WebForms. It has codebehind cs files to corresponding pages, which maybe simplifies exposing page class properties to the page markup. That should somewhat reduce number of code lines written. And maybe that's what WebForms developers liked. But that also brings back the feeling that you can write anything in the codebehind - first step towards problems. Separation of concerns was what made MVC to much more preferred. That separation is not so clearly expressed with codebehind files. Helping save number of code lines does not buy clear separation of concerns. We already learned that lesson.

Another thing I noticed was - Razor pages markup again tries to introduce html abstractions. I think this is a huge mistake. Developers jumped into MVC because it allowed better control of the final HTML. People are not bad at HTML anymore guys. I don't want to see these in my markup and then guess what the final output will be like (or will the final html have exactly these inside???):

asp-validation-summary="All", asp-for="Customer.Id", asp-validation-for="Customer.Name", asp-page-handler="delete", asp-route-id="@contact.Id".

_Update: I noticed these are in the MVC side too. Html helpers... So maybe this part does not make the Razor any worse than MVC. I still prefer to decide myself where I put the url to the action, by getting the action url as string (such as old Url.Action() call). I hope that is still possible, at least in MVC_

Overall, looking forward to see the promised recommendation from Microsoft as to why the Razor pages is recommended. And it better be a good explanation. And if not, I also would like to suggest changing the documentation and recommending MVC as opposed to Razor. Please don't jeopardize the achieved positive reputation that came with ASP.NET MVC long time ago.

I wanted to add this: Razor pages seems suitable for simple projects. I can't imagine growing complex project done using this approach. I would rather state the recommendation this way.

[myronrogersrogersgmailcom]

I am choosing to start with MVC over Razor because MVC is established and maintenance of MVC is in demand. Razor will be a second thought. I am not seeing any demand for Razor in my area.

[davidfowl]

@ttutisani have you tried razor pages? This is usually the feedback we get when people look at the template but don't actually use it.

[ttutisani]

@davidfowl no I haven't tried, but I read the whole tutorial around it. Would you try something that does not seem attractive?

Is there another github issue that describes why people chose Razor over MVC? That would be helpful to read. Otherwise I'm not trying it.

I don't like the concept behind it so far.

[davidfowl]

It's streamlined for view/page focused applications. There's a razor file and a PageModel (which acts like both a controller and a view model combined into a single type). Everything else is shared with MVC. In a sense, its like having controller per page with each action being one specifically for that page. Here's an example that might help visualize it:

MVC

Controllers/AboutController.cs

```C#
[Route("/about")]
public class AboutController : Controller
{
[HttpGet]
public IActionResult Index() => View(new AboutModel { Message = "Hello World" });

 // Image a form post doing something relevant here
 [HttpPost]
 public IActionResult Post() => View();

}

Models/AboutModel.cs

```C#
public class AboutModel 
{
    public string Message { get; set; }
}

Views/About/Index.cshtml

@model AboutModel

@Model.Message

Razor Pages

Pages/About.cshtml.cs
```C#
public class AboutModel : PageModel
{
public string Message { get; set; }

public void OnGet()
{ 
    Message = "Hello World";
}

public void OnPost()
{
}

}

Pages/About.cshtml

```cshtml
@model AboutModel

@Model.Message

[myronrogersrogersgmailcom]

I currently prefer the MVP page concept with my android applications. I
am sure I would personally prefer it with c#. However comming off the
as400 platform with some android Java background my number one gole is to
become employees again on the east coast. In the east us employers are
more concerned with the candidate meeting exact specifications than
employers in the Midwest. There will be over 50 as400 candidates released
here in Jacksonville fl between now and 2020. There are only two or three
as400 shops left and no one does android java as a primary.

On Fri, Jun 15, 2018 at 2:04 PM, Tengiz Tutisani [e-mail]
wrote:

@davidfowl https://github.com/davidfowl no I haven't tried, but I read
the whole tutorial around it. Would you try something that does not seem
attractive?

Is there another github issue that describes why people chose Razor over
MVC? That would be helpful to read. Otherwise I'm not trying it.

I don't like the concept behind it so far.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-397699613, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75eXmJRRupn4MQLoAzP0OulqIvSOjks5t8_cXgaJpZM4TtY4A
.

[ttutisani]

@davidfowl That actually makes sense. Sounds similar to MVVM, where ViewModel is both a page model and a page specific controller. Obviously, you could not support 2-way bindings in the web, so you added OnGet/OnPost support to it, that to handle interactions initiated by the page towards the PageModel.

Now I get it. Maybe you should describe this and emphasize on the conceptual design in the Razor pages tutorial. More people would buy in. Especially if you could draw associations with one of the existing application patterns such as MVVM.

So, looking at it again from MVC standpoint, it's little bit unnatural to envision a page model that needs to be bound back on every request. Some properties will not have values because you didn't set them yet. Some properties will have values because they were sent down to the page... Just like WebForms used to maintain the ViewState (I guess that's what the page state was called). Persisting that state between requests is a strange concept. Some people at Microsoft definitely like this concept of maintaining state between requests. But I consider stateless design more natural fitted to web (after all, web is stateless).

Anyway, now that I understood the design goals, I clearly see the tradeoff. I still prefer MVC, because I prefer stateless architectures (at application level; otherwise it will sound anti-OOP). Especially for web.

Thanks for explaining the Razor pages! Definitely makes sense. I hope others got the cleaner idea too.

[lenj962]

This is an interesting discussion. I've worked with WebForms and MVC, as well as, Razor pages. There are lots of options (I like lots of options); but with options comes the need to know the issues so that the correct or best one is chosen. I like the way that Razor pages give less fragmented code than MVC. If we have a ToDos page, I prefer have the UI and the logic defined as much as possible in one place, the cshtml/cshtml.cs pair. Now, if you are going to make AJAX calls, then you have to address the scripts and the services. Lots of choices with tradeoffs. Keeps things interesting.

[myronrogersrogersgmailcom]

I don't prefer mvc. I just want a job on the east coast. Comming off of
one platform to another I know that I will have to begin with legacy
maintenance and then earn my spot in new development. Razor wiould be a
new development tech. I love bleeding edge but more importantly I need a
job. None of the Jacksomnville sies on indeed or dice want anything other
that .net MVC. No search results for Razor or anything else. This would
not be a show stopper in Dallas or CA, etc. On the east coast employers
are real sticklers for exact skill matches. The legacy code her is MVC.

On Fri, Jun 15, 2018 at 3:22 PM, Tengiz Tutisani [e-mail]
wrote:

@davidfowl https://github.com/davidfowl That actually makes sense.
Sounds similar to MVVM, where ViewModel is both a page model and a page
specific controller. Obviously, you could not support 2-way bindings in the
web, so you added OnGet/OnPost support to it, that to handle interactions
initiated by the page towards the PageModel.

Now I get it. Maybe you should describe this and emphasize on the
conceptual design in the Razor pages tutorial. More people would buy in.
Especially if you could draw associations with one of the existing
application patterns such as MVVM.

So, looking at it again from MVC standpoint, it's little bit unnatural to
envision a page model that needs to be bound back on every request. Some
properties will not have values because you didn't set them yet. Some
properties will have values because they were sent down to the page... Just
like WebForms used to maintain the ViewState (I guess that's what the page
state was called). Persisting that state between requests is a strange
concept. Some people at Microsoft definitely like this concept of
maintaining state between requests. But I consider stateless design more
natural fitted to web (after all, web is stateless).

Anyway, now that I understood the design goals, I clearly see the
tradeoff. I still prefer MVC, because I prefer stateless architectures (at
application level; otherwise it will sound anti-OOP). Especially for web.

Thanks for explaining the Razor pages! Definitely makes sense. I hope
others got the cleaner idea too.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-397718740, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75SIGdtwKkCEsIriBj6X-epuI_yqOks5t9AlmgaJpZM4TtY4A
.

[myronrogersrogersgmailcom]

I have a lot of programming experience. In one shop that is based on the
lead man theory here on the east coast, and several that where based on the
cowboy development theory in the Midwest. The lead man theory says you use
the pattern that your told to use. The cowboy theory says you get to
pick. On the east coast most development is based on the lead man theory.
MVC is what they want. Most likely only the old established hands in a
shop will enjoy the spotlight and pay associated with new tech.

On Fri, Jun 15, 2018, 4:29 PM Leonard E. James [e-mail]
wrote:

This is an interesting discussion. I've worked with WebForms and MVC, as
well as, Razor pages. There are lots of options (I like lots of options);
but with options comes the need to know the issues so that the correct or
best one is chosen. I like the way that Razor pages give less fragmented
code than MVC. If we have a ToDos page, I prefer have the UI and the logic
defined as much as possible in one place, the cshtml/cshtml.cs pair. Now,
if you are going to make AJAX calls, then you have to address the scripts
and the services. Lots of choices with tradeoffs. Keeps things interesting.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-397733516, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75XGG7VAgLAc49pbrwkU_WTgwky4pks5t9Bk_gaJpZM4TtY4A
.

[lenj962]

I understand the sentiment. There is the golden rule, "Them that got the gold (or at least control the gold) make the rules" I am in Texas, but that make little difference. Currently, I am independent and working on my own stuff. I have a lot of experience and I have learned not to be too tied to a single approach. There are always trade-offs. Not insignificant is to avoid conflicts with the boss, I've, also, seen bad things locked into legacy that sometimes need to change and endure and overcome the associated discomfort to achieve major improvement (however that is defined). I won't "die in a ditch" for little gain.

[myronrogersrogersgmailcom]

Yeah I just wish I was in the middle or west coast at my age. It's a lot
different if your a cowboy.....

On Fri, Jun 15, 2018, 5:54 PM Leonard E. James [e-mail]
wrote:

I understand the sentiment. There is the golden rule, "Them that got the
gold (or at least control the gold) make the rules" I am in Texas, but that
make little difference. Currently, I am independent and working on my own
stuff. I have a lot of experience and I have learned not to be too tied to
a single approach. There are always trade-offs. Not insignificant is to
avoid conflicts with the boss, I've, also, seen bad things locked into
legacy that sometimes need to change and endure and overcome the associated
discomfort to achieve major improvement (however that is defined). I won't
"die in a ditch" for little gain.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-397752019, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75Se-b0yoJvkNbYJYu4mSlw4R1JGoks5t9C0bgaJpZM4TtY4A
.

[davidfowl]

@ttutisani

So, looking at it again from MVC standpoint, it's little bit unnatural to envision a page model that needs to be bound back on every request. Some properties will not have values because you didn't set them yet. Some properties will have values because they were sent down to the page... Just like WebForms used to maintain the ViewState (I guess that's what the page state was called). Persisting that state between requests is a strange concept. Some people at Microsoft definitely like this concept of maintaining state between requests. But I consider stateless design more natural fitted to web (after all, web is stateless).

What do you mean by this? There's no state here. It's stateless, just like MVC...

[codehaks]

I was not using RazorPages before 2.1 release, But after giving it a try now I'm not going back. I start everything with a Razor page unless I need something more. For me, the key benefit is the way you approach to develop your web project.

With MVC 80% of the time, your goal is to show some data on a view. But you don't start by creating the View, You start by creating a Controller containing the Action containing the Model you want to end up on the View. So the approach is top to bottom. You end up doing a lot more than you actually need because you have to think with a broader perspective, the Controller you are defining probably going to be used for many other Actions.

With Razor pages, you start with the view which is your actual goal, if you need more stuff to be on that view you can add a PageModel, if you need a method to prepare that model for you then you add the method, and that's it, you never need a controller. so the approach is bottom-up.

With RazorPages you write less code simply because you write code only for the things you actually need, You don't write code just because the structure of the framework forces you to do so.

[amoerie]

If may address some criticism on MVC here:

No more passing data with messy ViewData. Use the build-it view model you get with PageModel.

ViewData is a seriously abused feature. In the 7 years that I've been developing with .NET MVC, I've always use typed viewmodels and very, very rarely had to resort to using ViewData/ViewBag.

No more weird overloads to disambiguate Get/Post methods

Do you have samples? POST actions usually have a form bound object the GET actions doesn't.

No more hunting several folders over for a matching view to a controller method.

The dependency on Tooling has been criticised here in this thread, but this problem has long been solved by Resharper / Rider and maybe other tools too. Although I do agree that MVC has a lot of magic strings going on, and with the Introduction of untyped resource files (the so called ILocalizers) this is only getting worse.

[Rick-Anderson]

No more weird overloads to disambiguate Get/Post methods

Do you have samples? POST actions usually have a form bound object the GET actions doesn't.

Usually is the key word. See this tutorial

Examine the Delete and DeleteConfirmed methods.

// GET: Movies/Delete/5
public async Task<IActionResult> Delete(int? id)
{

...

// POST: Movies/Delete/5
[HttpPost, ActionName("Delete")]
[ValidateAntiForgeryToken]
public async Task<IActionResult> DeleteConfirmed(int id)
{

[amoerie]

Fair point. I never use separate GET actions for delete actions, instead I display a modal dialog that asks for confirmation. So I've been unknowingly avoiding this problem for a long time, haha.

But still, is it really that awkward. The GET method asks for confirmation, the POST method actually performs the deletion. This warrants separate method names and isn't that awkward.

To circle back to the main issue: I can see Razor Pages being useful for very simple scenarios and for things like SPAs where you don't want the server to do much of the heavy lifting.

But as this thread clearly demonstrates imho, if Microsoft doesn't clearly communicate the intended use cases for Razor Pages, I can see this being abused too in the future.

[ttutisani]

@davidfowl

What do you mean by this? There's no state here. It's stateless, just like MVC...

This is what I mean (taken from Razor pages page):

```C#
public class CreateModel : PageModel
{
private readonly AppDbContext _db;

    public CreateModel(AppDbContext db)
    {
        _db = db;
    }

    [BindProperty]
    public Customer Customer { get; set; }

    public async Task<IActionResult> OnPostAsync()
    {
        if (!ModelState.IsValid)
        {
            return Page();
        }

        _db.Customers.Add(Customer);
        await _db.SaveChangesAsync();
        return RedirectToPage("/Index");
    }
}

```

Customer property on this PageModel will act like a page state if you assign to it in OnGet and then read it OnPost just as the example code does. That's very similar to what we all used to do with WebForms: first load puts data into Page properties, then postbacks take the data back to the page serverside interaction handlers (page load, event handlers, etc). Razor pages somewhat repeat that flow by binding the properties. And this makes the PageModel somewhat stateful, as opposed to stateless.

Now, if we could stop on just the model (Customer) binding, that would be awesome, because then you just helped developers keep the model-related get/post methods together. But nothing stops us from abusing it - that's the core of my concern. What will end up happening is (just as it happened to WebForms), people will start adding more and more properties to the PageModel, and will start tangling different get/post methods on the PageModel so that they all touch same properties, they all read or modify them in many different ways. This is spaghetti. Again, this is not what PageModel is itself, but this is the design that it's inviting.

I like the similarity with MVVM, but I think it won't work with the same success for web. Importantly, MVVM is a stateful pattern. It does not depend on the other side (view) implementation so much (i.e. if you have a value in the ViewModel property, it stays there even if the view does not bind it back). PageModel on the other hand depends on the View to stay consistent (i.e. Customer property will become null if View does not send form data back to OnPost).

Overall, I honestly think that Razor pages are for simpler page-based scenarios. But due to its invite to abuse and anti-patterns, I would not recommend using it for complex web applications.

I hope I was able to express my concerns clearly.

[tstivers1990]

Maybe my definition of a code behind file isn't accurate, but I wouldn't really consider the PageModel in Razor Pages code behind. Code behind, for me, is typically defined by the partial class declaration. I'm not familiar with Web Forms, but I know this is at least the case with WinForms, and based on a quick Google search, it appears to be the case with Web Forms as well. PageModels are not partial classes. They're entirely separate entities that can be moved to a separate folder if one wishes to do so, and can be renamed at will.

Perhaps the documentation should remove the term code behind. In reality, PageModels are ViewModels. They only appear to be code behind in Visual Studio because the IDE automatically groups files that match the pattern [FileName].[ParentExtension].[Extension]. They're completely decoupled from the view, though. Unlike WinForms and Web Forms code behind files, which are partial classes that are tightly coupled to the view. PageModels should be referred to as ViewModels instead of code behind because, in reality, that's what they are.

[tstivers1990]

@ttutisani

But nothing stops us from abusing it - that's the core of my concern.

And nothing will. You can't prevent bad programmers from writing bad code. You can only provide them with tools that allow them to write good code. PageModels encourage bad code no more than MVC does. In a lot of ways, they make it easier to write good code. There's a greater separation of concerns with Razor Pages. Take a look at the old AccountController implementation for MVC project templates and compare it with the new Razor Pages implementation. The new Razor Pages approach is far cleaner than the old AccountController approach. This is the benefit of using Razor Pages over MVC. You don't have to use CTRL+F to find the method you're looking for like you did with the old AccountController.

[Rick-Anderson]

Perhaps the documentation should remove the term code behind.

I agree.

@davidfowl @DamianEdwards do you concur?

[DamianEdwards]

If it's hurting more than it's helping, sure. Ultimately it's about the PageModel class so we should call it that.

[ttutisani]

All right, we all understood each other's points to some extent. I need to make a slight correction though - I said Razor Pages _invites_ for bad design, while MVC does not. Although, bad design can be achieved by both in certain cases.

I do have a very important question: why specifically is it recommended to use Razor Pages over MVC? why are they not provided as just mere alternatives? what's in it for Microsoft?

I personally would just see what goes better and would collect equal feedback for both. I would even invest more into what's more popular - because that's just how business works.

But there is a slight interest expressed in documentation for promoting Razor Pages. Why? Altruism?

[davidfowl]

I said Razor Pages invites for bad design, while MVC does not. Although, bad design can be achieved by both in certain cases.

I don’t see how. It actually gives you a view model separate from your domain model out of box.

I do have a very important question: why specifically is it recommended to use Razor Pages over MVC? why are they not provided as just mere alternatives? what's in it for Microsoft?

Because we think it’s a better way to write page centric applications (anything with views really).

[ttutisani]

@davidfowl

I don’t see how. It actually gives you a view model separate from your domain model out of box.

I tried to explain already. In short, it creates path for having stateful Page Models, which (in my strictly personal opinion) is a way to have exact same spaghetti problems as we had with WebForms. I already wrote everything with my previous answers. Sorry if that's not clear.

But I do understand that in some cases I may decide to use Razor Pages over MVC. So far, that's not my preferred approach. But I appreciate the discussion - it helped me clearly see the point of Razor Pages. Whether it's a good design choice for concrete web applications - that probably will stay a subjective choice of each developer.

[tstivers1990]

I do have a very important question: why specifically is it recommended to use Razor Pages over MVC?

The primary reason I chose to start using Razor Pages over MVC is because it gets rid of the massive controller problem that exists within MVC. Each PageModel is only responsible for itself. Whereas with MVC, a Controller is responsible for multiple Views and ViewModels. MVC is still the logical solution for the API portions of ASP.NET projects, though. And because it wouldn't make sense to implement API in Razor Pages, MVC is almost certainly going to co-exist with Razor Pages, rather than Razor Pages replacing MVC.

[Rick-Anderson]

I really discovered the productivity advantage of RP over MVC when I ported RP with EF Core from the MVC version

• When I needed to update the Create RP I didn't need to hunt for it in a controller - with the associated view that's far away in the file system.
• Built in view model.

[tstivers1990]

I tried to explain already. In short, it creates path for having stateful Page Models, which (in my strictly personal opinion) is a way to have exact same spaghetti problems as we had with WebForms.

There's no real reason you would implement stateful PageModels, though. You would genuinely have to work to implement stateful PageModels. If you attempt to do so, there's a strong chance you're going to realize early on that it's the wrong approach.

[davidfowl]

I tried to explain already. In short, it creates path for having stateful Page Models, which (in my strictly personal opinion) is a way to have exact same spaghetti problems as we had with WebForms. I already wrote everything with my previous answers. Sorry if that's not clear.

I don’t see it sorry, there’s no state and it doesn’t look stateful IMO. We can agree to disagree.

@tstivers1990 that’s exactly it!

[ttutisani]

Awesome, just what I expected. Thank you!

I think it would be nice (and it would also help sell RP idea) to have a real-life case study (not demo projects) from real company, real team, real product. Large, complex project. What was the experience with RP. Pros and Cons.
I'm also going to try this. But I'd love to hear how it really went for those who tried it. Not just in the beginning, but with lots of problems solved with it.

Anyway, I guess I've exhausted my point. Thank you!

[donniefitz2]

I built a pretty large web app with Razor pages. In hindsight, I think MVC would have been a better fit although RP did a decent job. I found the development experience a little clunky once things really started to get complex. The models felt limiting.

Site in question: https://urgentcare.bannerhealth.com/

[Syndaryl]

Answering the actual question from the issue (not "why are you using Razor Pages tutorials instead of MVC tutorials", which is the opposite).

I'm using the MVC tutorial because my boss told me to learn MVC. We have existing applications developed using it, will be continuing to use it. If I want to work, I need to know how to work.

Frankly I find the tone of the original note to be somewhere between bizarre and offensive. I'm using the MVC tutorial because I need to learn about MVC.

[scottsauber]

We're using Razor Pages for a multi-tenant Health Insurance portal where HR Admins can CRUD on employee data, run reports, upload docs, download docs, billing statements, etc. and the employees who are insured can see details about their Health Insurance, change it, download docs, etc.

We have 60+ pages and I can say that for Server-rendered HTML, I will never go back to MVC. It's just a better fit for server-rendered HTML apps. It's also not just for simple things. The Health Insurance domain is inherently complex and combine this with the fact that it's a multi-tenant app (we sell the product to other insurance companies), which adds more complexity as the app is highly configurable as different insurance companies do things a bit differently.

Why use it?

• Razor Pages is more secure by default. Razor Pages gives you AntiForgeryToken validation by default. Plus you opt-in to what properties you want to be model bound via [BindProperty] which limits your exposure to over-posting attacks.
• Razor Pages has a better folder structure by default that scales better. In MVC, the default folder structure simply does not scale. Having separate folders for Views, Controllers, and often ViewModels when all three are ultimately tightly coupled to one another is a huge PITA to work with. You end up bouncing to all 3 folders and navigating a bunch anytime you need to add or change a feature. It's horrible. This is why I advocated for Feature Folders. With Razor Pages, your PageModel (Controller + ViewModel) are in the same folder as your View. You can just hit F7 to toggle between them which is also super convenient.
• Leads to more maintainable code that scales better. With MVC it was super easy to bloat a Controller with 10+ Actions. Often, these Actions weren't even related to one another in any way (except maybe a Redirect between the two). This made navigating the Controller to find code very difficult. It got worse if there were private methods in the Controller too, further adding to the method bloat. With Razor Pages, it's nearly impossible to bloat up your Page Model with unrelated methods to your page. Everything you put in your PageModel is related to your Page.
• Unit Testing is easier. With a Controller, you might have 8 Actions and some of your dependencies you inject in were only related to one or two Actions. So when unit testing a single Action either you need to mock those out unnecessarily or pass a null, both of which feels gross (this can be solved a bit with the Builder pattern). With Razor Pages, the dependencies you inject in are 100% related to GET and POST actions you're working with. It just feels natural.
• Routing is easier. By default in Razor Pages, routing just matches your folder structure. This makes nesting folders way easier to accomplish. For instance, all of our HR Admin pages are under the /Administrator folder and all the Employee pages are under the /Employee folder. We can authorize an entire folder and say the person must be an Administrator to get to any subfolder of /Administrator, which was way easier to do that than with multiple Controllers that make up the Administrator features.

I think that's the big stuff.

Some stuff we do that has helped us:

• Make constants files for your Page routes vs magic strings. An example might look like this.
• Put the InputModels/ViewModels in a separate file (living in the same folder, right next to the RazorPage it belonged to) vs. an inline class in the PageModel. We found this was easier to reason about and de-cluttered the PageModel because we had some pages with lots of input fields. Although I know some people feel the opposite about this.

Hope that helps clear up why we chose Razor Pages and why we won't willingly go back to MVC for server-rendered HTML apps. If you're not rendering HTML server-side and you're just writing API's for a React/Angular/Vue/whatever front-end, then don't use Razor Pages, use MVC.

[augustobotossi]

I am building a project where I get some information based on a webpage filled out by the user, that information is used to create a URL that runs a third party API. The result expected is a JSON with a list of items (it could be over 200 items) with 10-11 fields. I was able to make it work with a Controller, but not with Razor Pages.

[shaunluttin]

Why choose MVC tutorials over Razor Pages

The team I am on is already using MVC.

have you used Razor Pages?

No. I am interested in them, though, and would like to.

On that point, I suggest introducing RazorPages as a new feature of MVC and not as an alternative to it. That way, teams will feel more comfortable using RazorPages in an existing MVC app. To elaborate, I would introduce RazorPages in the same way that MSFT introduces ViewComponents and TagHelpers. ViewComponents are an alternative to PartialViews, TagHelpers are an alternative to @Html syntax, and RazorPages are an alternative to Views. If we do not take that approach, I fear that my team will say, "We're not switching from MVC to Razor Pages." What I want them to say instead is: "Sure, let's use a RazorPage instead of a View for the application's FooBarBaz page." To summarize, lets make sure that people see RazorPages as just another good feature of MVC that works with existing MVC projects.

[marcolee149394]

.Net Entity is worse framework comparing to Java JPA or Hibernat. They don't know how to build it and copy the concept from Java

[myronrogersrogersgmailcom]

Hmm never mind. Im going with Dart. I'm thinking there is an easier way.
Ask google.

On Mon, Jul 2, 2018 at 11:17 AM, marcolee149394 [e-mail]
wrote:

.Net Entity is worse framework comparing to Java JPA or Hibernat. They
don't know how to build it and copy the concept from Java

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-401839915, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75XNFheh4Yh9_VtOUlcx7O0EJcIMbks5uCjmkgaJpZM4TtY4A
.

[GocePetrovski]

I get the feeling that there is nothing wrong with MVC itself just people were abusing it and now this is supposed to solve that problem. Considering MVC was "better" than WebForms, and from a high level, this looks like WebForms++ I'm not buying it. This pattern of chasing the next shiny thing is so MS typical and it is the reason I limited the usage of .NET in my work...

Bloated Controllers is an issue on about every platform that is using it, but that means you need better development practices instead of different (or going back to the old way) approach. Any class can be bloated, right?

Maybe people should learn a bit form DHH and in general, ROR how to best use MVC...
Anyway, other reasons I prefer MVC is because I develop mobile apps and variations of MVC is what I use on both platforms, so with MVC "I feel at home". Also, Web APIs that are required by most apps are best done using MVC.

[scottsauber]

Bloated Controllers is an issue on about every platform that is using it

Doesn't that kind of speak to the inherent problems with MVC then? If, as you say, every platform that has it abuses it?

Razor Pages allows developers to fall into the pit of success much easier than MVC for all the reasons I listed above (really hard to bloat, better folder structure, security, etc.).

Razor Pages also follows an MVVM pattern, so if you're used to Xamarin, you may feel even more at home with Razor Pages than MVC.

I'd be curious why anyone thinks it's like Web Forms other than the page-focused approach and the PageModel has the .cs file extension which is just superficial. Literally 95%+ of the code you copy between MVC + your Razor Page will just work. And the small % that doesn't is usually super easy to convert (like return Page() instead of return View()). For those reasons, it's MUCH more like MVC than Web Forms, and it's not even close.

Again - it's not for every scenario (JSON being one, but you can use MVC + Razor Pages side-by-side if you'd like), but it absolutely crushes the traditional server-rendered HTML scenario.

I'd be curious for you to give it a spin first on a few real pages and then hear your feedback. Like you, I was super skeptical until I actually used it and quickly realized how much better it was for all the reasons I already covered above.

[GocePetrovski]

@scottsauber First, I don't think MVVM is better than MVC.
I don't think PageModel (or ViewModel) is not hard to bloat. For example, the same type of person that adds code that should go into a repository into a controller would insert it into PageModel, right?
Also, mentioning Xamarin is not selling it form me. In fact, it goes the opposite way.

I'm in the process of deciding what to use for the next project and to be honest, and I am leaning towards Vapor which is Swift on the server and using MVC. The reason I am still considering .NET Core is that I have much more experience in it and there it is a much more mature platform. However, this kind of constant changes from MS makes me doubt this is the right choice. Razor Pages is the best way now, how about in 2 years time? Rewrite everything?
I believe the right approach would be to keep improving the current MVC. I hate to say it, but look at Apple, MVC for years and still going strong! They keep refining it. The reason I like platforms like that is that I can focus on building software instead of every few years learning the next best thing.

[twoCansOfTomatoes]

I work in the DevOps realm and trying to learn web development. I want to learn MVC first before moving ahead to Razor Pages since I am pretty new to this and have zero professional experience in web development. Once I understand how MVC works and could flawlessly build a app using the same, I would move to Razor Pages.

[myyandar]

.NetI hate going back to "Asp.Net WebForms in a new can" on the quite. I also hate changing direction every now and then. What is wrong with .Ne Core MVC? Why is Microsoft pushing for Razor pages?

[GocePetrovski]

Here is my dilemma on which way to go. I need a website and API. The website and apps would use API. Ideally, I'd like the API to be a separate website, but for authentication/authorisation simplicity I'll keep it in one for now.

Now, for the API the best approach is MVC. And since I do need the (data) Models and I will have them and for reusability purposes, I will have Views. So I have M and V all I need is C(ontroller). It would have been easier to adopt RP if they just fit nicely in the existing MVC. For example, if they were developed as special/custom type of View or Controller or perhaps ViewController?

I don't like the idea of creating ViewModels for each view(including page) because it just doesn't feel right. Imagine Customer (data) model. Why not use the same model to populate many different views? Why do I need CustomerSummaryViewModel, CustomerDetailsViewModel etc? I have seen projects littered with so many View Models that becomes difficult to follow which model is the original, the source of truth if you like. Who is the actual Customer if I base it on the above.

[shaunluttin]

Why is Microsoft pushing for Razor pages?

...because they make some use-cases much less expensive to develop and maintain. Here is a good use case for RazorPages.

http:/www.mysite.com/about

RazorPages

Pages
    About.cshtml
    About.cshtml.cs

MVC

Views
    Home
        About.cshtml
Models
    AboutModel.cs
Controller
    HomeController

[CezaryStasiak]

I never heard of Razor Pages, and MVC is well known programming paradigm used by basicly everyone. So MVC it is

[Ohwaattnsma]

...because they make some use-cases much less expensive to develop and maintain.

Why not use MVC and Features Folders:

  Feature1
    Index.cshtml
    Features1Controller
  Feature2
    Index.cshtml
    Feature2Controller

[vobrechkov]

I actually kind of like Razor Pages but everyone uses MVC nowadays so good luck convincing people to chose it over MVC. Tried with a couple of co-workers and got more or less the same responses you see here. For certain types of apps I see how Razor Pages can work better than MVC but how do you convince others? For page-based types of apps with lots of forms type of stuff I would actually prefer the Razor Pages approach - you have your markup and back-end codes in the same place instead of Controllers and Views. Yes, I know you can use Feature folders like mentioned but how is that different than Razor Pages at that point? How is Feature1Controller any different than Page.cshtml.cs? And if you wanna do MVC things with Razor Pages you still can. At my work we still have Web Forms product and I think Razor Pages is the best way to potential migration to Core while also keeping a similar way of doing things, hence less of a learning curve and easier migration path. I will try to be your advocate :)

[davidfowl]

I think one of the mistakes is describing Razor Pages as anything other than a feature of the MVC framework.

[erwinroots]

The Introduction to Identity on ASP.NET Core uses "Select an ASP.NET Core Web Application (Model-View-Controller)". I didn't see the equivalent for Razor Pages.

[Rick-Anderson]

@erwinroots it will take us some time to migrate tutorials to RP (Razor Pages). It's usually straight forward to move from MVC to RP or RP to MVC.

[Ponant]

My main issue is the security side of Razor Pages. So far I do not see some sensible equivalent of the @blowdart 's WorkShop. I would also encourage a deeper discussion on why we do not need Antiforgery attributes any more. And then, I really prefer the old MVC tutorials as they have a more thorough discussion on how to implement and manipulate identity.

This razor UI identity class library is just a bad idea in my opinion. Before we just had AddIdentity + Tokens and stores with an ApplicationUser, which made it clear where we start from. Now it is hidden in the library and we need to scaffold and "look for" the things to recover what we want. Razor Pages with a full blown Identity from the beginning is the best way to go, and the user could then generate the ui library if he wishes to. Any serious dev who wishes to go public with his websites will have to use a full blown identity system as he faces GDPR. This issue of identity/security is the only reason why we do not switch to Razor Pages at the moment.

[myyandar]

Hi Rick-Anderson, I can understand the amount of work involved in getting the .Net Core 2.1 MVC tutorials done. Programmers will be patient in waiting because we need it. But will it eventually be done?

[andreassundstrom]

I'm new to ASP.net core development. I first learned razor-pages, but keep getting the feeling that razor-pages isn't enough to learn,why shouldn't I just learn MVC from the start?

[tstivers1990]

I'm new to ASP.net core development. I first learned razor-pages, but keep getting the feeling that razor-pages isn't enough to learn,why shouldn't I just learn MVC from the start?

You should. You should learn both. Razor Pages is built on top of MVC. So it's still useful to know MVC. Most already existing projects you'll work on, if you do that sort of work, will be done with MVC as well. So you'll want to know MVC if you're going to be working on projects that already exist today. Razor Pages is just another tool to add to your toolbox.

[Rick-Anderson]

@myyandar Yes we plan on updating all the tutorials to feature Razor Pages. That will take some time. Fortunately, it's easy to convert from MVC to RP.

[rmast]

We just use MVC for API purposes to use Angular, which is well mentioned as an exception by scottsauber's decisiontree.

[spacecat]

@scottsauber thanks for sharing your experiences with Razor Pages vs MVC. Exactly the types of things you're wondering about as a .NET MVC developer. Btw, I could not get the following to work? Custom key command needed?
"You can just hit F7 to toggle between them which is also super convenient."

@Rick-Anderson @DamianEdwards @davidfowl
What @scottsauber shared is exactly what developers want to hear and know about before diving into a new technology (new MVC feature). Those types of stories + a feature comparison matrix and the MVC vs RP article is done.

[Yaevh]

I don't know if anyone has brought that before, but as of today MVC tutorial is just much more detailed than Razor Pages tutorial, covering complex data model with related data, handling concurrency conflicts, using raw SQL etc., even if it may be somewhat out-of-date in places. So even when you're going to actually use Razor Pages only, you still have to go through MVC tutorial to get a grip of the more complicated issues.

BTW, I don't really agree with people claiming that Razor Pages is an entirely different paradigm than MVC. It's better to think of Razor Pages as MVC with micro-controllers, each controller serving only a single view, with possibly multiple actions for different HTTP verbs. This IMHO helps to keep things clean and separated and prevents having to deal with overbloated controllers with dozens of actions. That said, you still can use traditional controllers in Razor Pages project to do things like AJAX handling and other stuff that doesn't neatly fit into Razor Pages one-controller-per-view paradigm.

[Rick-Anderson]

I don't know if anyone has brought that before, but as of today MVC tutorial is just much more detailed than Razor Pages tutorial,

At least for RP with EF 1-8, the RP version is much more up to date than the MVC version, has best practices, and many improvement over the MVC version. The RP version is 2.1, the MVC is 2.0.

[scottsauber]

@scottsauber thanks for sharing your experiences with Razor Pages vs MVC. Exactly the types of things you're wondering about as a .NET MVC developer.

No problem. Glad it was useful!

Btw, I could not get the following to work? Custom key command needed?
"You can just hit F7 to toggle between them which is also super convenient."

As far as the F7 thing. First are you on 15.7+ of VS 2017? That's when F7 became a thing. If you are, the second thing... are you using Resharper? Resharper remapped this for me too so I had to add it back following this:
https://superuser.com/a/1328538

[iamimbohacker]

Because Razor Pages EF tutorial sucks! It Shows useless scaffolding that impacts beginner developers paradigm and makes them think that it's a proper approach of adding data access to a project. You'd better provide with only restful app with EF tutorial with step by step explanation how to reference EF. people now code UI on angular and react.

P.S: why you have removed documentation from https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/intro?view=aspnetcore-2.1 ? there is only text saying that razor pages is better than MVC

[nazarkryp]

All I wanted to see is that I have to reference EntityFrameworkCore.SqlServer and not razor pages tutorial with Scaffold the student model

[Rick-Anderson]

@iamimbohacker

P.S: why you have removed documentation from https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/intro?view=aspnetcore-2.1 ? there is only text saying that razor pages is better than MVC

Nothing has been removed. It states

This tutorial has not been upgraded to ASP.NET Core 2.1. The ASP.NET Core 2.0 version of this tutorial is available by selecting ASP.NET Core 2.0 above the table of contents or at the top of the page:

[ModelosPR]

I find it a LOT easier to customize html elements, utilizing custom CSS or templates, with MVC. Specially when utilizing JS libraries.

[JasonRosenthal]

I searched for tutorial on how to get started with entity framework 6 project for my brand new Windows 7 wpf mvvm project because I thought that is what I should be using. The 6 page told me that core 2.0 is the thing now. I have no interest in razor or mvc. It used to be easy to start new projects using visual studio. Very frustrating.

[GocePetrovski]

@davidfowl

I think one of the mistakes is describing Razor Pages as anything other than a feature of the MVC framework.

Not sure this is quite true.. for instance, how do you create dynamic breadcrumbs? You cannot look for controllers and actions, right?

[myronrogersrogersgmailcom]

You know the whole problem with development patterns in general is
academic. Patterns are a learning tool intended to be a basis for learning
how to apply theories to software development when they apply. They where
never intended to handicap development by limiting a project to one only
one pattern. We should use patterns when they are appropriate, then mix
and match as needed.

On Tue, Jul 3, 2018 at 10:40 PM, Goce [e-mail] wrote:

I get the feeling that there is nothing wrong with MVC itself just people
were abusing it and now this is supposed to solve that problem. Considering
MVC was "better" than WebForms, and from a high level, this looks like
WebForms++ I'm not buying it. This pattern of chasing the next shiny thing
is so MS typical and it is the reason I limited the usage of .NET in my
work...

Bloated Controllers is an issue on about every platform that is using it,
but that means you need better development practices instead of different
(or going back to the old way) approach. Any class can be bloated, right?

Maybe people should learn a bit form DHH and in general, ROR how to best
use MVC...
Anyway, other reasons I prefer MVC is because I develop mobile apps and
variations of MVC is what I use on both platforms, so with MVC "I feel at
home". Also, Web APIs that are required by most apps are best done using
MVC.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-402346487, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75dV3B0gmqic23QE0R4Qv2yuhwoZoks5uDCsxgaJpZM4TtY4A
.

[jfrancis2]

As someone quite new to this stuff, it's really not helpful when there's no clear way to start a project and a bunch of people arguing about stuff I don't understand. From my point of view, the MVC tutorial looks more detailed but the razor one is easier to follow as it doesn't randomly introduce concepts that i've never seen before. Why is there nothing aimed at beginners? It always assumes a HUGE amount of knowledge that you just can't get from following a tutorial and blindly copying stuff.

[tstivers1990]

@GocePetrovski If I'm not mistaken, Razor Pages work with routes just like MVC does. And you would use the route information to produce the breadcrumb. Though I've never used this, myself. But I highly doubt it's something that can't be done with Razor Pages.

There are few scenarios I've found where Razor Pages don't fit. But you can mix Controllers into a Razor Pages project just fine. For example, WebAPI is something that simply makes more sense on a controller. And if you want to do something like store images in a database and have them accessible via a url, controllers are the solution there as well. I don't think it's stressed enough that controllers and Razor Pages can coexist in a project just fine. And in a project with any level of complexity, it's probably best that they do.

[JDGHHou]

I am coding a Single Page App with many ajax calls to do lookups. When I started on it, I found these tutorials that told me I should use Razor Pages or maybe some kind of hybrid MVC/Razor setup. I started with that and it was working okay, but I got to a point where I couldn't have different models for Partials than for the Main page those partials are on. I don't know how to fix it. Now I'm trying to revert my project back to pure MVC. I shouldn't have messed with Razor at all. The tutorials on Microsoft's site are all over the place - Razor and MVC are completely intertwined throughout. It's really confusing. I can't find any guidance on how to fix this.

UPDATE: Still trying to just do basic stuff in Razor Pages. Articles have guided me now to ViewComponents, but ViewComponents clash with the default Razor Pages implementation that uses PageModel to render the parent page. Models are stepping on each other even though ViewComponents are supposed to be self-contained. Again, articles that I find showing how to use View Components default to showing how to render them from an MVC Controller, not a Razor Page. Microsoft's documentation should be the primary source for education on this but it's a confusing mess.

[macginitie]

Only because the job for which I will soon be interviewing specifically mentions MVC (but not Razor) in the description. Just brushing up a little ;-)

[jaimesalinasgit]

Because MVC is a wider paradigm, more accepted on any company and any language, Razor Pages feels like a step back for .net web development, Microsoft did a great job giving us MVC but with this change, it feels like going in the wrong direction.

[GocePetrovski]

@tstivers1990 sure you can use route information, however it is not like it is subset of it, right? On very simplified high level one could say the folder is same as the controller and each page (Create, Delete etc) is the action, but that is oversimplifying.

Anyway, besides me complaining 😁 , I have taken the plunge, and on the new project, I use RP for the website and MVC for the API. I'm happy to share my approach (below) just in case it does help someone and as well to get it verified just in case I'm going utterly wrong way.

I have two separate websites purely because the API would be used by mobile apps too and I'd like the ability to version it separately to the website which of course would always be updated to use the latest version of the API.

What I find interesting, been doing iOS development for years, the RP design pattern reminds me a lot on Apple's MVC implementation in iOS SDK where the PageModel is kind of like the ViewController. In my implementation, I still use the same (shared library) Models on the API and the Website, but these are pure data transfer models. The PageModel, like a controller, exposes my DTO Model to the Page (view of a sort?) and I have Repositories (Data Sources) that deal with retrieval and saving the models.
The website is simple for now, so it does work for me for now. I figured, if it doesn't scale as complexity grows, I'll start mixing/adding MVC into my website project too and see where I end up.

[armaandh]

i have personally found MVC tutorials easier to follow simply because coming from any other MVC based framework (like Spring MVC), it's much easier to jump in and start mapping your previous knowledge. I think RP can be quite nice for making dynamic web sites, however with the massive amount of information already available on the internet about MVC, it feels far more comfortable to make your application using the MVC paradigm IMO.

[AlgorithmicAscension]

Razor pages feel great for readonly data, but I need to be able to interact with the model, might have complicated hooks, so full MVC is a safer bet. Razor would be my default if not for this reason

[Rick-Anderson]

Razor pages feel great for readonly data

@AlgorithmicAscension why do you say that? The EF/RP series is all about CRUD operations. It was ported from the EF/MVC series. While porting the MVC version to RP I discovered the productivity advantage of RP over MVC.

[AlgorithmicAscension]

@Rick-Anderson thank you for the reference

[Rick-Anderson]

@armaandh

i have personally found MVC tutorials easier to follow simply because coming from any other MVC based framework (like Spring MVC), it's much easier to jump in

Have you tried the RP versions? The RP tutorials were written so they would be easy to follow for folks having no experience. Given RP is so similar to MVC, any MVC experience makes them trivial to follow.

[myronrogersrogersgmailcom]

It's still my opinion that if you want a job with any established firm or
if you wish to maintain legacy apps for "ANYONE", if your new to C# and you
want steady paychecks MVC is first.

On Thu, Aug 23, 2018 at 2:48 PM Rick Anderson [e-mail]
wrote:

@armaandh https://github.com/armaandh

i have personally found MVC tutorials easier to follow simply because
coming from any other MVC based framework (like Spring MVC), it's much
easier to jump in

Have you tried the RP versions? The RP tutorials were written so they
would be easy to follow for folks having no experience. Given RP is so
similar to MVC, any MVC experience makes them trivial to follow.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-415527844, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AGT75ZGLI-FuvPa7tN2okkp-90QrsRK-ks5uTvjtgaJpZM4TtY4A
.

[tstivers1990]

@myronrogersrogersgmailcom Nobody claimed you should only learn Razor Pages, and not MVC. Even if you're working on your own projects, odds are you'll still need to use MVC for some parts, such as an api or mapping images in a database to a url, so you should still know it.

[spacecat]

I think a lot of the confusion is because the tutorials are all over the place. Seriously, I spend lots of time reading docs on Microsoft. The worst thing about it is that I can find info about a topic on multiple domains, docs.microsoft.com, msdn.com, asp.net, azure.com, etc etc , this is what bugs me the most I think. It would be so much easier to have one single domain for one particular technology. Like for helm.io, bootstrap, kubernetes and those types of technologies/doc sites (these are just examples).
I'm not saying it's all bad because I've seen the improvements over the years but there still a lot to be done. One very good thing is the new feedback system (github). I think that is fantastic.

[glfrazier]

I'm not interested in building a web app.

[kimikomotoyama]

I spent an hour trying to find how to make a new web app. I'm new to C#, and also I'm more familiar with MVC. Therefore, I thought instead of coursing through all new concepts, I'd at least stick to a concept I'm more comfortable with so I can focus on learning ASP.NET Core.

[hdbob]

Razor definitely is a a step backwards, architecturally. Also, MSFT's habit is to ship on time, ready or not; Razor is definitely misbehaving in VS2017. It's too untested to be pushed so aggressively.

[WhiteBookmark]

I am an intermediate when it comes to C# and .NET framework but now I decided to start moving into web development, since I am already so familiar with Microsoft technologies, I thought it would be helpful. Despite choosing the latest technology which is ASP.NET Core, I honestly do not find any tutorial that is helpful for beginners.
Sure there are official ms docs but it is so confusing for a beginner in web development like me. Information is just flooded, one after another there is a "new" thing. There should be a proper guide at least for beginners, the way docs are written, its an assumption that one needs to know extensive knowledge in this particular field.
I am right now unable to decide whether I should start building websites using MVC or Razor because I find Razor easy to understand but since MVC is appreciated and seems better by everyone, not sure what to do.

[Rick-Anderson]

@WhiteBookmark

but since MVC is appreciated and seems better by everyone, not sure what to do.

That's not true. Most programmers I've talked to that have actually used Razor Pages (RP) prefer it over MVC for UI development. Most of RP development transfer to MVC dev.

I honestly do not find any tutorial that is helpful for beginners.

Get started with Razor Pages has high ratings and traffic

[Ronkiro]

Everything on Razor Pages tutorial is too fast for a newbie. It may need some time to do basic things, so will try MVC, that i am more adapted to.

[Rick-Anderson]

Everything on Razor Pages tutorial is too fast for a newbie.

RP is actually easier than MVC with controller and views. Go through Create a web app with ASP.NET Core MVC and then go through the same thing for RP

To really see the RP advantage, you'd need something a bit more complicated like Razor Pages with EF Core compared to ASP.NET Core MVC with EF Core

[WhiteBookmark]

Well I am developing a website using RP, learning things one by one now however I decided to skip EF because 1st it seems very complicated, 2nd it looks slow compared to Dapper/ADO.NET

[KaiserSozei87]

I just don't like Razor Pages, at the moment it is too steep of a learning curve for me in certain areas when i already have a million and one other things to do. I will switch............eventually.

[Ronkiro]

RP is actually easier than MVC with controller and views. Go through Create a web app with ASP.NET Core MVC and then go through the same thing for RP

I mean, for Razor Pages i had some problems to start understanding. But for MVC i managed to learn by myself and to do my own application easily.
Razor Pages may be easier to use, but it's harder to understand. If someone is not adapted to the language syntax (i.e. someone that just studied C# and OOP like me, who came from languages like Java and were using Servlets/JSPs) they won't understand.
More experienced developers may have less difficulties on this.

[dsoronda]

MVC is a clean and proven paradigm. While Razor page approach feels like a step backward.

I 100% agree with this quote. RP is a mess.

IMHO, RP breaks SRP by introducing complexity back where it doesn't belong (bringing back fat objects instead of simple POCO ViewModels).

Why are we going back to 2004 and ASP stuff ???

[scottsauber]

IMHO, RP breaks SRP by introducing complexity back where it doesn't belong (bringing back fat objects instead of simple POCO ViewModels).

There's nothing stopping you from having your separated ViewModel with Razor Pages. We use Razor Pages with this approach and our Input Models are all in a separate class and it works great.

// RegisterPage.cshtml.cs
public class RegisterPageModel()
{
     [BindProperty]
     public RegisterInputModel Input { get;set; }
     // Other PageHandlers
}

// RegisterInputModel.cs
public class RegisterInputModel
{
    public string Email { get; set; }
   // the rest
}

Let's not forget that MVC doesn't exactly promote SRP either. How many times have you been in a Controller that's responsible for controlling the Actions of more than one Page? All the time, right?

That's a big area where Razor Pages shines over MVC, it is focused on a SINGLE page.

[mikebrind]

@hdbob I have no problems using VS with razor pages. Perhaps your issues are nothing to do with the RP framework?

Why do you think Razor pages is a "step back"?

[hdbob]

Razor has to run on the server, not the client. So HTML is being sent over the net, not just app data. This is the step back. It’s the state of web technology from the 90s and early 00s. Am I misunderstanding how Razor works?

[dsoronda]

@scottsauber

Let's not forget that MVC doesn't exactly promote SRP either. How many times have you been in a Controller that's responsible for controlling the Actions of more than one Page? All the time, right?

That is not the point. Purpose of Controller is to response to actions. It is his responsibility.

Razor responsibility is to render pages, that's why it was called Razor View engine, not to have "business" logic inside.

[dsoronda]

@Rick-Anderson

No more passing data with messy ViewData. Use the build-it view model you get with PageModel.

Nobody uses ViewData. You have Model from MVC (that's what M stands for) and usually good practice is to have ViewModel folder that separates Razors ViewModels from business Models.

Razor pages give less fragmented code than MVC

Please. And you thing that this messy mix of Razor / HTML is less fragmented ??

BTW, MVC is not a standard.

For something that exists over 45 years, ref IT IS de facto standard.

[mikebrind]

@dsoronda razor pages != razor view engine.

There is no need to put logic in a razor page anymore than you would on an MVC view.

MVC is NOT a standard. It's one architectural pattern. There are other perfectly valid ones.

[tstivers1990]

The misconceptions in this thread are appalling. Please, if you're going to criticize something, at least understand what you're criticizing first.

[dsoronda]

I'll try to simplify my responses:
Question is:

Why choose MVC tutorials over Razor Pages

Why I chose MVC:

• There are over dozen of books that is out there covering ASP.NET MVC over years. How many books are covering Razor Pages?
• Video tutorials ?... Udemy, Pluralsight.....

My biggest issue is forcing Razor Pages over MVC as stated in:

We recommend you try the Razor Pages tutorial before the MVC/Controller/Views version. The Razor Pages tutorial:
Is the preferred approach for new application development.

Why is "preferred", if we have so many user posts here that says otherwise? So, why is MVC so bad suddenly?

[tstivers1990]

@dsoronda Nobody is saying MVC is bad. MVC is here to stay. The world isn't falling down. MVC is still a core part of ASP.NET, and will likely stay that way into the foreseeable future.

That said, have you actually tried Razor Pages? The argument that there are more books on MVC is irrelevant. Technology progresses. ASP.NET didn't start with MVC. It didn't even start as ASP.NET. If lack of books covering the technology was a valid reason to avoid the technology, technology wouldn't progress and we'd still be writing everything in assembly.

I have actually used both Razor Pages and MVC. I started with MVC. Then moved to Razor Pages. I've found that Razor Pages is far easier to work with than MVC. It makes the project structure much more clear. It makes it easier to follow good practices. It makes it easier to apply separation of concerns. And the MVVM pattern, which is what Razor Pages applies, is much better than MVC for the use case that Razor Pages was designed for. You're still going to use MVC for Web APIs and scenarios where it makes more sense. If you want to store images in a database and access them via a URL such as domain.tld/images/[imageId] then MVC is the right tool for the job. Use the right tool for the job. Razor Pages is just another tool in your arsenal, and is arguably a better tool than MVC in a lot of ways, regardless of the fact that MVC has been around longer or is more documented.

Would you argue with someone if they gave you a tool to add to your tool box? Then why the fuss about Razor Pages?

[JDGHHou]

The fuss, for me at least, is that Microsoft's documentation is inadequate.
Even in your two-paragraph post, you've done more than Microsoft to explain
a use case for one versus the other.

On Sat, Sep 8, 2018, 10:31 AM Anthony Stivers [e-mail]
wrote:

@dsoronda https://github.com/dsoronda Nobody is saying MVC is bad. MVC
is here to stay. The world isn't falling down. MVC is still a core part of
ASP.NET, and will likely stay that way into the foreseeable future.

That said, have you actually tried Razor Pages? The argument that there
are more books on MVC is irrelevant. Technology progresses. ASP.NET
didn't start with MVC. It didn't even start as ASP.NET. If lack of books
covering the technology was a valid reason to avoid the technology,
technology wouldn't progress and we'd still be writing everything in
assembly.

I have actually used both Razor Pages and MVC. I started with MVC. Then
moved to Razor Pages. I've found that Razor Pages is far easier to work
with than MVC. It makes the project structure much more clear. It makes it
easier to follow good practices. It makes it easier to apply separation of
concerns. And the MVVM pattern, which is what Razor Pages applies, is much
better than MVC for the use case that Razor Pages was designed for.
You're still going to use MVC for Web APIs and scenarios where it makes
more sense. If you want to store images in a database and access them via a
URL such as domain.tld/images/[imageId] then MVC is the right tool for
the job. Use the right tool for the job. Razor Pages is just another
tool in your arsenal, and is arguably a better tool than MVC in a lot of
ways, regardless of the fact that MVC has been around longer or is more
documented.

Would you argue with someone if they gave you a tool to add to your tool
box? Then why the fuss about Razor Pages?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-419651378, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOwWPwpRHcDWgEbSYks16A31Hv2lbnAXks5uY-LBgaJpZM4TtY4A
.

[tstivers1990]

@JDGHHou Sure, I can't argue there. The documentation is a bit lacking and could be clarified in a lot of areas. This is something that will get fixed over time.

[dsoronda]

This post seems to likely turn into turn flame war (Tabs vs spaces... MVC vs Razor Pages....etc), so this will be my last post here.

Here is my biggest concern and I'll quote it again.;:

My biggest issue is forcing Razor Pages over MVC as stated in Create a web app with ASP.NET Core MVC on Windows with Visual Studio

We recommend you try the Razor Pages tutorial before the MVC/Controller/Views version. The Razor Pages tutorial:
Is the preferred approach for new application development.

Why is "preferred" ??
Is this official Microsoft statement ? If not, why is that line there ? Let user chose what is better/preferred for him instead forcing someones opinion it text.

IMHO, this sounds like Microsoft is telling me to ditch MVC for Razor Pages (because, it's a "preferred" way) and I assure you I'm not the only one that thinks the same.

So, for now, I'll stay with MVC. Who knows, maybe in few months there will be "never" and "more preferred" way to do ASP.NET web apps ?

[JDGHHou]

Sure, but maybe they could hold off on the "Razor Pages is the preferred
method" stuff until they're truly ready to make the case.

On Sep 8, 2018 11:03 AM, "Dražen Šoronda" [e-mail] wrote:

This post seems to likely turn into turn flame war (Tabs vs spaces... MVC
vs Razor Pages....etc), so this will be my last post here.

Here is my biggest concern and I'll quote it again.;:

My biggest issue is forcing Razor Pages over MVC as stated in Create a web
app with ASP.NET Core MVC on Windows with Visual Studio
https://docs.microsoft.com/en-us/aspnet/core/tutorials/first-mvc-app/?view=aspnetcore-2.1

We recommend you try the Razor Pages tutorial before the
MVC/Controller/Views version. The Razor Pages tutorial:
Is the preferred approach for new application development.

Why is "preferred" ??
Is this official Microsoft statement ? If not, why is that line there ? Let
user chose what is better/preferred for him instead forcing someones
opinion it text.

IMHO, this sounds like Microsoft is telling me to ditch MVC for Razor Pages
(because, it's a "preferred" way) and I assure you I'm not the only one
that thinks the same.

So, for now, I'll stay with MVC. Who knows, maybe in few months there will
be "never" and "more preferred" way to do ASP.NET web apps ?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-419653816, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOwWPwZEoj-yhLZ5FiIwTOGkUhXO4FyDks5uY-psgaJpZM4TtY4A
.

[tstivers1990]

@dsoronda I think it is the more preferred way in that the majority of your website should be Razor Pages, and only MVC used where Razor Pages don't make sense (such as the examples in my above post). Yes, I think Microsoft is pushing for Razor Pages to be the default standard for a new project. I don't work for Microsoft, so I can't speak for them. But this seems to be their position from what I can see. And I agree with it. Like I said, Razor Pages is objectively a better tool in a lot of ways.

Programming comes with a lot of rules and best practices. Good programmers know when it's a good idea to break these rules or practices. Think of Microsoft's recommendations as just that, recommendations. Ultimately, they don't know what your project is. Only you know that. And only you can decide when it's a good idea to ignore those recommendations. In most use cases, though, it's best to follow those recommendations.

[mikebrind]

The fuss, for me at least, is that Microsoft's documentation is inadequate.

I agree with this. It is also very MVC-focused. There are 5 items in the Razor Pages section of the docs. Most of what you need to know in order to use the framework is buried in the extensive MVC area. I understand how this has come about, but it does nothing to support the notion that Razor Pages should be preferred, or even considered.

[Rick-Anderson]

Is this official Microsoft statement ? If not, why is that line there ? Let user chose what is better/preferred for him instead forcing someones opinion it text.

Yes, it is the official Microsoft ASP.NET team statement. We're not forcing RP, we're making a recommendation.

IMHO, this sounds like Microsoft is telling me to ditch MVC for Razor Pages (because, it's a "preferred" way) and I assure you I'm not the only one that thinks the same.

We've never said to ditch controllers and views for RP.

Who knows, maybe in few months there will be "never" and "more preferred" way to do ASP.NET web apps ?

In the next few months, no. ASP.NET MVC was introduced in 2007. Will there be a newer and better approach in 10 years? Possibly.

@mikebrind

but it does nothing to support the notion that Razor Pages should be preferred, or even considered.

See #7801

[mcrio]

Thank you MS team and the community for putting enormous efforts into open source and for providing us a great framework and all the different tools and guides. It’s still everyones own choice what technology and technique one’s going to use and pursue. Hats off to you and thanks a big time.

[Ruchir-zealous]

I just don't like Razor Pages. I am working with MVC since MVC 2.0. Razor Pages may be easier to use, but it's harder to understand. Things seem much simple in MVC. MVC is a clean and a standard. Razor page feels like ASP web form kind. I don't understand why they bring the code-view file concept back when MVC is widely adapted by developers.

[lmcdougald]

MVC template is laid out in such a way where it's clear how WebAPI controllers and view controllers are expected to coexist.

[richard-berg]

I'm going to follow the MVC tutorial because it is the very first link on the very first page users see when installing the latest version of Visual Studio, v15.8.4 as of this writing.

This is a highly curated list (only 4 entries total) -- incredibly valuable real estate. Surely the VS product managers would not steer beginners toward legacy technology?

[NikitaIT]

Razor Pages is MVVM, thanks to data binding it's convenient. I did not try, but I read the documentation.
1) I see in this approach a big plus - modularity. Now move the code to another project will be even easier.
2) I use about such grouping by folders

 \ About.cshtml
 \ AboutModel.cs
 \ AboutHandler.cs
 \ AboutMapper.cs
 \ About.js
InformationController.cs
InformationRouter.cs

And now I can get rid of the mixing of interactions in InformationController.cs

However, there are a number of things that are not yet clear to me.
1) I used to be able to share the controller between projects, replacing only the views. Apparently with RP this is not possible.
2) Obtaining resources and processing actions on the page require the creation of a Controller. Ie, get rid of the mixing of interactions will not succeed. That will lead to the need to support both MVC and MVVM, which I can not call a successful solution.
3) Pages are large, partial representations are often re-used, now they can not be reused with another .cshtml.cs.

Considering everything written, I think that in a big project it's better to forget about Razor Pages. Although most likely it is worth waiting for someone to try on this hat.

[Rick-Anderson]

@NikitaIT

Pages are large, partial representations are often re-used, now they can not be reused with another .cshtml.cs.

Subclass to reuse. This is covered in #7801

I used to be able to share the controller between projects, replacing only the views. Apparently with RP this is not possible.

Why not?

[dstewart101]

I'm not a particularly experienced developer, but after a loooooong time convincing my organisation to move away from webforms to a much more flexible approach with MVC, I now see that Microsoft are moving the goalposts once again. It feels like there is no real reason for this change other than for change's sake.
Something fresh/new to keep the features changing.
It's my opinion that "best practices" or "recommended approaches" are just too frequently revised to the point where it is hard to keep up! I think there is more transferable skills in MVC vs Pages so that's what I'll be sticking with.

[NikitaIT]

@Rick-Anderson

Subclass to reuse.

Of course, but Inheritance is not a flexible solution and requires more code changes, than when view is independent.

Why not?

I admit it was wrong, but I still like MVC more than RP)

[janissimsons]

Razor pages looks like a product that was done by a junior developer, who joined an experienced team working on MVC and thought to himself:

"Why don't we just merge the controllers and views?"

Then the junior dev merged them, made a commit and called it Razor pages.
If it hasn't already happened, then in the near future another junior dev will come along and ask:

"Why don't we just merge the Razor pages and models?"

.
There is a reason why we keep our controllers, views and models separate - simply put it is the separation of concerns, which keeps our apps modular and easier to extend.
Please don't kill MVC.

[mikebrind]

Razor pages looks like a product that was done by a junior developer, who joined an experienced team working on MVC and thought to himself:

"Why don't we just merge the controllers and views?"

Then the junior dev merged them, made a commit and called it Razor pages.

... except that the controller and View haven't been merged in Razor Pages. They are separate.

[janissimsons]

... except that the controller and View haven't been merged in Razor Pages. They are separate.

What do you mean? The whole idea behind RP is to get rid of controllers and have the RP handle the responsibility of views and controllers alike. Even the microsoft documentation states so:

..it handles requests directly, without going through a controller (source: https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio)

Anyway, I am not looking for a flame war, I am merely saying that RP looks like an anti-pattern, feel free to use it, if you want to, but I am sticking with traditional MVC.

[mikebrind]

What I mean is that a Razor Page is composed of a content page (analogous to an MVC view) and a PageModel class (analogous to a controller). The PageModel class is as testable as a controller. You can inject dependencies via its ctor etc.

..it handles requests directly, without going through a controller (source: https://docs.microsoft.com/en-us/aspnet/core/razor-pages/?view=aspnetcore-2.1&tabs=visual-studio)

Good point. That's not how I would have described it. I can see how that might make Razor Pages look like an anti-pattern.

[WhiteBookmark]

After trying out Razor pages, I decided to move on to MVC pattern. I will say that MVC is much better, easier and reliable compared to Razor pages. The code was just getting messier and clustered in RP but in MVC it is better organized.

[whut]

I like Razor Pages, but indeed all the advantages of it either are already preset or could be added to the MVC approach.

Quotes from current version of #7801:

• Leads to more maintainable code and a folder structure by default that's easier to navigate.

The same can be done in MVC, with feature folders, albeit it requires work to force MVC into this style:

• some additional code needed to be able to have views and controllers in the same folder
• yet more code is needed to have subfolders mapped to URLs automatically, like with this simple convention of Pages subfolder in Razor Pages.

I do not know how hard is to achieve the above in ASP.NET Core 2.1, as lat time I did that in ASP.NET MVC 5 in 2011 it required me to override paths to views and add some code for fully automatic registration of areas, so in the end simple adding new folder or subfolder in it (like with Pages in Razor Pages) with controller and view was enough to have it all working and served under expected URL. This feature I believe is the main selling point of Razor Pages:)

• Routing is easier.

Yes, it is a pain to configure routes for controllers in subfolders, areas are not good enough, attribute based routing also, but like said above this can be done in MVC. Only thing missing is that this should be provided by default by the framework.

More secure by default.

• AntiForgeryToken validation by default.

Such convention could be to MVC also. For example [WebController] attribute like the [ApiController] already introduced, which would enable AntiForgeryToken validation on every POST method.

More secure by default.

• You opt-in to the properties that need to be model bound via [BindProperty]. [BindProperty] prevents mass assignment/over-posting attacks.

The same is true for MVC, just use separate models for each action, like you do separate models for each page. Each controller should serve only single page. With "feature folders" it is natural to have each controller with only two actions, like GET and POST, and specific model for each controller. With subfolders, I would end up with folders like Widget/Create, Widget/Edit, Widget/Details, Widget/List, each with single controller, view and model.

More secure by default.

• The PageModel acts like a view model.

How does it influence security?

In closing, I do understand the value of Razor Pages, it is great both for simple cases and complex once. I believe it is good that Razor Pages exists, but it should not be suggested to be preferred approach. Why? Because learning MVC is still required, at least to expose REST APIs. From this perspective it looks bad to many devs that yet another framework is required to get benefits mentioned above.

Benefits of Razor Pages should be added to MVC, so that we will have freedom to choose Razor Pages if it is a server-side-pages-only app, but be able to unify on MVC approach in (IMO more common) case of mix of server-side APIs and either server-side pages or SPA.

[mikebrind]

@Rick-Anderson I would follow the MVC tutorials because the E-book that Microsoft has published on modern web applications' architecture doesn't even mention Razor Pages: https://docs.microsoft.com/en-us/dotnet/standard/modern-web-apps-azure-architecture/

[whut]

Just another idea: ASP.NET could have same routing convention like for the Razor Pages if the controllers are inside Pages folder, and apply then the AntiForgeryToken validation by default on POST (so no need for additional attribute)

[GocePetrovski]

Benefits of Razor Pages should be added to MVC, so that we will have freedom to choose Razor Pages if it is a server-side-pages-only app, but be able to unify on MVC approach in (IMO more common) case of mix of server-side APIs and either server-side pages or SPA.

I kind of agree with this statement a lot. My take is that Razor Pages should have been true extension of MVC. The way I see it a Page should have been special/custom type of controller that does extend Controller and adds lot of niceties, hocks, whatever.
If it is too difficult to extend MVC (controller) to do this, maybe Microsoft's implementation of MVC needs a bit of improvement.

The reality is that most, if not all modern websites do need API type of controllers in order to be more engaging and responsive (not to be confused with responsive as change layout based on browser size). And since we do need MVC controllers in the same project, why not continue with the same philosophy? Why have project that is part MVC and part MVVM? And don't even get me started on client side (JAvaScrip) patter used. Imagine you plug React (don't' know why, bus some do) on client side and now you have 3 different UI related design patterns in the same website. What happened to keep it simple???

[tstivers1990]

Just another idea: ASP.NET could have same routing convention like for the Razor Pages if the controllers are inside Pages folder, and apply then the AntiForgeryToken validation by default on POST (so no need for additional attribute)

The Pages folder is for Pages. What sense would it make to have Controllers inside of a folder called Pages? This would just lead to confusion for no real gain.

Benefits of Razor Pages should be added to MVC, so that we will have freedom to choose Razor Pages if it is a server-side-pages-only app, but be able to unify on MVC approach in (IMO more common) case of mix of server-side APIs and either server-side pages or SPA.

I kind of agree with this statement a lot. My take is that Razor Pages should have been true extension of MVC. The way I see it a Page should have been special/custom type of controller that does extend Controller and adds lot of niceties, hocks, whatever.
If it is too difficult to extend MVC (controller) to do this, maybe Microsoft's implementation of MVC needs a bit of improvement.

Pages are MVVM. That's one of the core features of Razor Pages. They use the MVVM pattern rather than the MVC pattern. Extending MVC to make it more MVVM-like is pointless when you consider this. At best, you'll get a half baked MVVM implementation. Improving an MVC implementation to make it more compatible with MVVM is an oxy-moron.

The reality is that most, if not all modern websites do need API type of controllers in order to be more engaging and responsive (not to be confused with responsive as change layout based on browser size). And since we do need MVC controllers in the same project, why not continue with the same philosophy? Why have project that is part MVC and part MVVM? And don't even get me started on client side (JAvaScrip) patter used. Imagine you plug React (don't' know why, bus some do) on client side and now you have 3 different UI related design patterns in the same website. What happened to keep it simple???

It's all about using the right tool for the job. I see nothing wrong with using two different UI design patterns within the same project. As long as your project structure is clear and consistent, where's the room for confusion? What are some actual, real world, tangible problems this causes? There's nothing needlessly complicated about this. In fact, I've found things to be much simpler with Razor Pages.

[racouster]

I have now actually used Razor pages and find it to be easier to use for quick setups. Thanks for adding it. Setting up view models is still a bit tricky when they are nested.

[JDGHHou]

racouster, can you shed some light on the issue with nested view models? I
ran into it on a single page app with multiple tabs. I wasn't able to
figure it out and, as usual, Microsoft's documentation was little help. I
still can't use a model on the main page and individual models on the view
components embedded in the tabs. Did you figure it out?

On Fri, Sep 21, 2018, 6:32 AM racouster [e-mail] wrote:

I have now actually used Razor pages and find it to be easier to use for
quick setups. Thanks for adding it. Setting up view models is still a bit
tricky when they are nested.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-423501597, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AOwWP9jukqEovTuHxsRCtFWK_ByiJjZ8ks5udM5ngaJpZM4TtY4A
.

[RogExp]

I have participated in many large projects, although those have mostly not been built with MS tools. However, the problem is usually being able to reuse code. You eg. build an application for desktop, but then suddenly you want to reuse some code in a web-service, in an application with a web-UI or in a mobile app.

Comparing RP and MVC, one should also look at it from the above point of view. Although I have very little experience of MVC and Razor Pages, my impression is that suddenly deciding to eg. completely change the user interface, would be easier having used a pure MVC pattern.

How does MVC or RP suit into the new Blazor techniques and how should you use MVC or RP being able to reuse as much code as possible in future projects.

I'm sure you can also cleverly separate the code in RP, but I think even the simplest tutorial should consider this aspect. Not having used RP very much, below my first impression comment to one of Rick's RP tutorials (Rick don't misunderstand me, I really appreciate your tutorials, seldom has MS done this kind of tutorials).

_I understand that a tutorial is built this way. However I would like you to consider putting another folder "Business" into this structure, ie. even the scaffolding should then make such a folder. You would then have Pages, Business and Models.
No page should have "using RazorPagesMovie.Models" but only "using RazorPagesMovie.Business" and hence the BusinessLayer would have Movie.Add, Movie.Remove and other Business logic.
As someone wants to change the UI, everyone is happy as the programmer has understood to separate the business logic from the page and it's also a security issue. What's your opinion about this?_

But the ultimate conclusion/question: Isn't MVC better prepared for separating code and making code reusable?

Regards Roger.

[Chandukunbi]

I have never worked with ASP.net Core before, but I prefer to start with a design (MVC) I'm familiar with to get to know the fundamentals of C# and ASP.net before plunging in Razer.

[myyandar]

I partly agree with Chandrakant, but the extreme end of it will take out all the work, and most likely, put mid-level coders out of some simple college-fees-paying jobs. However, if we can get the Identity Scaffolder to consider MVC Controllers, and enable scaffolding of View Models in addition to the existing scaffold for Model classes that have Id fields. The current scaffold works only with models with an Id property.

Yakubu Yandar Musah,
With my best compliments

---

From: lm28 [e-mail]
Sent: Tuesday, September 25, 2018 11:58:38 PM
To: aspnet/Docs
Cc: myyandar; Mention
Subject: Re: [aspnet/Docs] Why choose MVC tutorials over Razor Pages (#6146)

Have worked through the Razor page tutorial and I found the concept a lot easier to grasp than MVC.
Unfortunately though, when searching for help, there is almost nothing (outside of https://docs.microsoft.com/en-us/aspnet/core) that relates to Razor pages.

I feel that there are a few issues related to the scaffold process...but the problem lies with VS.
for example: you can only Scaffold one page at a time . . . and you cannot scaffold a page if there is a syntax error on a completely different script in the project.

As for my solution, I need to add the filter, paging and soring options to at least 70 percent of my tables. Making the manual changes manually for 150+ tables is not practical.
Consequently, I have scripted the entire process (via a Console app) which is specific to my database schema. It...

1. Generates CRUD pages for ALL tables in the schema.
2. the relevant CRUD page include 1:Sort, 2:Filter, 3:Pagination
3. The Model for each page is updated to reflect a DisplayName.

However, the 70 percent of tables that are in the schema serve as source options for SelectList (drop-down) boxes. But it seems that Razor doesn't have a solution for SelectList yet. It seems that I have no option, but to revert back to MVC.
As the end of the day....I think that while Razor has potential, it is still immature.
I made the mistake of choosing the 'easy' way. (MS Access and vb) and have not kept abreast of other technologies. Its now time for me to take the hard road. (Asp.Net Core MVC)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/aspnet/Docs/issues/6146#issuecomment-424540082, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ATM7vJnjeJZJnikwBaEAnDUtXMfzR4FDks5uesMugaJpZM4TtY4A.

[tomlindhe]

I really don't get it. Why this constantly change in methodology? I started with classic asp and have been following Microsofts unrational journey since then and wondering what the point is to change HOW things are done instead of doing it better. After feeling forced to move over to MVC, now I'm supposed to move back to the page-driven web-form alike approach again? After all big words and propaganda about MVC! There is nothing wrong with Razor Pages, I tried it out and for me it really feels like moving back in time. But it's hard to take Microsoft seriously now.. Please make up your mind!

[Ronkiro]

I really don't get it. Why this constantly change in methodology? I started with classic asp and have been following Microsofts unrational journey since then and wondering what the point is to change HOW things are done instead of doing it better. After feeling forced to move over to MVC, now I'm supposed to move back to the page-driven web-form alike approach again? After all big words and propaganda about MVC! There is nothing wrong with Razor Pages, I tried it out and for me it really feels like moving back in time. But it's hard to take Microsoft seriously now.. Please make up your mind!

Maybe Microsoft wants to keep things updated. I think the wrong thing here is, they do not need to change everything to keep it up to date, but to give tools to help if you need something, which would be the case of Razor Pages in my opinion Although, Razor Pages in being "announced" as main side of it for beginners, which it's totally wrong (At least it's what my vision offers). This disencourages beginners on this world (like me), which is very bad for either Microsoft or developers themselves.

[jovvybersamin]

I don't have any ASP.NET MVC 1-5 Background so I started learning the Razor Pages because it seems related to ASP.NET CORE MVC? (Not sure yet.). I haven't started reading the ASP.NET CORE MVC maybe after writing this comment.

The Razor Pages look cool though it feels like a WPF MVVM Approach, but what happens if you started adding a Javascript interaction with jQuery or VueJS (MPA), what will happen to the ModelBinding?

I do have PHP Laravel Framework experience though and I hope some of the toolings in Laravel will be available in ASP.NET CORE MVC in the future =D.

[dannevesdantas]

yep @jovvybersamin, Razor Pages is a brand new MVVM aproach proposed by the ASP.NET team, but it isn't largely adopted by the industry (yet). As you said you have Laravel experience I recommend you start learning ASP.NET Core MVC, that is 100% similar to Laravel and other well accepted and popular web frameworks like Spring, CodeIgniter and Zend Framework in an architectural point of view, so you will be familiar with ASP.NET Core MVC. The main differences is ASP.NET Core MVC uses Entity Framework Core ORM by default instead of the Eloquent ORM, and ASP.NET Identity instead of Stormpath, but both have (almost) the same features. Feel free to analyze both approaches and determine which fits better to you and your project.

[birdmod]

I am starting to work with Microsoft Web technologies and my last experience was with PHP/Symfony.
Between Razor which is specific to ASP and MVC which is known already present outside I chose to leverage on my experience. However once I will be at ease with MVC I will gladly try it.
Thanks to your good work and docs.

[rexbroo]

I started my first MVC Project with MVC for a variety of reasons and I've decided to stay with it, even though I am exploring Razor Pages, too.

[wutever0]

Because why the hell would we go back to the "new" Web Forms (aka Razor Pages)?!
Is there no consistency with your vision?!

[tstivers1990]

Because why the hell would we go back to the "new" Web Forms (aka Razor Pages)?!
Is there no consistency with your vision?!

In what way is web forms similar to razor pages?

[wutever0]

Because why the hell would we go back to the "new" Web Forms (aka Razor Pages)?!
Is there no consistency with your vision?!

In what way is web forms similar to razor pages?

There's a strong coupling between the view and the "controller" which is the code behind page. The whole point of MVC was to separate the two and that was supposed to be the "cleaner" solution. Now we are back to tieing them back together again.

[tstivers1990]

There's a strong coupling between the view and the "controller" which is the code behind page. The whole point of MVC was to separate the two and that was supposed to be the "cleaner" solution. Now we are back to tieing them back together again.

No there isn't. The razor view and the razor viewmodel are entirely separate entities. You can even move them to a completely separate folder if you wish.

[wutever0]

No there isn't. The razor view and the razor viewmodel are entirely separate entities. You can even move them to a completely separate folder if you wish.

Then I suppose it's the page-driven approach that makes it similar to web forms.

[tstivers1990]

Then I suppose it's the page-driven approach that makes it similar to web forms.

I suppose a Lamborghini is similar to a Toyota because both have combustion engines, then.

[wutever0]

I suppose a Lamborghini is similar to a Toyota because both have combustion engines, then.

I suppose so.

[rajesh-chawla]

My app will primarily be an API with a few admin pages. My thought is to go with MVC as it seems to map easier to api's.

[H35am]

Like others I'm far more familiar with MVC and I don't understand why the support(tutorial) for MVC has been removed. I like to know why would someone choose RP over MVC, what are the benefits? From separation of concern perspective is MVC far more better.

[dannevesdantas]

@H35am the MVC tutorials and docs are still available on the Tutorials and MVC sections at docs.microsoft.com.

[H35am]

@dannevesdantas thanks for pointing that out, I was referring to this link as you can see here the pages are removed and this is something I don't get.

[DRed96]

I am asked to maintain older systems for the company I work for. I will learn Razor in the future, but right now MVC is the most useful option.

[Erwandebenaze]

Hi !
I'm using MVC because my manager told me that we need different views for one action from Controller. And with Razor, it's one view for one action. So if we use Razor it will multiplicate the code !

[Ponant]

It seems that some past parts of the discussion are missing in this post. For instance, I remember @scottsauber giving an explanation on why he prefers RP for server-side html scenario, but I can't find it. It has been referenced here, too https://stackoverflow.com/questions/46777404/why-is-razor-pages-the-recommended-approach-to-create-a-web-ui-in-asp-net-core-2
Is anyone encountering the same issue?

[scottsauber]

@Ponant - It's buried in the "hidden items" now that this thread is so long. You can read that noob's comment here: https://github.com/aspnet/Docs/issues/6146#issuecomment-398599679 :smile:

For the record - up to well over 100 pages now on that app and my opinion on Razor Pages is still the same.

I was making some updates to a MVC5 app, and it struck me how much more boilerplate there is to MVC. [HttpGet], [HttpPost], [ValidateAntiForgeryToken], passing the ViewModel param in the method of the Post, Attribute Routes, new'ing up a ViewModel and passing it into like View(/* model goes here */), etc. Just stuff I never have to worry about with Razor Pages.

I'll probably write up a blog post on a comparison when I get some time.

@Erwandebenaze - You can still share views in Razor Pages with a Partial view.

[Ponant]

@scottsauber , ok! Unfortunately I wanted to have a look at how you managed with view models how you do binding as there seems to be different ways to do that in RP and my head is banging. I remember you showed up some links on how you setup view models and so on and I said to myself I will get back to that.

[Ponant]

@scottsauber , I remember that you where a fan of features folder, and I use it extensively too. Do you mind saying what you gain more from RP over Features folders? It seems that it relates to the antiforgery token and perhaps that it collapses the files, but other than that I have all files in the same folder(s). But there are other things which I am missing, what's your take on the difference?

[Rick-Anderson]

Do you mind saying what you gain more from RP over Features folders?

There are several listed in https://github.com/aspnet/Docs/pull/7801

[Ponant]

@Rick-Anderson , sorry I did not see a mention on RP vs Feature Folders in your link. My understanding is that you have one razor page for one action, because the page directive turns it into one and only one action. If that is correct, then the number of files will double with the number of actions. With a feature folder structure the number of files will be lesser or equal. Now you can say that the difference will lie in the View Model, but there have been several comments saying that you need to create View Models anyway with RP. This is why I ask the question to someone who is using it with 100+ pages.

[Ponant]

I just looked up @ardalis paper https://msdn.microsoft.com/en-us/magazine/mt842512.aspx and checked up his repo https://github.com/ardalis/OrganizingAspNetCore where you have traditional MVC, Feature folder and RP side by side. I don't see an advantage of using RP over feature folders when it comes to the number of files. Furthermore, I learned that the BindProperty attribute also works on controllers, so this reduces the differences to RP significantly in my eyes.
Unless someone argues differently, I find the inclusion of RP and traditional MVC in the docs rather confusing.

1) Identity is now entirely RP in the templates, which makes it a problem to work with identity server
https://github.com/IdentityServer/IdentityServer4/issues/2664
2) The docs have no clear distinction between the two approaches, starting with the security/identity part
3) I was interested in RP because people say it is more like MVVM and I had experience in uwp, but that argument seems weak, too.

Honestly it is confusing and the docs are a bit offset in terms of updates to the latest sdk.

[Rick-Anderson]

@Ponant - @scottsauber contributed to that PR and lists several advantages.

Did you read what @scottsauber wrote?

@Ponant - It's buried in the "hidden items" now that this thread is so long. You can read that noob's comment here: https://github.com/aspnet/Docs/issues/6146#issuecomment-398599679 :smile:

[Ponant]

@Rick-Anderson , yes I read the changes he submitted and also read the comments by others and I did not see a comparison to feature folders. I may be wrong but it seems that if you remove the "easier structure" argument, then I do not see an advantage of RP because feature folders offer this and there is a nice api by @odeToCode that allows you to have a Pages folder with a controller and view all in one and you can subfolders and areas. Regarding routing, I just don't see the advantage neither, attribute routing is very nice in MVC and practical, you can make it strongly typed by setting up a static file in a way similar to a sitemap. My argument 1 above remains a substantial one and I do not see it going away anytime soon because I just can't imagine how third parties will now switch to RP and Identity Server is a great example widely used. Recently, @blowdart mentioned in NDC that the team is working on having IS4 integrated in the template. While I think this is great, I am not sure if he is not struggling with the choice RP vs traditional MVC for that template to come. This is similar to what I am experiencing and to what others have said. In my previous projects I took the asp.net identity template and worked it out to fit my needs. As .Net Core experienced significant changes since 1.0 with the security API, I often had to take a look at the new templates to see how changes occurred (security is important!). My first question with RP was then: Is it really much better, much more powerful to justify a change? And it seems from this discussion that the answer is a no if you use feature folders.

[Ponant]

@Rick-Anderson , I think that, in short, if you want a fair comparison, then compare with feature folders and make feature folders as the default MVC template.

[rjean99]

I'm currently going through both tutorials so I can compare the results. My main concern is which approach will provide the most flexibility for customization and simple integration of 3rd party controls (ie. DevExpress, Bootstrap, etc.) not so much pure speed/ease of coding

[Rick-Anderson]

@Ponant

I don't see an advantage of using RP over feature folders when it comes to the number of files.

I've debated that with @ardalis in the past. RP can have more files, but that's OK. We're not saying RP has less files and that makes it better.

I am not sure if he is not struggling with the choice RP vs traditional MVC for that template to come.

I can assure you he's not.

I think you have two misconceptions:

• Files/Folder is the major advantage.
• RP is much different from MVC

Is it really much better, much more powerful to justify a change

It's trivial to go from one to the other. Almost all the APIs you use are identical. I think a much better question "Are the small differences between RP and MVC with controllers/views worth going to RP?".

To me the biggest advantages of RP over MVC with controllers and views:

• No bloated controllers. More focused/natural pages with RP. Makes it easier to update/maintain.
• Easier to go from RP Model to Razor file.
• No need to mock controller features you're not using.

When I ported Get started with ASP.NET Core MVC to RP I saw a minimal advantage. When I ported ASP.NET Core MVC with Entity Framework Core - Tutorial 1 of 10 to RP I realized a nice productivity boost. The EF/RP app is trivial compared to a real production app, but it's complicated enough to show the advantages.

Most of the dev's I've talked to who prefer RP to MVC with controlers/views had similar experiences. They were only convinced after developing with RPs.

[Ponant]

@Rick-Anderson , thanks for taking the time to answer.

1) What about the other points raised? They are to me the most important ones to my eyes to encourage people to use it, because everyone is interested in productivity boost and third party integrations. I understand that you can use RP and traditional MVC in the same project to support third parties but it makes you switch between concepts, taghelpers (asp-page vs asp-controller for instance, ignore the antiforgerytoken attribute in RP, etc), and that is a bit so so, especially if you go through the docs. For instance, the Security part with claims, policies etc uses traditionally controllers as of today
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-2.1

2) I knew that RP is based on MVC so I did not expect it to be much "different". I followed up the RP from the early on live.aspnet and supported the idea because of the "code behind" structure. I may have had one misconception over the two you mention, namely that the folder/fils structure is the biggest advantage, but quite sincerely this argument popped up throughout the standups and is there in the docs, at least implicitly. Perhaps the difference lies in English wording.

3) I was wondering a poll will not help you out to see real stats. A one-question poll that will ask the question:
-Do you prefer traditional MVC over RP and a checkbox "I already tried RP". That can be set up easily with Forms, I can do it if it helps.

[ProfBird]

I teach web development at a community college. My goal is to teach students concepts that are generally applicable regardless of what programming language or framework they end up using once they get a job. If I were to teach RP, then they would be learning an esoteric framework that shares little with other mainstream frameworks. By teaching ASP.NET Core MVC, they are learning concepts that will transfer to other MVC frameworks.

It is true that MVC is not a "standard" in the formal sense of the word, but most mainstream MVC frameworks have more similarities than differences and once you've learned one it's easy to learn another. In that sense MVC is a standard design pattern.

My time is valuable, I don't want to spend it learning a set of concepts and design patterns that only work with one framework. This year I'm using C# and ASP.NET Core MVC, next year I might need to be using Python and Django, or Ruby on Rails, or who knows, but at least I'll already have a good foundational set of concepts that I can transfer.

[OdeToCode]

You'll find the same concepts in RP that you find with ASP.NET MVC and other frameworks both server-side and client-side.

1) A separation of concerns - a page method builds a model to give to a view. The model knows nothing about the view. The view will focus only on presentation. This is the same separation of concerns the MVC side of the framework uses, but without the artificial separation of spreading all the files I need to work on a single logical page across three physical directories. I'm certain that the people in this thread who say RP doesn't maintain the same SoC as MVC haven't tried to develop with RP.

2) Separate deciding from doing - the page method doesn't write into the response stream, instead the page method returns a data structure that tells the framework what to do next. This practice makes unit testing easier, and also grants additional flexibility with action filters and page filters that can set up a pipeline design and take care of cross cutting concerns. The base abstraction for resulting is the same as the MVC side of the framework - IActionResult.

3) Dependency inversion principle - a page method should be programming to abstractions and not concrete details. The page constructor can advertise what dependencies are needed so the framework can inject the dependencies. This feature works the same as the MVC side of the framework.

Each of these three points includes the phrase "the same as the MVC side of the framework", and if I had the time, I could list many more example of where RP and MVC share the same patterns, and even the same abstractions. I'm also sure I could list 100s of fundamental webdev concepts you can teach with Razor pages that are more important than any framework - the POST-Redirect-GET pattern, preventing XSS, how cookies work, etc.

[ProfBird]

Thanks for your thoughtful response. Those are good points. I'll give
them consideration. However, there is one practical issue about what
framework to teach or to learn and that is what goes in a portfolio and
on a resume. Many potential employers won't recognize RP while they will
recognize MVC, so it could be harder for a newly graduated student to
sell themselves if they learned RP instead of MVC.

• Brian

Brian Bird
Faculty
Computer Information Technology
lanecc.edu/cit
Lane Community College
Building 19, Room 152
4000 E. 30th Ave., Eugene, OR 97405

Blog: Bird's Bits
LinkedIn: linkedin.com/in/brianabird

[Rick-Anderson]

@ProfBird

ASP.NET Core MVC, they are learning concepts that will transfer to other MVC frameworks.

ASP.NET Core MVC and RP share show much in common it's easy to learn and use them both in parallel. It's trivial to go from MVC to RP and vice-versa. It's much more difficult to go from ASP.NET Core MVC to Spring MVC.

It is true that MVC is not a "standard" in the formal sense of the word, but most mainstream MVC frameworks have more similarities than differences and once you've learned one it's easy to learn another.

Try the EF/MVC tutorial and the EF/RP tutorial, it's really trivial going from one to the other. Try going from ASP.NET Core MVC to Spring MVC, that's not so easy.

Many potential employers won't recognize RP while they will recognize MVC,

Learn them both - no employer will complain about that.

[tstivers1990]

Many potential employers won't recognize RP while they will recognize MVC,

Learn them both - no employer will complain about that.

Honestly, this. It took me very little time to become proficient with RP coming from ASP.NET Core MVC. I don't understand why the resistance to it seems so strong.

[sparkeh9]

I am using both RP and MVC. I don't see RP as a replacement for MVC, instead it is a supplement.
I wouldn't use RP for anything more complex than a contact form or something

[plamenkoyovchev]

Because I do not like Razor Pages.

[Miggleness]

I was looking for open source Razor tooling and fell into this hole. Just... wow.

[rexbroo]

I concur, learning and using both seems wisest.

On 11/7/2018 5:30 AM, Nick Briscoe wrote:
>

I am using both RP and MVC. I don't see RP as a replacement for MVC,
instead it is a supplement.
I wouldn't use RP for anything more complex than a contact form or
something

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-436622830,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AZC600HZjkTyUGrypRg20dJak1E4keTjks5usuCGgaJpZM4TtY4A.

--
Rex Brooks
Starbourne Communications Design
Email: [email protected]
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: [phone]

---

This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

[datvm]

From someone who hated Razor Page when reading the tutorial/overall architecture because it reminded me of the old Web Form time: Just try it on some projects, you will love it. Even if you don't like it, no matter, the same project can still be developed with your good-ol MVC. I even have a project that mixes both (MVC for API, Razor for UI), and I have to say Razor Page is so much better than MVC for UI only pages.

And as others have said, learning both is actually the wisest, and it does not take much time of you anyway.

[JAugustoGuimaraes]

Why push RazorPage over MVC instead add RazorPage as new Feature? What is wrong with MVC??

[ccit-spence]

In the 2.0 docs a long tutorial is listed for MVC. Razor Pages docs do not list an equivalent of that documentation. Documentation, Blogs, Tooling, Examples in the wild for MVC far exceed what exist for Razor Pages.

Soon the 2.2 documentation will become GA. Are we then still forced to go back to an MVC long tutorial in 2.0?

Razor Pages look promising, just not as mature of an ecosystem.

[Rick-Anderson]

@ccit-spence

In the 2.0 docs a long tutorial is listed for MVC. Razor Pages docs do not list an equivalent of that documentation.

What tutorial is that?

Documentation, Blogs, Tooling, Examples in the wild for MVC far exceed what exist for Razor Pages.

It's usually trivial to go from MVC tutorials to a RP version.

[ccit-spence]

This is the tutorial.
https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/?view=aspnetcore-2.0

RP does not translate 100% to MVC. I understand why. It does present a better workflow. The issues come in the subtle differences.

[Rick-Anderson]

There is a RP version of that tutorial, sans the last two stages. Having converted the MVC version to RP, I saw the advantages of RP. The conversion from MVC to RP was trivial.

[Ponant]

It is important to talk about the differences between MVC and RP, not the similarities!
And I am sorry to say that saying that learning both is the wisest is correct only under certain circumstances in your work or life, but it is certainly not something you should recommend to everyone.

There is one fundamental aspect that keeps being left unanswered on this thread and others and this is Authorization, Claims, Policies. At one time there was a workshop which allowed me to go through the fundamental understanding of Authorization in .Net Core and it was just perfect for a beginner in the field to greatly understand how to secure with a big S the http request flow. This workshop was by @blowdart , and I just realize now that it has been updated to .Net Core 2.1, great but you know what ?: It is the traditional MVC https://github.com/blowdart/AspNetAuthorizationWorkshop , also see dicussion going back to May 2018 https://github.com/aspnet/Docs/issues/6301.

So now you have the following confusion and please stop saying that the shift is trivial because this is inappropriate if you want to teach or diffuse knowledge and further more I disagree that this is as trivial when considering authorization because the security tests one must do need to be double checked:

0) You want to check out how Auth works in .Net Core, you head to perhaps the most important feature, Policies, https://docs.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-2.1 , with guidlines using MVC

1) You popup ASP.NET Identity from a template .Net Core 2.1 since there has been some major changes since 1.0, and you get a template with no access to the Identity code !

2) To access this code you start scaffolding, painfully and with still unresolved issues https://github.com/aspnet/Scaffolding/issues/839 , which means you need to go through the code and correct the scaffolding, such as substituting IdentityUser for ApplicationUser . Notice that you will most likely need to scaffold identity in 80%-90% of your projects, so this is extra work the dev needs to do while trying to keep focus. Once you scaffold you get RP based Identity.

3) Now you have the Authorization workshop with controllers and a scaffold identity with RP. OK, now you have to go through linking the two.

4) If you look for setting up an Auth flow with admin, restricted privileges, and read only users, for instance, you can head to here https://docs.microsoft.com/en-us/aspnet/core/security/authorization/secure-data?view=aspnetcore-2.1 . This step-through uses RP.
If you compare this with @blowdart 's Workshop with the tuto then you start seeing a difference because the former uses extensively code based policies because you need to go beyond the authorize attribute by requiring you to check explicitly for auth, such as
var isAuthorized = await AuthorizationService.AuthorizeAsync( User, Contact, ContactOperations.Create); if (!isAuthorized.Succeeded) { return new ChallengeResult(); }
whereas the latter is more elegant and above all more secure as less error prone as large parts use the [Authorize(Policy="blabla")] (you get rejected before entering the action) and then follow up with a scenario similar to above. It is not clear if you can continue to use the authorize attribute in this scenario for RP otherwise it would have been used in the tuto above or another.

5) Now you want to plugin IdentiyServer which has a template based on .Net Core 2.0, with controllers. OK so you need to port to RP, right? I am not sure they will.

To me the bottom line is that RP has been promoted too early, is imposed inappropriately with Identity (which furthermore is in a library), the docs are not ready, they mix both with links amazingly empty and I hope you will accept or at least understand that this is not "easy" or "trivial" to switch.

[molatO]

I chose MVC over Razor pages due to it's ability to integrate with angular

[ardalis]

In terms of API calls, or something else? Both MVC and Razor produce the
same HTML for their pages/views so I'm not sure what integration
you're referring to.

On Sun, Jan 20, 2019 at 12:08 PM Egbuta Kelechi [e-mail]
wrote:

I chose MVC over Razor pages due to it's ability to integrate with angular

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Docs/issues/6146#issuecomment-455883770, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAvvL71ptUkzKFujLrEN6EDgv8b73obuks5vFKKFgaJpZM4TtY4A
.

--
Steve Smith
http://ardalis.com | http://twitter.com/ardalis

[molatO]

I should have been a bit clearer in my reply. Here's what I imply. MVC is quite similar to WebAPI in it's implementation. The major difference being in their output i.e. html and json. As a result I believe the MVC tutorial plays well, when trying to understand the interaction between a WebAPI project and an angular project. In contrast to a Razorpages which as the name suggests are just pages with code-behind files as opposed to MVCs and WebAPIs with controllers. My explanation might come off as a bit bogus, but that's the best I could do.

In terms of API calls, or something else? Both MVC and Razor produce the same HTML for their pages/views so I'm not sure what integration you're referring to.
…
On Sun, Jan 20, 2019 at 12:08 PM Egbuta Kelechi @.*> wrote: I chose MVC over Razor pages due to it's ability to integrate with angular — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#6146 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvvL71ptUkzKFujLrEN6EDgv8b73obuks5vFKKFgaJpZM4TtY4A .
-- Steve Smith http://ardalis.com | http://twitter.com/ardalis

[Rick-Anderson]

@molatO that's not correct.
There's no difference in the ability of Razor VS MVC to work with angular.

[Ponant]

I am using RP since a few months now and really like its simplicity. However, there is a big caveat that is not mentioned except here https://github.com/aspnet/AspNetCore/issues/8065 and that is the inability to use strongly typed @page . I am hitting this issue as the project gets large. I did not see the strongly typed proposal by @scottsauber applicable. I hope this will be fixed at some point.

[arisliang]

How do we get ride of Razor pages completely, if we prefer MVC? There should be an option to not add something if we don't want to use it.

[dannevesdantas]

How do we get ride of Razor pages completely, if we prefer MVC? There should be an option to not add something if we don't want to use it.

It really looks like microsoft is trying to force the adoption of razor pages

[EntityAdam]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

[plamenkoyovchev]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

[dannevesdantas]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

Ok, maybe not "forcing", but at least strongly inducing I believe...

[arisliang]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

Ok, maybe not "forcing", but at least strongly inducing I believe...

So this is like, we give you the rights to vote (or choose), because we're democracy, but there's only 1 candidate available at this time. So..

[tstivers1990]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

Ok, maybe not "forcing", but at least strongly inducing I believe...

So this is like, we give you the rights to vote (or choose), because we're democracy, but there's only 1 candidate available at this time. So..

Not quite. More like you just got outvoted.

[arisliang]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

Ok, maybe not "forcing", but at least strongly inducing I believe...

So this is like, we give you the rights to vote (or choose), because we're democracy, but there's only 1 candidate available at this time. So..

Not quite. More like you just got outvoted.

And outchoosed as well

[tstivers1990]

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

Ok, maybe not "forcing", but at least strongly inducing I believe...

So this is like, we give you the rights to vote (or choose), because we're democracy, but there's only 1 candidate available at this time. So..

Not quite. More like you just got outvoted.

And outchoosed as well

Why do you hate progress so much?

[arisliang]

progress you say?

[EntityAdam]

So this is like, we give you the rights to vote (or choose), because we're democracy, but there's only 1 candidate available at this time. So..

Really? In no particular order 1. Razor Pages 2. MVC 3. Blazor 4. JS SPA++

Not quite. More like you just got outvoted.

And outchoosed as well

Your use cases may not be in line with all developers, and that's OK. You do have a voice if you so choose to use it. However, RP wasn't just created all willy nilly. Use cases were examined, telemetry collected on how ASP.NET was being used, and features that were being asked for, to name a few. (a) less magic (b) improved testability (c) improve ability to adhere to Single Responsibility Principle (d) better organization etc.

[arisliang]

So this is like, we give you the rights to vote (or choose), because we're democracy, but there's only 1 candidate available at this time. So..

Really? In no particular order 1. Razor Pages 2. MVC 3. Blazor 4. JS SPA++

Except no. 2 is not there.

No one is 'forcing' you to use it. Razor Pages and MVC share 80% of their code. Simply not opting to use it will not incur any perceived bloat.

No one is forcing us but there are no MVC templates :D

[EntityAdam]

MVC Docs -> Link

[arisliang]

Your use cases may not be in line with all developers, and that's OK. You do have a voice if you so choose to use it. However, RP wasn't just created all willy nilly. Use cases were examined, telemetry collected on how ASP.NET was being used, and features that were being asked for, to name a few. (a) less magic (b) improved testability (c) improve ability to adhere to Single Responsibility Principle (d) better organization etc.

(a) In default template, first thing it does is to be able to login without AccountController.Login code that MVC template used to have. How is this less magic?

MVC Docs -> Link

The function is there, but where is the template?

[EntityAdam]

(a) In default template, first thing it does is to be able to login without AccountController.Login code that MVC template used to have. How is this less magic?

The default template does not have authentication enabled. You would have to select that.

Because authentication is such a common use of ASP.NET Core, it's been abstracted into nuget packages and uses virtual controllers so your very own business logic isn't muddied with rolling your own, or modifying an authentication solution that has already been solved.

In RP, MVC and API, if you select authentication for 'individual accounts', It adds 'Identity' to your application, creates an Areas/Identity/Pages and wires in the below nuget packages. Which uses a virtual controller to handle the login / registration

Microsoft.AspNetCore.Identity;
Microsoft.AspNetCore.Identity.UI;

In RP, MVC and API, if you select 'Work or School Accounts" it adds Authentication and AzureAD.UI. You don't have to use these solutions. You may need another solution like SAML, or JWT, etc. These packages are the ones most used.

The function is there, but where is the template?

Each of the available ASP.NET Applications (RP, MVC, and API) each have one template that can all be configured with the same exact options to add authentication, require HTTPS and enable docker support. Each of which provide the same level playing field for starting to work on a new application.

[arisliang]

The default template does not have authentication enabled. You would have to select that.

I refer to the individual accounts.

Which uses a virtual controller to handle the login / registration

And virtual controller is the less magic part you were referring to?

[EntityAdam]

MVC and RP are equal in that specific case.
MVC has the virtual controller as well. And yes, it is less magic. Dont like the virtual controller? Remove the respective .UI package and make your own.

Less magic was more of a ref to the MVC convention of passing @ViewBag around. Where RP is strongly typed.

[arisliang]

Dont like the virtual controller? Remove the respective .UI package and make your own.

Where is the .UI package? And how do you remove it in order to remove the virtual controller?

[EntityAdam]

Sounds like a good question for stackoverflow, or find me on the aspnetcore slack.

[arisliang]

Actually what's the problem with an actual controller? What's the reason to introduce a virtual controller in the first place? It's exactly because authentication is such a common use case, and critical part of the application, its code should be more transparent, not more virtual, and hide away. This is opposite of less magic.

[arisliang]

Sounds like a good question for stackoverflow, or find me on the aspnetcore slack.

Thanks, but my real question is why it there in the first place? The actual controller works much better than the virtual one, more transparent, more certain of what is happening. Why introduce something to hide a critical portion of code?

[Rick-Anderson]

There is no virtual controller. An RCL is used for auth. See Scaffold Identity

[dannevesdantas]

Sorry guys, but if the objective is less magic, why an RCL, virtual controller or some other type of "magic" is used for auth? This seems to be contradictory. It's ok to promote razor pages, but removing MVC templates was a bad idea (in my opinion), the user should be able to choose if he/she wants rp or not. Ok, it is still possible to implement AccountController.cs but the idea of templates is to provide a quick start, and who wants only MVC (the majority of the .NET developers) now lost that ease :sob:

[EntityAdam]

The 'magic' you keep referring to as the RCL authorization package is applied to both MVC and RP. So RP is still less magic. The RCL isn't even relevant when discussing the reasons why RP was created.

Have you tried the templates? The choice you are asking for is already there. You don't have to pick RP. You can choose MVC, API, Blazor, React or Angular. You can choose whether or not they have Auth. If you don't like the way auth is implemented in the template, select no authentication and roll your own. If you want to use the RCL but want to customize it, you can do that to by taking it from the NuGet package.

[dannevesdantas]

select no authentication and roll your own

Yep, we are still able to roll our own authentication and AccountController, and that’s great. But who doesn't want RCL authorization (the majority of the .NET developers) and prefers the AccountController now lost the ease of having a auth template providing a quick start with it 😭 Implementing AccountController from scratch (and related code) by yourself takes a lot of time, even for experienced developers... I believe keeping both auth templates would make everyone happy.

[Rick-Anderson]

Implementing AccountController from scratch (and related code) by yourself takes a lot of time, even for experienced developers...

So why do it? Then you need to perform a security audit. You'll need to maintain the code. That's all done for you in the RCL.

Have you done any dev with Razor Pages? It's far easier to learn RP than it is to write your own auth.

[arisliang]

Why keep mentioning "easier"? Do you want to give it to developer or end user? Webform and drag and drop is eaiser, and it's gone.

[tstivers1990]

Why keep mentioning "easier"? Do you want to give it to developer or end user? Webform and drag and drop is eaiser, and it's gone.

Are you so unreasonable that you will argue against making things easier for developers?

[arisliang]

No, I only want to say don't make "easier" as the main selling point.

Remember the main reason aspnetcore is successful is because it conforms to
standard, from non-standard. Be skeptical when you want to leave standard
and go back to non-standard again.

On Mon, 29 Jul 2019, 08:59 Anthony Stivers, [e-mail]
wrote:

Why keep mentioning "easier"? Do you want to give it to developer or end
user? Webform and drag and drop is eaiser, and it's gone.

Are you so unreasonable that you will argue against making things easier
for developers?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore.Docs/issues/6146?email_source=notifications&email_token=AAIQK343B4AUVRPGAU3XFALQBY6G5A5CNFSM4E5VRYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD27KNSY#issuecomment-515811019,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIQK3YUFHZH7DGWNGZKFBTQBY6G5ANCNFSM4E5VRYAA
.

[Rick-Anderson]

Remember the main reason aspnetcore is successful is because it conforms to
standard,

What standard is that? It follows the MVVM (built on top of MVC) pattern, but MVC is not a standard.

Why keep mentioning "easier"?

OK, 10,000 times less complexity, risk, and time to use RP in an RCL than to create your own auth. That's a pretty compelling reason to make the trivial migration from MVC to RP.

Webform and drag and drop is eaiser, and it's gone.

Not true. Not for a real app. I remember stumping very good Web Forms dev's on a very small/simple app because state was kept for you.

[arisliang]

Don't interpret "standard" as some international body regulates something.
When 99% of the world doing something in a particular way, it's a de facto
standard.

On Mon, 29 Jul 2019, 09:20 Rick Anderson, [e-mail] wrote:

Remember the main reason aspnetcore is successful is because it conforms to
standard,

What standard is that? It follows the MVC pattern, but not a standard. RP
follows the same pattern.

Why keep mentioning "easier"?
OK, 10,000 times less complexity, risk, and time to use RP in an RCL than
to create your own auth. That's a pretty compelling reason to make the
trivial migration from MVC to RP.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore.Docs/issues/6146?email_source=notifications&email_token=AAIQK33O2PMZH7A47OSWAALQBZAWXA5CNFSM4E5VRYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD27K63A#issuecomment-515813228,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIQK34KHM6TDXEAY424BB3QBZAWXANCNFSM4E5VRYAA
.

[Rick-Anderson]

When 99% of the world doing something in a particular way,

Where do you get 99% use the MVC pattern?

Have you done any RP programming? It follows the MVVM pattern.

Going from Spring MVC to ASP.NET Core MVC is much more difficult than going from ASP.NET Core MVC to RP. Or any other non ASP.NET MVC framework for that matter.

[tstivers1990]

Some people would just prefer to write COBOL on their Commodore 64 I guess. 🤷‍♂️

[Rick-Anderson]

Take a look at what one experienced MVC developer has to say about RP vs MVC
Public review URL

[dannevesdantas]

Have you done any RP programming? It follows the same MVC pattern.

Take a look at what one experienced MVC developer has to say about RP vs MVC
Public review URL

I'm sorry for being boring and pushy @Rick-Anderson, but I read the document, and itself says "Razor Pages follows the MVVM pattern".

When 99% of the world doing something in a particular way,

Ok, it's a pattern, but the point is we must agree that it’s well-accepted by the industry. And ms knows what happens when we try to get out of the "standard" (IE and W8 sent us a hello from the cemetery 🧟). Like Blazor, RP is still an ideia, a proposal, a newborn project that may or may not gain popularity. Still believe keeping both authorization templates (RCL and also MVC) would be a good idea.

[tstivers1990]

I'm sorry for being boring and pushy @Rick-Anderson, but I read the document, and itself says "Razor Pages follows the MVVM pattern".

It's MVVM built on top of MVC.

[arisliang]

My suggestion, do whatever you want with RP (or mvvm, or whatever, as I'm
sure it's an interesting innovation), and leave MVC alone (including its
template).

Until RP is proven by user acceptance, then announce RP is the way to go.

On Mon, 29 Jul 2019, 11:07 Anthony Stivers, [e-mail]
wrote:

I'm sorry for being boring and pushy @Rick-Anderson
https://github.com/Rick-Anderson, but I read the document, and itself
says "Razor Pages follows the MVVM pattern".

It's MVVM built on top of MVC.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/AspNetCore.Docs/issues/6146?email_source=notifications&email_token=AAIQK36EXF4EQFWX2S3EONTQBZNFHA5CNFSM4E5VRYAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD27OULY#issuecomment-515828271,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIQK32CSRIAGDSSEYUEAA3QBZNFHANCNFSM4E5VRYAA
.

[AgentTheGreat]

I sense a lot of dogmatic expressions in this thread regarding how MVC is a "standard" and how WebForms was all bad.
When MVC first came out they actually forced a front end designer to view and write C# code, functions with overloads and all. There was a stark difference between HTML as a declarative language vs. the imperative nature of C# in what you had to see.
Microsoft basically learned from WebForms and the concept of controls to create Tag Helpers, etc. and make the presentation side of things easier for people involved in creation of the product.
WebForms tried to abstract away a lot of the internal workings of the web because it was an old technology. Now you got Razor Pages because many developers such as myself - having written APIs and controllers - still think of the front-end stuff in terms of pages, and Razor Pages provide a nice, balanced mix of comfort and compliance with what people call "de facto standards" of the modern web.
A lot of the objections sounds like nitpicky whining, honestly. People who are used to the way they've learned stuff and don't really want even attempts at more ease of use, at the cost of losing even a little bit of compliance with what the majority of developers are supposedly currently doing.

As for giving examples of defunct Microsoft technologies, I should point out that there was this left over hostility towards everything Microsoft that plays a huge role IMO. Want an example? Go check out how all the stuff that was considered Visual Basic's weaknesses are now considered Python's strengths. They call it an "intuitive language" now, where you don't have to define variables! You just assign a value to an identifier and voilà! Magic! I remember how everyone frowned upon VB back in the day and now you see "learn Python" everywhere, a language where you don't have to define variables but you can't be liberal with the way you indent the code.
So don't take the demise of some technologies necessarily as a sign of the failures of the product itself.

[tstivers1990]

Apparently people hate it when Microsoft innovates.

[arisliang]

I don't think anybody hates innovation in general. What some people against is to push innovation prematurely.

[AgentTheGreat]

I don't think anybody hates innovation in general. What some people against is to push innovation prematurely.

You gotta admit it's mostly just change that most people are against. I haven't seen a good argument how Razor Pages is "premature". It isn't. Clearly if you want HTML returned to the browser it works much more easily and intuitively compared to classic MVC.
To respond to "why do you keep saying 'easier'? Drag and drop in WebForms was 'easier' and it's gone" I should say being easy wasn't the part that made WebForms obsolete. It was all the other stuff Razor Pages got rid of. But the Page concept/abstraction works pretty well in general.
Easier can be a main selling point to developers. It is partly why the vast majority of people use .NET and Java for business applications instead of C++.

[arisliang]

I suggest you can say the same thing about being mature when its market share or people's acceptance reached similar level as MVC.

[ccit-spence]

The biggest problem with any innovation including Razor Pages in my mind is the abandonment of other technologies such as MVC. We have watched most of these Javascript frameworks become the new best thing only to start feeling the pains solved in older styles of programming.

Innovation is great, if it is truly innovative. A new way of doing something is not in and of itself innovative. Do Razor Pages solve every problem already solved by MVC. Did Razor Pages only solve a particular problem and now it is being pushed as a solution for everything. How long until it is on par? How easy it to find transitional documentation to solve something already solved within MVC? How many Nuget packages work with Razor Pages? What impact do Razor Pages have on security? My problem is I have more questions about Razor Pages than I have solutions to problems.

[AgentTheGreat]

What was the problem you wanted solved? When was MVC "abandoned"? MVC is _the_ solution to creating APIs and end points and Razor Pages never even suggested it is going to replace MVC. They keep saying it's MVC, with some goodies added on top so you get to have a more intuitive experience since MVVM has been the go to "standard" for UIs, and HTML is no different.

Are we really _that_ mad about the fact that we have a combination of a controller and a model? You get to clearly see your default routing system and you don't have to jump from controllers to views to models. That's it. That's the problem that is solved. Now you might not see that as a problem, but as I mentioned earlier there are those who don't see writing data access code with C++ a problem and make fun of the rest of us for losing performance with this modern crap. They want their power over pointers, and no amount of explaining how something like LINQ makes development easier is going to convince them.

[ccit-spence]

When was MVC "abandoned"? MVC is the solution to creating APIs and end points

Maybe some people use it for something other than APIs is my exact point.

you get to have a more intuitive experience since MVVM has been the go to "standard" for UIs

If you like MVVM. Being a "standard" is pretty opinionated considering it is being told to an MVC community

There have been many years of MVC for UI. Document the differences, don't just offer quick responses of its easier etc...

I have no problem with Razor Pages as a whole, as Blazor matures it becomes very compelling.

Maturity of an ecosystem is far more important to me than trying to figure out a new way to do the same thing.

[AgentTheGreat]

I don't "just" offer quick responses of it's easier. That's the whole difference. Other than that, as mentioned countless times before, there is no difference between Razor Pages and MVC because Razor Pages IS MVC with a twist. There is no theoretical problem with Razor Pages as opposed to WebForms; I've read this whole thread and I can't find anyone suggesting a valid criticism of Razor Pages, except saying "we're not there yet so don't want to hear it".

If you like MVVM. Being a "standard" is pretty opinionated considering it is being told to an MVC community

Yeah that's like if someone made a pitch to the WebForms community about MVC. You would have been talking to the WebForms community back then. Everywhere else, and in web frameworks like Angular you get a taste of MVVM. You've just been doing MVC a lot.

Maturity of an ecosystem is far more important to me than trying to figure out a new way to do the same thing.

Again, WebForms was pretty mature by that definition. You had to twist yourself to do the thing that was clearly simpler using MVC - like test or make simple HTTP calls and update views. Same argument goes for Razor Pages against MVC.

[tstivers1990]

I suggest you can say the same thing about being mature when its market share or people's acceptance reached similar level as MVC.

Popularity != maturity

[tstivers1990]

The biggest problem with any innovation including Razor Pages in my mind is the abandonment of other technologies such as MVC. We have watched most of these Javascript frameworks become the new best thing only to start feeling the pains solved in older styles of programming.

Please, stop making claims you cannot possibly back up. Razor Pages is built ON TOP of MVC. How do you suppose MVC is being abandoned? MVC is still the recommended pattern for Web APIs.

[tstivers1990]

Maturity of an ecosystem is far more important to me than trying to figure out a new way to do the same thing.

Well Razor Pages gets to benefit from the ecosystem already built around C#/.NET.

It's not the drastic change you're making it out to be. Case in point: Name a library you rely on that can't be used and doesn't exist for Razor Pages.

[arisliang]

Popularity != maturity

You seem to underestimate the importance of framework popularity. Besides, popularity is a strong indicator of maturity.

Angular

It's not fair comparison. Angular is up against a library jQuery, and solves a whole of problems that jQuery can't easily do. Being MVVM is a merely side product, not the reason it wins over. RP is up against a framework MVC, and solves nothing that MVC cannot easily do. Being MVVM alone doesn't help much.

[tstivers1990]

RP is up against a framework MVC, and solves nothing that MVC cannot easily do. Being MVVM alone doesn't help much.

While ASP.NET Core MVC is a framework, MVC itself is just a pattern, just like MVVM is just a pattern. There are clear benefits to using MVVM over MVC. I have personally found it much easier to work with, as someone who preferred MVC prior to Razor Pages' release.

I honestly don't understand why you're here whining. Microsoft has clarified that MVC isn't going anywhere. Razor Pages is built on top of MVC. You're effectively here advocating that a feature I and many other users like be abandoned, simply because you don't like it. If you don't like it, continue to use MVC. Nobody has a gun to your head.

[arisliang]

There are clear benefits to using MVVM over MVC

Not so clear to me.

I honestly don't understand why you're here whining

Because they crippled MVC template.

[tstivers1990]

Not so clear to me.

Well if you actually tried it instead of performing the fool's errand of fighting change, perhaps it would become clear.

Because they crippled MVC template.

In what way? As far as I'm aware, it still exists just the same as it did before.

[AgentTheGreat]

It's not fair comparison. Angular is up against a library jQuery, and solves a whole of problems that jQuery can't easily do.

Umm...yes, but I don't get how jQuery and Angular are compared here. It's like comparing LINQ with MVC. They have different responsibilities. Am I missing something here?

[arisliang]

In what way? As far as I'm aware, it still exists just the same as it did before.

They shutdown account controller in MVC template.

Well if you actually tried it instead of performing the fool's errand of fighting change, perhaps it would become clear.

Time is not free for people, especially for developer at these days. If there's no clear benefit, why spend time on it?

Somebody mentioned above RP solves a problem so that people

don't have to jump from controllers to views to models.

Is this the _clear_ benefit? Is this the _problem_ RP solves for MVC? There's no problem with MVC calling view and model.

[arisliang]

Umm...yes, but I don't get how jQuery and Angular are compared here. It's like comparing LINQ with MVC. They have different responsibilities. Am I missing here?

While somebody compare RP with C++ also, do you get that?

[EntityAdam]

This thread is again off topic.

Why choose MVC tutorials over Razor Pages.

I understand ya'll are in the middle of a heated debate, but please remember the objective is to get feedback that could help new users chose between RP and MVC, as well as give the veteran ASP.NET developers a good comparison.

[AgentTheGreat]

Umm...yes, but I don't get how jQuery and Angular are compared here. It's like comparing LINQ with MVC. They have different responsibilities. Am I missing here?

While somebody compare RP with C++ also, do you get that?

Makes me realize you didn't really get it. Comparison of RP was to MVC _the same way comparison of C++ was to .NET and Java, and not to RP._

Seriously?

[tstivers1990]

They shutdown account controller in MVC template.

And what's stopping you from making your own? The templates are just that, templates. Personally, I don't end up using any of the Identity templates by the time I'm done, because the code isn't what I consider production ready and lacks unit tests. Adapt and overcome.

Time is not free for people, especially for developer at these days. If there's no clear benefit, why spend time on it?

If you are unwilling to spend time learning new technologies, you will not get far in this field.

Is this the clear benefit? Is this the problem RP solves for MVC? There's no problem with MVC calling view and model.

I don't know what the text you quoted is really trying to say. But one clear benefit is you don't end up with bloated controllers. The current solution to bloated controllers is to basically make them do nothing themselves, instead putting all of the code in other classes. Hardly ideal. MVVM solves this problem. Razor Pages is also more in line with how the web actually works. But Razor Pages don't work in every scenario. There are times when you will still use MVC in your projects that are primarily Razor Pages. You will still have controllers for your REST API, if you have one. You will still use controllers for things that shouldn't actually generate a web page, such as if you're storing images in a database and want to be able to retrieve them via a route.

I don't know how I can drive this point home to you. But, _Razor Pages is just another tool in your arsenal._

[AgentTheGreat]

This thread is again off topic.

Why choose MVC tutorials over Razor Pages.

I understand ya'll are in the middle of a heated debate, but please remember the objective is to get feedback that could help new users chose between RP and MVC, as well as give the veteran ASP.NET developers a good comparison.

Yes you're right. My own take for any new users reading up to this point and trying to decide between Razor Pages and MVC:

If you are going to work with HTML and you feel comfortable with the concept of a "web page", choose Razor Pages. You won't be missing anything, and you can work easier with those pages. In the unlikely event that you think you are missing something in the middle of your work, you can add a Controller to your project MVC style. Nothing stops you from doing that.

On the other hand, if what you are creating is APIs for others to use, or do anything else web or network-based that has nothing to do with HTML, choose MVC because in that case choosing Razor Pages lands you in the same WebForms hell we painfully came out of years ago. It just doesn't make sense to use Razor Pages for a scenario where there is no "page" involved.

[arisliang]

If you are unwilling to spend time learning new technologies, you will not get far in this field.

There're many new technologies out there. RP is not the only one worth people's time. The problem is too many new things, too little time.

And what's stopping you from making your own?

Cost of time again.

I don't know how I can drive this point home to you. But, Razor Pages is just another tool in your arsenal.

The problem of these days is there're too many tools out there. All claim to be the next best thing, few delivers. For me, I'd stick to what's been proven by time. If a few years later, everybody doing MVVM or RP for backend, I'd join. But likely to be honest, after 2 years, MS will come out yet another best tool, and RP would fall out of favor. MS has this track of records in the web development world.

Comparison of RP was to MVC the same way comparison of C++ was to .NET and Java, and not to RP.

Angular to jQuery was the same comparison in the sense that they're all competitors, trying to gain the common ground. In the end, it's the tool solves real problem wins, not what pattern they use, be it MVC or MVVM, or whatever other patterns. It just happened that MVC pattern turned out to be suitable for backend, and MVVM for frontend.

[AgentTheGreat]

Angular to jQuery was the same comparison in the sense that they're all competitors, trying to gain the common ground. In the end, it's the tool solves real problem wins, not what pattern they use, be it MVC or MVVM, or whatever other patterns. It just happened that MVC pattern turned out to be suitable for backend, and MVVM for frontend.

I have never thought of jQuery as a competitor to Angular. One of them is "designed to simplify HTML DOM tree traversal and manipulation, as well as event handling, CSS animation, and Ajax."
The other one is "a TypeScript-based open-source web application framework".

So jQuery is mainly designed for you to select and manipulate DOM objects (the same way LINQ selects, filters and manipulates objects) and Angular is a framework, conceptualizing different parts of a web application, defining a paradigm (and corresponding tool set) to work with an application designed to run in a browser (the same way ASP.NET MVC does the same on the server side of things).

It would be a weird situation to choose between these two. You would clearly use both of them together. The same way you'd use LINQ in an MVC application.

[tstivers1990]

If you are unwilling to spend time learning new technologies, you will not get far in this field.

There're many new technologies out there. RP is not the only one worth people's time. The problem is too many new things, too little time.

And what's stopping you from making your own?

Cost of time again.

I don't seem to have this problem. You're over-exaggerating the learning curve of Razor Pages. You can pick it up in a day and be proficient enough with it if you are already proficient with MVC. Then you learn the rest as you encounter it. I suggest, for your own sake, you change your attitude towards the value of spending time learning new technologies. The time spent learning a new technology isn't exactly unpaid if you're doing it right. If the new technology helps you become more efficient or otherwise makes you more marketable in some way, there's a very clear potential for a return on that time invested.

I don't know how I can drive this point home to you. But, Razor Pages is just another tool in your arsenal.

The problem of these days is there're too many tools out there. All claim to be the next best thing, few delivers. For me, I'd stick to what's been proven by time. If a few years later, everybody doing MVVM or RP for backend, I'd join. But likely to be honest, after 2 years, MS will come out yet another best tool, and RP would fall out of favor. MS has this track of records.

The .NET ecosystem is not the JavaScript ecosystem. Microsoft isn't releasing some new thing and abandoning the old every 6 months. MVC has been around for how many years? Microsoft seems to be releasing a new technology every year or so lately. That's a pretty reasonable pace. Your claim that they just up and abandon old technology simply has no merit. Microsoft has a long standing track record of maintaining backwards compatibility and supporting products for a predictable amount of time. In the development world, they support their libraries and frameworks longer than just about any other company I can think of, even after the product has been marked as deprecated.

[arisliang]

I don't seem to have this problem. You're over-exaggerating the learning curve of Razor Pages. You can pick it up in a day and be proficient enough with it if you are already proficient with MVC. Then you learn the rest as you encounter it. I suggest, for your own sake, you change your attitude towards the value of spending time learning new technologies. The time spent learning a new technology isn't exactly unpaid if you're doing it right. If the new technology helps you become more efficient or otherwise makes you more marketable in some way, there's a very clear potential for a return on that time invested.

I don't suggest learning curve of RP, I suggest it'd be a waste of time if people had to learn new tools while the current tools works well. Well admittedly, it may well be appealing to some people. That's fine, like I said before, just leave the MVC alone, do whatever it takes to make RP popular and gain acceptance, win it in the long run, if you have so much confidence in it. Don't force it while it's still new, or sneak it in, like dropping account controller in MVC template (this make MVC RP _ish_, while some people may not want this development experience).

The .NET ecosystem is not the JavaScript ecosystem. Microsoft isn't releasing some new thing and abandoning the old every 6 months. MVC has been around for how many years? Microsoft seems to be releasing a new technology every year or so lately. That's a pretty reasonable pace. Your claim that they just up and abandon old technology simply has no merit. Microsoft has a long standing track record of maintaining backwards compatibility and supporting products for a predictable amount of time. In the development world, they support their libraries and frameworks longer than just about any other company I can think of, even after the product has been marked as deprecated.

When new things fall out of favor (most of them always do), it makes not much difference whether Microsoft _officially_ deprecate it or not. That's why for me, time-proven is important factor.

Will this approach miss out new toys at the beginning? Yes, but there're too many new toys coming out, you'd miss most of them anyway, so just give it some time, let most of them fade away. And spend time on what's left after the initial enthusiasm.

For backend, that's MVC so far. As long as MVC is left alone, I have no problem with RP to be innovative.

[EntityAdam]

We've already discussed this. You are incorrectly assuming the MVC template with identity areas contained within the code being moved to an RCL had anything to do with Razor Pages. If you want your old template back, start with a blank template and use the aspnet-codegenerator CLI to scaffold identity.

[tstivers1990]

@arisliang You aren't making a good case here. Honestly, I get the impression you just don't want to learn Razor Pages right now and would rather stick to MVC. That's fine. You can continue to do that. The removal of the templates aren't a great loss in my view. I didn't like them to begin with. They're meant to be used as a reference. I don't think they were ever intended to really be used as the final product in production. They're very rudimentary and could be designed much better. Any professional website is going to want to redesign them. So the templates are of limited value to begin with. Thus why Microsoft doesn't want to maintain two versions of them.

I don't like Areas. I think it's a feature that clutters my project hierarchy up. So I choose not to use them. This means the templates don't work for my needs either. I wasn't happy when they switched the templates over to Areas. So I made a project, scaffolded all the Identity files, and moved them all from Areas to Pages, along with redesigning the things I didn't like. And now I use that project as my starting point instead. The point is, you're not locked in. It's just a fact of life, not everything is going to be to your liking. But you have the power to make it to your liking, and it doesn't take that much time to create your own templates. If you really want to do something about it, you can create templates and put them on the Visual Studio marketplace. In fact, I wouldn't be surprised if there's already a good set of templates on the marketplace that you could use.

[arisliang]

They're meant to be used as a reference.

Yes, and reference is good to have. So that people know it's working as expected.

Thus why Microsoft doesn't want to maintain two versions of them.

Skill is the same thing as template in this sense. So Microsoft don't want to maintain two sets of templates, but asking user to maintain two sets of skills.

starting point

Yes, that's the template is about, starting point.

The MVC template now don't have the account controller. What impression does that give to user? What is MVC without the C? Is it still MVC? What magic does it do behind the scene that magically able to login without a login function? And that magic can't be stepped through in debugging.

Granted this can be worked around by creating own template. But that doesn't change the strange and confusing impression given by the default MVC template.

This weirdness seems to be pretty in line with RP's removal of controller.

[tstivers1990]

I'm out of time for this thread. Enjoy your fight against progress.

[arisliang]

1. It's not progress. Not proven anyway.
2. It's not a fight for me. It's an expression of opinion.
3. Bye.

[AgentTheGreat]

Yes, and reference is good to have. So that people know it's working as expected.

At this point you sound like a dude who got mad because in this version of Windows 10, you couldn't see Candy Crush Saga already pinned to Start.
You know what other reference is good to have? A complete e-commerce website sample you can leverage. If Microsoft had that, and then decided it wasn't worthwhile, you could make the exact same argument like "it's nice to have a sample sales template!"

Skill is the same thing as template in this sense. So Microsoft don't want to maintain two sets of templates, but asking user to maintain two sets of skills.

If you don't have the skill necessary to create an account controller then you need to go back to basics. Microsoft expects you to have that skill; they didn't owe you an accounts controller implementation.

The MVC template now don't have the account controller. What impression does that give to user? What is MVC without the C? Is it still MVC? What magic does it do behind the scene that magically able to login without a login function? And that magic can't be stepped through in debugging.

They didn't take away your ability to create a login function. They didn't take away the "C". Ability to create controllers is there. It was just the Candy Crush Saga tile that got removed by default.

This weirdness seems to be pretty in line with RP's removal of controller.

The fact that you have no experience in MVVM and think RP "had" a controller to be removed is honestly your problem. I rarely see someone who is so arrogant to practically state "MVC is so good that every paradigm HAS TO have a controller, if one doesn't that means it was REMOVED!"
And there is no weirdness.

P.S. I also think whatever valuable insight that could have been provided in this debate is provided. There is nothing more to be said that can give us anything new.

[ccit-spence]

Clarification from my point of view, I am not against Razor Pages in anyway. All I am saying is if something is documented (Official Docs) in MVC then Razor Pages should have the same example.

I have written MVC, Angular, React apps and get the reasoning behind the concept of Razor Pages. Just make sure the docs for Razor Pages have parity with the MVC examples.

Razor Pages introduce what seems to be some magic in relation to models etc.. Make sure it is clear. I know it is not really magic, but it may seem that way to others. At first glance you feel as if you are giving something up.

return Page() is a little different than building up a model and returning return View(model)

Keeping the files close together is a great idea.

[arisliang]

Candy Crush Saga, complete e-commerce website

A basic login temperature is not all these. You're taking it to the extreme. Microsoft has provided it since forever, why remove it?

they didn't owe you an accounts controller implementation

That's exactly the kind of mindset and danger that people needs to be aware of. They don't owe user anything. That's means people's invested time is not an important factor in their decision now or future on a particular new technology.

They didn't take away your ability to create a login function

It's not there by default, and it creates confusion by default. And in many occasions, it's not what you technically can or cannot do it, but the first impression it gives.

Maybe it's just me, I'd like a default _mvc_ template to work with a C. Here I refer template as a MVP. By removing the C in the template, it's no longer a MVP that demonstrate the c at work.

Maybe I hijected the discussion with the template, which is more specific to me. Other people may not have this issue. But many of them have concerns for their own reasons.

Actually since you mentioned windows 10, isn't windows 10 showing this similar type of mentality and problem now? They just set a deadline and push everybody ahead of it. I'm curious to see what happens on the day of windows 7 end support, where there are still 30-40% machines running it.

you have no experience in MVVM and think RP...

I have experience in mvvm, not so in RP. I wasn't interested in RP until I Google why MVC template has no login controller, and it leads me to this thread.

The more I read of this thread of what people's feedback on RP, the more sense it makes to me. Using mvvm has its challenge in the backend dominated by MVC pattern.

whatever valuable insight that could have been provided in this debate is provided.

Many valuable insights provided in early responses, but not addressed, so people left. I'm here at this RP vs MVC thread due to googling the issue I encountered with the MVC template.

Heated discussion as it is, is because a lot of these are highly opinionated. That's why the discussion? Because there're different views?

Of course Microsoft has the final say, I'll just leave it at that.

[AgentTheGreat]

Clarification from my point of view, I am not against Razor Pages in anyway. All I am saying is if something is documented (Official Docs) in MVC then Razor Pages should have the same example.

Agreed.

Razor Pages introduce what seems to be some magic in relation to models etc..

What part of it feels like magic?

return Page() is a little different than building up a model and returning return View(model)

The thing is, the page _is_ the model. Since a page consists of a view and a view model, saying return Page() means exactly what it means. If you are used to specifying "return this view and send this model with it" it may _feel_ like you've given up something, but you haven't. The concept of a page is complete on its own, so you just return a page that already has a model.

[ccit-spence]

I tried an experiment and converted a Controller to Razor Pages in an app I am working on. Fairly big with multiple Area/Controllers.

Converting was easy. Had to change up the models. Overall was easy. One thing I notice when navigating to Razor Pages, they flicker/flash and the Controller provided Views do not.

Is this normal?

[Rick-Anderson]

One thing I notice when navigating to Razor Pages, they flicker/flash and the Controller provided Views do not.

I've never heard of that from folks who converted. @ccit-spence Can you provide a sample on GitHub that reproduces the problem?

[EntityAdam]

Both RP and MVC are not SPAs (Single Page Applications). Both will 'flicker' as each page is a full HTTP request resulting in a new document. Your mileage on screen flicker will vary depending on rendering performance and http transport speed.

[ccit-spence]

@Rick-Anderson Unfortunately I can't share the source.
@EntityAdam Correct, Does this mean RP is a little slower?

Possibly has to do with the common Layout, I literally replaced only a Controller using the same Partials, View Components and Layout.

It is not a glaring difference, just a visible flash. The Controllers do not flash. This is on a local machine, real world the Controllers might flash as well.

[Rick-Anderson]

@ccit-spence I'm not asking you to share the source. I'm sure that would have too much irrelevant complexity. MVC with controllers and views using the same view engine as Razor Pages.

[EntityAdam]

No it does not necessarily mean RP is any slower. I would be very surprised if there was anything more than a nominal difference. It's all the same stuff under the hood, as MVC and RP share approx 80% of the code. In simple terms, I always expect screen flicker, however running local sometimes it is imperceptible. It is the nature of rendering server side. If you want no flicker, you'll require client side rendering.

[ccit-spence]

An update for the flash I was noticing, the flash only happens when going between Controllers and Pages. Pages to Pages no flash and Controller to Controller no flash.

Guessing some sort of transition in View rendering when going between Controller and Pages?

[datvm]

@ccit-spence View rendering is server-side (producing HTML code). There will always be flickering on client-side unless you are doing SPA.

A bit into very specific browser case: even if RP is slower than MVC, it should not be reason for flickering. At least in my browser, if I click a link, browser won't clear the current page but the loading icon should start animating, until it receives the HTML (which, server-side rendering of the View is finished already), only then will it clears the page and draws the new HTML page. In short, flickering should happen after server has already finished it job.

[sfatali]

Yeah, because of this kind of lame "design features" I shall never touch Razor Pages again! https://github.com/dotnet/aspnetcore/issues/8065

[yangzhongke]

Given that 'the separation of frontend and backend' is a popular development pattern, ASP.Net Core MVC has become unpopular, why we should go back to the old-styled coupling technology:Razor Pages?