Understanding views

A Razor view is actually a template that is transformed into a class that inherits from RazorPage<T>. The generic parameter is actually the type of model, as we will see in a moment. This class inherits from RazorPage, which exposes a few useful properties, as follows:

• IsLayoutBeingRendered (bool): Whether a layout page is currently being rendered or not
• BodyContent (IHtmlContent): The resulting page's body contents; will only be available at a later time
• TempData (ITempDataDictionary): The temporary data dictionary
• ViewBag (dynamic): Access to the view bag, which holds arbitrary data prototyped as dynamic
• User (ClaimsPrincipal): The current user, as in HttpContext.User
• Output (TextWriter): The output writer, to which the HTML results are sent once the page is processed
• DiagnosticSource (DiagnosticSource): Allows the logging of diagnostic messages, covered here
• HtmlEncoder (HtmlEncoder): The HTML encoder used for encoding the results as they are sent in the response
• Layout (string): The current layout file
• ViewContext (ViewContext): The view context
• Path (string): The current view file path
• Context (HttpContext): The HTTP context

All of these properties can be used in a view.

We can, of course, define our own class that derives from RazorPage<T> and have our view use it, by using @inherits, like this:

public class MyPage : RazorPage<dynamic>
{
    public override Task ExecuteAsync()
    {
        return Task.CompletedTask;
    }
}

The only required method is ExecuteAsync, but you don't need to worry about that. If we now inherit from this class, we will see the following:

@inherits MyPage

Or, if we want the generated class to implement some interface, we can use the @implements keyword instead—like, for example, for IDisposable, as illustrated in the following code snippet:

@implements IDisposable

@public void Dispose()
{
    //do something
}

In this case, we must, of course, implement all interface members ourselves.