Page 66 - MSDN Magazine, November 2017

Cutting EdgE DINO ESPOSITO Guidelines for ASP.NET MVC Core Views
Although ASP.NET Core might seem very similar to classic ASP.NET MVC on the surface, there are a lot of differences under the hood. Controllers, Razor views and even model classes can often be easily migrated with minimal effort, yet architecturally speaking, ASP.NET Core diverges significantly from previous non- Core versions of ASP.NET.
The main reason for this is the rewritten pipeline, which pro- vides an ASP.NET Core application at least two ways to generate an HTML-based response. As expected, an application can adopt the MVC programming model and generate HTML out of Razor views invoked via controller actions. Alternately, an application can act as a very thin Web server built around some terminating middleware, and your code in that terminating middleware can do everything, including returning a string that the browser treats as HTML. Finally, in ASP.NET Core 2.0 you can use an entirely new approach—Razor Pages. Razor Pages are Razor views that don’t need the MVC infra- structure, but can generate and serve HTML directly out of Razor files.
In this article, after a quick discussion on mini servers, termi- nating middleware and Razor Pages, I’ll contrast and compare the approaches you have within the MVC programming model to build views. In particular, I’ll focus on what’s new in ASP.NET Core, including tag helpers, view components and dependency injection (DI), and their impact on actual coding practices.
HTML from the Terminating Middleware
The terminating middleware is the final chunk of code in the
ASP.NET Core pipeline that gets to process a request. Basically, it’s
adirect(lambda)functionwhereyouprocesstheHTTPrequestto
produce any sort of detectable response, whether plain text, JSON,
XML, binary or HTML. Here's a sample Startup class for this purpose:
public class Startup
{ public void Configure(IApplicationBuilder app)
{
app.Run(async context =>
{
var html = BuildHtmlFromRequest(context); await context.Response.WriteAsync(html);
} });
}
By writing HTML-formatted text in the response’s output stream, and setting the appropriate MIME type, you can serve HTML content to the browser. It all happens in a very direct way, with no filters and no intermediation, but it definitely works and is faster than anything in earlier versions of ASP.NET. Terminating middleware gives you control over the flow sooner than any other
option. Clearly, coding an HTML factory right in the terminating middleware is far from being a maintainable and flexible solution, but it works.
Razor Pages
In ASP.NET Core 2.0, Razor Pages provide an additional way to serve HTML content, directly invoking a Razor template file with- out having to go through a controller and action. As long as the Razor page file is located in the Pages folder, and its relative path and name match the requested URL, the view engine will process the content and produce HTML.
What really differentiates Razor pages and Razor views is that a Razor page can be a single file—much like an ASPX page—that contains code and markup. A Razor Page is a CSHTML file flagged with an @page directive that can be bound to a view model that inherits from the system-provided PageModel class. As I men- tioned already, all Razor Pages go under the new Pages root project folder and routing follows a simple pattern. The URL is rooted in the Pages folder and the .cshtml extension is stripped off the actual file name. For more information on Razor Pages, have a look at bit.ly/2wpOdUE. In addition, for a more advanced example, have a look at msdn.com/magazine/mt842512.
If you’re used to working with MVC controllers, I expect you’ll find Razor Pages fundamentally pointless, perhaps only minimally helpful in those rare scenarios where you have a controller method that renders out a view without any business logic around. On the other hand, if you’re new to the MVC application model, Razor PagesprovideyetanotheroptionformasteringtheASP.NETCore framework. To some people, Razor Pages offer a lower barrier of entry for making progress with the framework.
Tag Helpers
The Razor syntax has always been essentially an HTML template interspersed with snippets of C# code. The @ symbol is used to tell the Razor parser where a transition occurs between HTML static content and a code snippet. Any text following the @ symbol is parsed according to the syntax rules of the C# language. The items discovered during text parsing are concatenated to form a dynamically built C# class that’s compiled on the fly using the .NET Compiler Platform (“Roslyn”). Executing the C# class just accu- mulates HTML text in the response stream, mixing together static content and dynamically computed content. In the end, the expres- sivity of the Razor language is limited to the expressivity of HTML5.
62 msdn magazine