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 rseyf2017@gmail.com .

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 notifications@github.com 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

[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

public class AboutModel 
{
    public string Message { get; set; }
}

Views/About/Index.cshtml

@model AboutModel

@Model.Message

Razor Pages

Pages/About.cshtml.cs

public class AboutModel : PageModel
{
    public string Message { get; set; }

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

    public void OnPost()
    {
    }
}

Pages/About.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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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 notifications@github.com 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...