Introduction to Razor Views in ASP.NET MVC

ASP.NET MVC remains a cornerstone of web development on the Microsoft stack, offering a clean separation of concerns and fine-grained control over HTTP responses. At the heart of its view engine lies Razor, a powerful templating syntax that lets you blend C# code with HTML seamlessly. Razor views (files with the .cshtml extension) are the standard way to generate dynamic HTML content in modern ASP.NET MVC applications. They enable you to transform data from controllers into rich, interactive web pages without writing cumbersome server-side controls or mixing business logic into presentation layers.

This expanded guide dives deeper into Razor views, covering syntax, advanced features like layouts and partials, model binding, validation integration, and performance best practices. Whether you are building a small intranet application or a large-scale public website, mastering Razor will help you deliver maintainable, performant, and SEO-friendly pages.

What Are Razor Views?

Razor views are server-side templates that combine HTML markup with embedded C# code. When a user requests a URL, the MVC pipeline routes the request to a controller action. That action typically returns a ViewResult by calling View(). The framework then locates the corresponding .cshtml file, executes the Razor code to produce an HTML string, and sends that string to the client’s browser.

The key benefit is that Razor compiles views into .NET classes at runtime or compile time (depending on the project configuration), allowing you to use the full power of the .NET runtime, including loops, conditionals, complex expressions, and even exception handling, directly inside your markup.

For example, a simple Razor view might look like this:

@{
    ViewBag.Title = "Home Page";
}

<h1>Welcome to @ViewBag.Title</h1>
<p>The current server time is @DateTime.Now.ToLongTimeString().</p>

Everything prefixed with @ signals a transition from HTML to C#. The @ character is the core of Razor syntax, and the engine is smart enough to infer where the C# code ends and HTML resumes, even across spaces, parentheses, or HTML tag boundaries.

Razor Syntax Deep Dive

To write effective Razor views, you must understand the various code block styles and expression modes available.

Inline Expressions

The simplest form is an inline expression, where a single @ followed by a C# expression outputs the result as text. For example:

<p>Your account balance is @balance.ToString("C2")</p>

If the expression returns an IHtmlString or implements IHtmlString, Razor will not HTML-encode the output. For all other types, Razor automatically HTML-encodes the value to prevent cross-site scripting (XSS) vulnerabilities.

Code Blocks

Use @ followed by a pair of curly braces to write multi-statement C# blocks:

@{
    var greeting = "Hello";
    var name = "World";
    var message = greeting + ", " + name + "!";
}
<p>@message</p>

Inside code blocks, you can declare variables, call methods, and perform logic. The HTML outside the braces is still rendered in sequence.

Control Structures

Razor supports standard C# control flow keywords like if, else if, else, for, foreach, while, and switch. Each must be prefixed with @ and followed by a code block or single statement. Best practice is to always use braces to avoid ambiguity:

@if (Model.IsAuthenticated)
{
    <span>Welcome back, @Model.UserName!</span>
}
else
{
    <a href="/Account/Login">Log in</a>
}

Similarly, loops integrate naturally:

<ul>
@foreach (var item in Model.Items)
{
    <li>@item.Name (@item.Price.ToString("C"))</li>
}
</ul>

Note that the @ is only required on the opening keyword. The closing brace is plain C# and Razor correctly resumes HTML when encountering the </li> tag.

Comments

Razor provides its own comment syntax that strips content from the rendered HTML entirely:

@* This is a Razor comment. It will not appear in the output. *@

HTML comments (<!-- ... -->) are still sent to the browser and are visible in the source. Use Razor comments for developer notes or to temporarily disable code blocks.

Special Characters

To display a literal @ symbol, use @@. For email addresses, Razor automatically recognizes them and does not require escaping. For example, [email protected] is treated as plain text.

Strongly-Typed Views and Model Binding

One of the most powerful patterns in ASP.NET MVC is using strongly-typed views. Instead of relying on ViewBag or ViewData, you declare the model type at the top of the view using the @model directive (lowercase ‘m’). This gives you compile-time checking and IntelliSense support for the model’s properties.

@model IEnumerable<Product>

<h2>Product List</h2>
<table class="table">
    <thead>
        <tr>
            <th>Name</th>
            <th>Price</th>
        </tr>
    </thead>
    <tbody>
    @foreach (var product in Model)
    {
        <tr>
            <td>@product.Name</td>
            <td>@product.Price.ToString("C")</td>
        </tr>
    }
    </tbody>
</table>

The controller passes the model via the View() method:

public ActionResult Products()
{
    var products = db.Products.ToList();
    return View(products);
}

Strongly-typed views also simplify form submissions with model binding. When a form is posted, the MVC framework automatically maps request data to properties of the model parameter in the controller action, provided the input names match the model’s property names.

ViewBag, ViewData, and TempData

While strongly-typed models are preferred, the framework also offers untyped containers for passing data between controllers and views:

  • ViewBag: A dynamic object that allows you to set arbitrary properties. It is a wrapper over ViewData. Example: ViewBag.Message = "Hello";. Access it in the view with @ViewBag.Message.
  • ViewData: A dictionary of key-value pairs (ViewDataDictionary). Access it as @ViewData["Key"]. Values must be cast to the appropriate type if you need strong typing.
  • TempData: Similar to ViewData but persists across a single redirect. It is stored in session and cleared after being read. Useful for displaying one-time messages like “Record saved successfully”.

Use these mechanisms sparingly. Overusing ViewBag can lead to runtime errors and makes views harder to maintain. Reserve them for rarely needed auxiliary data that does not fit into the main model.

Layouts and _ViewStart

Layouts give your application a consistent look and feel by defining a common master page. A layout is a .cshtml file that contains the outer structure of a page (header, navigation, footer) and a @RenderBody() call where the content of individual views is inserted.

For example, a typical _Layout.cshtml might look like:

<!DOCTYPE html>
<html>
<head>
    <title>@ViewBag.Title - My App</title>
    @Styles.Render("~/Content/css")
</head>
<body>
    <nav>...</nav>
    <main>
        @RenderBody()
    </main>
    <footer>...</footer>
    @Scripts.Render("~/bundles/js")
    @RenderSection("Scripts", required: false)
</body>
</html>

Individual views can specify which layout to use. By convention, the _ViewStart.cshtml file in the /Views folder sets the default layout for all views in that folder:

@{
    Layout = "~/Views/Shared/_Layout.cshtml";
}

You can override the layout in any specific view by reassigning the Layout property. This is especially useful for pages that need a completely different layout, such as login pages or error pages.

Partial Views and View Components

Partial views are reusable fragments of UI that can be embedded inside other views. They are especially useful for complex forms, list items, or any component that appears in multiple places. To create a partial view, simply create a .cshtml file conventionally named with a leading underscore (e.g., _ProductCard.cshtml).

You render a partial view from another view using Html.Partial or Html.RenderPartial:

@Html.Partial("_ProductCard", item)

The difference is that Html.Partial returns an HTML string, while Html.RenderPartial writes directly to the response stream (slightly faster for large partials, but cannot be used inside a code block).

For more complex, logic-heavy reusable components (like a shopping cart summary that requires database access), consider View Components. View Components are full-fledged classes with their own Invoke/InvokeAsync method, enabling injection of services and complex processing. They are the modern successor to child actions:

public class CartSummaryViewComponent : ViewComponent
{
    public async Task<IViewComponentResult> InvokeAsync()
    {
        var cart = await GetCartAsync();
        return View(cart);
    }
}

Invoke from a view with @await Component.InvokeAsync("CartSummary").

Sections and RenderSection

Sections let you define regions in a layout that individual views can fill. Common use cases include injecting page-specific scripts, stylesheets, or sidebar content. In the layout, declare a section with @RenderSection("SectionName", required: false). In a view, define the content:

@section Scripts {
    <script src="~/Scripts/page-specific.js"></script>
}

If a section is marked as required (required: true), every view that uses the layout must define it, or an exception will be thrown. Use required sections for items that are fundamental to the page, such as a title area or main content.

You can also check if a section has been defined in the view using IsSectionDefined("SectionName") inside the layout, which allows you to provide default content.

HTML Helpers vs Tag Helpers

Razor views offer two families of server-side tools for generating HTML: HTML Helpers and Tag Helpers.

  • HTML Helpers are methods called in the view, such as @Html.TextBoxFor(m => m.FirstName) or @Html.ActionLink("Home", "Index"). They return HTML strings and are familiar to developers who have worked with earlier versions of MVC.
  • Tag Helpers were introduced in ASP.NET Core but are also available in ASP.NET MVC 5.x via a NuGet package (Microsoft.AspNet.Mvc.TagHelpers). They allow you to write HTML-like tags that the server processes, e.g., <input asp-for="FirstName" />. Tag Helpers are more natural for front-end developers and enable richer Intellisense and validation integration.

For example, creating a form with Tag Helpers looks like:

<form asp-action="Submit" asp-controller="Home" method="post">
    <label asp-for="Email"></label>
    <input asp-for="Email" />
    <span asp-validation-for="Email"></span>
    <button type="submit">Submit</button>
</form>

Tag Helpers automatically bind to model properties, render validation attributes, and generate correct URLs. They are generally preferred for new development because they integrate seamlessly with unobtrusive validation and are easier to maintain.

Validation and Error Handling

Razor views work in concert with the validation system in ASP.NET MVC. You can display model-level and property-level validation errors using HTML Helpers or Tag Helpers. The ValidationSummary displays all errors at once, and ValidationMessageFor shows errors for a specific field.

@Html.ValidationSummary(true, "", new { @class = "text-danger" })
@Html.ValidationMessageFor(m => m.Email, "", new { @class = "text-danger" })

When you use Tag Helpers, the validation span is automatically added and populated during model binding if validation fails. This client-side validation markup is generated using data annotations on your model, such as [Required], [StringLength], and [Range].

To enable unobtrusive client-side validation, ensure that the necessary JavaScript libraries (jquery.validate.js and jquery.validate.unobtrusive.js) are included in your layout, usually in the Scripts section.

Razor with AJAX and Partial Rendering

Razor views are not limited to full page loads. You can use them to render partial HTML that is returned via AJAX and inserted into the DOM. Create a controller action that returns a partial view:

public ActionResult ProductDetails(int id)
{
    var product = db.Products.Find(id);
    if (product == null) return HttpNotFound();
    return PartialView("_ProductDetails", product);
}

On the client side, use jQuery or the built-in Ajax.ActionLink helper to load the partial result into a container:

@Ajax.ActionLink("View Details", "ProductDetails", new { id = item.Id },
    new AjaxOptions { UpdateTargetId = "detailsContainer" })

You must include the jquery.unobtrusive-ajax.js script for the Ajax.* helpers to work. Alternatively, you can write a plain jQuery $.get() call that updates the container manually. The benefit of using Razor partials for AJAX is that your server-side logic and markup remain consistent, avoiding duplication between full-page and partial responses.

Performance Considerations for Razor Views

Although Razor views are compiled, there are still performance pitfalls to avoid:

  • Avoid excessive logic in views. Keep views as simple as possible; move complex calculations, data transformations, and business rules to the controller, service layer, or view model.
  • Use caching judiciously. For views that rarely change (e.g., static navigation), consider applying output caching with the [OutputCache] attribute on the controller action. For partial views that are expensive to render, use Html.Partial with @Html.CachePartial (custom extension) or a caching framework like CacheCow.
  • Minimize the number of partial views rendered per page. Each Html.Partial call adds overhead. If a partial is used many times in a loop, consider building the HTML in the controller using a StringBuilder or a custom HTML generator.
  • Use async actions for I/O-bound operations. If your view depends on data that involves database queries or external API calls, define the controller action as async Task<ActionResult> and call await before passing the model. This frees up threads during I/O wait.
  • Precompile Razor views in production using RazorGenerator or the built-in RazorViewEngineOptions in ASP.NET MVC 5 (via MvcBuildViews set to true in project properties). This eliminates the first-request compilation delay.

Best Practices for Maintainable Razor Views

  • Always use strongly-typed models and avoid ViewBag for main data. This improves compile-time checking and readability.
  • Follow naming conventions: views should match controller action names, and partials should be prefixed with underscore.
  • Use display and editor templates for reusable data type displays. For example, create DisplayTemplates/DateTime.cshtml to format dates consistently.
  • Separate CSS and JavaScript from views. Put only minimal inline styles; use bundling and minification for external resources.
  • Write unit tests for controllers and view models. While views themselves are hard to test, ensure that the data passed to them is correct. Consider UI testing frameworks like Selenium or Playwright for integration-level validation.
  • Keep layouts focused. Do not put heavy logic or data retrieval in a layout. Layouts should only contain scaffolding HTML and calls to @RenderBody() and sections.

Conclusion

Razor views are the backbone of dynamic HTML generation in ASP.NET MVC. Their clean syntax, seamless integration with C#, and support for strong typing, layouts, partials, and validation make them a powerful tool for building maintainable web applications. By mastering advanced features like Tag Helpers, View Components, and AJAX partial rendering, you can create rich user experiences without sacrificing performance or code quality. As you continue developing with ASP.NET MVC, keep exploring the Razor view engine’s capabilities—it evolves with each version of the .NET framework, bringing even more productivity enhancements to your web development workflow.

For further reading, consult the official Microsoft documentation on Razor Syntax, Partial Views, and Tag Helpers in ASP.NET Core (which also apply to MVC 5 with suitable package references).