Q&A

Q&A: Developing Web Sites with ASP.NET Core Razor Pages

Microsoft says Razor Pages development in ASP.NET Core can make coding page-focused web-dev scenarios easier and more productive than using the controllers and views integral to another option: the Model View Controller (MVC) approach.

Specifically, company documentation states: "Razor Pages is a page-based model. UI and business logic concerns are kept separate, but within the page. Razor Pages is the recommended way to create new page-based or form-based apps for developers new to ASP.NET Core. Razor Pages provides an easier starting point than ASP.NET Core MVC."

ASP.NET Core Razor Pages
[Click on image for larger view.] ASP.NET Core Razor Pages (source: Microsoft).

To help .NET-centric developers get started building web projects with this approach, Microsoft MVP Philip Japikse is conducting an intermediate-level, full-stack development session during the big Live!360 tech conference being held in Orlando Nov. 13-18.

Attendees of the Nov. 15 presentation titled Websites with ASP.NET Core Razor Pages will dig into the details of View Components, Tag Helpers, Routing and much more in the session that runs from 9:15 a.m. to 10:30 a.m.

We caught up with the well-known international speaker to get more details on the session in a short Q&A.

VisualStudioMagazine: Can You Briefly Explain the Foundation of ASP.NET Core?
Japikse: ASP.NET Core is the next evolution for web development using the Microsoft stack. Based on .NET (Core), ASP.NET Core is a complete re-architecture and rewrite of the very popular ASP.NET framework. ASP.NET Core not only focuses on developer productivity, but also performance. With each release of ASP.NET Core, the benchmarks place the framework as one of the fastest available. With ASP.NET Core, you can develop RESTful services, web applications (using Razor Pages or the Model View Controller (MVC) pattern) and Single-Page Applications (SPA) using Blazor.

What Are Your Favorite New Features in ASP.NET Core Razor Pages?
For me, the reason I like Razor Pages is twofold. The first is the familiar Razor view engine. If you have worked in MVC applications before, many of the capabilities will be very natural to you: layout pages, templates (display and editor) and the advantage of being able to stay in the markup with Razor. The second is the speed to develop web applications.

"Since Razor Page-based applications are page focused and don't use the MVC pattern, each page can stand on its own. It creates a lower barrier to entry than its MVC counterpart, and I find it works great for smaller applications."

Philip Japikse, Microsoft MVP, ASPInsider, MCSD, PSM II, PSD and PST

Since Razor Page-based applications are page focused and don't use the MVC pattern, each page can stand on its own. The Get and Post methods plus routing parameters are in the code-behind file for the view. It creates a lower barrier to entry than its MVC counterpart, and I find it works great for smaller applications.

What New Features Would You Like to See in ASP.NET Core Razor Pages?
The one part of Razor Page-based web applications that blocks us from using them at scale in large applications is the friction required to achieve code reuse through inheritance. While you can technically create a base page and inherit from that in your Razor pages, there isn't the level of support and reuse that you get when developing an enterprise application using the MVC pattern.

Inside the Session

What: Websites with ASP.NET Core Razor Pages

When: Nov. 15, 9:15-10:30 pm.

Who: Philip Japikse, Microsoft MVP, ASPInsider, MCSD, PSM II, PSD and PST

Why: The Razor Page approach creates a lower barrier to entry than its MVC counterpart and works great for smaller applications.

Find out more about Live! 360, taking place Nov. 13-18 in Orlando

What Pain Points Do Developers Typically Encounter in Getting Started with ASP.NET Core Razor Pages?
If you have used ASP.NET MVC in the past, the Razor view engine will be very comfortable to you. I think the biggest difficulty will be getting back into a page-based routing system and getting used to code-behind files again. Code-behind files have a rather nasty legacy, and MVC developers will need to move past the history and embrace the new. A lot of care went into Razor pages to prevent the mistakes of the code-behind files in ASP.NET Web Forms.

If you are coming from a Web Forms background, the Razor view engine is quite different than the Web Forms view engine. While infinitely improved, it will take some getting used to. While there are some familiar patterns (like base layout pages and a page-based routing engine), moving from Web Forms to ASP.NET Core is probably a bigger leap than moving from ASP.NET MVC to Razor Page-based applications.

As Blazor Has Made a Big Splash by Allowing C# Web Development, what's the Role of ASP.NET Core Razor Pages Amid All the Blazor Hype?
It's not really a question of one over the other. They are very different and provide different mechanisms. ASP.NET Core web applications using Razor Pages or the MVC pattern use server-side code combined with the Razor view engine, HTML markup and client-side code (CSS/JS) to render a complete end-to-end application. There are some advantages with how authentication and authorization "just work," and there are capabilities that help defend against cross-site scripting attacks. Blazor WebAssembly (or Blazor Wasm), on the other hand, is a Single-Page Application (SPA) framework that runs entirely on the client (much like a JavaScript-based SPA).

A Blazor application will need a RESTful service to provide its data, authorization/authentication and so on. One reason that some developers really like Blazor is it significantly minimizes the JavaScript that you need to write, and instead allows you to write a great deal of the client-side logic in a language that you might be more comfortable with, like C#. There are of course trade-offs. For example, security is a very different paradigm than Razor Pages or MVC. You are now looking at using openID connect, OAuth or some other token-based system instead of ASP.NET Identity "out of the box." Note that this isn't any different than if you were using Angular to build your app, since the same issues regarding security exist. But for many C#/ASP.NET (Core) Developers, that would be a brand-new requirement to resolve. I'm not saying one is better than the other, but they are very different paradigms in a lot of the development and deployment details.

If you were to follow up your question with "which one is better," I would answer both Blazor and Razor Pages are very solid, even as new as Blazor WebAssembly is. The best part of the discussion is that now, as a Microsoft stack-based developer, you have many different choices of how to build your applications.

About the Author

David Ramel is an editor and writer at Converge 360.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube