Introduction to ASP.Net Core Razor Pages

In the last chapter, Chapter 3, Introduction to ASP.Net Core MVC, we learned all about the MVC web development framework, our first dynamic framework to develop Web applications. We rebuilt the static HTML version of the Fred’s Cars website from chapter one, learned all about the Microsoft implementation of MVC, popular software patterns like dependency injection and the repository pattern, unit testing, and learned a lot about the C# programming language created specifically for .Net and .Net Core along the way.

We started with MVC because out of the three ASP.Net Core frameworks it has been around the longest and because the MVC software pattern lends itself well to web development and goes back to 1979 when it was developed by Trygve Reenskaug while working as a visiting scientist on the Smalltalk language team at Xerox PARC (Palo Alto Research Center).

As we now know MVC uses three components; Model, View, and Controller. These components can also be referred to as layers or tiers. And by breaking up the application into three layers, each layer of responsibility can be created, maintained, scaled, and tested in isolation freeing the developer from having to worry about other parts of the application while doing so.

About this chapter

In this chapter we are going to learn about the second dynamic web development framework included in the ASP.Net Core platform, Razor Pages, and rebuild Fred’s Cars using the framework. I like to think of Razor Pages as MVC light. As a matter of fact Razor Pages are built on the MVC engine under the hood but provide an easier framework to learn then MVC while still providing it’s advantages like dependency injection and testing. Microsoft recommends using Razor Pages going forward for the development of any new applications. If you are unsure of which ASP.NET Core web UI solution to use, see Choose an ASP.NET Core UI.

What does page-focused mean?

Microsoft describes Razor Pages in the following quote:

Razor Pages can make coding page-focused scenarios easier and more productive than using controllers and views.

I’ve always found this to be a vague and ambiguous definition. I mean what are “Page-focused” scenarios anyway?

“Page-focused” means the page itself is the unit of functionality.

In MVC we have a controller that handles many different actions and displays many views. MVC is built around controllers and views where the controller accesses a model in a third tier.

In Razor Pages we have a single page that knows how to display itself and process its own forms. Razor Pages are built around PageModels and Views. I think of the PageModel as a hybrid model/controller controlling the behavior of the page and defining the properties and modeling the page needs to function.

In MVC a controller structure might look like the following:

ProductsController

Index()      -> /Products
Details(id)  -> /Products/5
Create()     -> /Products
Edit(id)     -> /Products/5
Delete(id)   -> /Products/5

In Razor Pages every page has everything it needs to process and display itself including C# code and business logic as well as HTML and Razor expressions.

So a Razor Pages structure for Products might look like this:

Pages/
    Products/
        Index.cshtml
        Index.cshtml.cs

        Details.cshtml
        Details.cshtml.cs

        Create.cshtml
        Create.cshtml

        Edit.cshtml
        Edit.cshtml.cs

In the above structure we see that Razor Pages are stored in the Pages folder as opposed to MVC where controllers are typically stored in the Controllers folder and views are stored in the Views folder.

Also we see that each page contains a cshtml file containing HTML and Razor expressions and a cshtml.cs file which contains the C# code and business logic. This is the code-behind file.

Oh No! Not a code behind file. Is Microsoft going back to the pitfalls of webforms?

If you have experience with Web Forms from the original .Net Full Framework you might be thinking as I did with my first reaction to Razor Pages. The first time I read about webforms I thought, “What? A code behind? Is Microsoft crazy? We’ve already been down this road.

Web Forms was Microsoft’s first attempt at separation of concerns. It attempted to separate out the code and business logic from presentation and get away from the notorious spaghetti code of Classic ASP. And while there was great enthusiasm and acceptance of the framework we have already talked about all the pitfalls that eventually reared their ugly heads in Web Forms in Chapter 2, Module 3, What is ASP.Net?.

Let’s set the record straight. This is not a return to Web Forms. Although Razor Pages do in a way recapture the historical enthusiasm for Web Forms, Web Forms did not have the capacity and tools Microsoft has built up for ASP.Net Core and MVC like its baked in IOC container, dependency injection, and unit testing.

Where do Razor Pages shine?

Also keep in mind that MVC and Razor Pages as well as Blazor can all be used side by side in the same application.

I typically still use Controllers and Views for parts of the application that involve complexity but Razor Pages for supplemental areas of the application like:

• Login
• Register
• Change Password
• Contact Us
• Admin dashboard

Flexibility vs Focus

Let’s talk a little more about what the term “page-focused” means for Razor Pages.

MVC solves every problem the same way. A controller can select many actions. An action can render many views and views can render using partial views. This provides a great deal of flexibility for complex features. But not every feature needs this amount of flexibility. Some need the focus to be more on the feature itself. Razor Pages trade flexibility for focus. But you don’t have to choose just one framework. The two frameworks can co-exist. Use controller/views for more complex areas, Razor Pages for single features where you need to zone in.

I personally have always liked Razor Pages because the URLs reflect the folder structure by default but still give you power over routing. We will talk more about routing later in the chapter.

What’s Next

In the following modules we will rebuild the Fred’s Cars web application using Razor Pages.

Also, I mentioned in Chapter 3 that I don’t typically use the Visual Studio scaffolding tools to build applications because developers tend to treat the controllers, views, and Razor Pages the scaffolding creates as a black box preventing them from really learning the frameworks.

However, scaffolding can be a very powerful tool. We will start off by taking a quick look at how scaffolding works, then scrap that project and start from scratch in our usual way with an empty web template.