Product Catalog with Razor Pages

Build a browsable product catalog with forms, validation, and a SQL-backed database using MVC.

MVCRazorModel Binding

Overview

A product catalog is where ASP.NET Core MVC's three pieces finally work together end to end: a Product model carrying validation rules as data annotations, a ProductsController handling requests and talking to the database, and Razor .cshtml views rendering HTML that a browser can actually submit a form to. The same [Required]/[Range] attributes you put on Product in Step 1 get used twice — once by EF Core, to decide column constraints in the database, and once by ASP.NET Core's model binder, to validate a submitted form before your controller code ever runs.

By the end of this tutorial you will have a ProductsController with Index, Create, and Edit actions, matching Razor views for each, and an EF Core CatalogDbContext backed by **SQLite** — a real, file-based SQL database (catalog.db), not an in-memory stand-in. That choice matters here specifically because this project is about persistence surviving past a single run: a visitor creates a product through an HTML form, and it needs to still be there the next time the app starts. A production deployment would swap the single UseSqlite(...) call in Step 2 for UseSqlServer(...) or UseNpgsql(...) against SQL Server or PostgreSQL — every controller and view below stays exactly the same.

What You'll Build

A Product model with [Required], [Range], and [StringLength] data annotations.
A CatalogDbContext backed by SQLite, with migrations applied automatically on startup.
A ProductsController with Index (list), Create (GET/POST), and Edit (GET/POST) actions.
Razor views using tag helpers (asp-for, asp-action) for model-bound forms and validation messages.
Server-side model binding and validation on every submitted form, backed by [ApiController]-free conventional MVC.
A redirect-after-POST pattern on every successful save, avoiding duplicate submissions on refresh.

Prerequisites

C# fundamentals — classes, properties, and async/await.
MVC basics — the idea of a controller action returning a View().
HTML forms — <form method="post">, input names, and how a browser packages submitted fields.
EF Core basics — DbContext, DbSet<T>, and SaveChangesAsync() (covered in the Task Manager Web API project).
Data annotations — attributes like [Required] and [Range] applied to a model's properties.

Project Structure

Running dotnet new mvc -o ProductCatalog scaffolds the conventional ASP.NET Core MVC layout: Program.cs at the root; Controllers/ holding ProductsController.cs; Models/ holding Product.cs; and — the piece a pure Web API project does not have — a Views/ folder, with one subfolder per controller. Every action method in ProductsController that calls the parameterless View() looks for a .cshtml file at Views/Products/{ActionName}.cshtml by convention, so Index() renders Views/Products/Index.cshtml, Create() renders Views/Products/Create.cshtml, and so on — no explicit file path is ever written in the controller code.

This tutorial also adds a Data/ folder for CatalogDbContext.cs, the same convention used in the Task Manager Web API project. Because this project uses a real SQLite file rather than an in-memory database, Program.cs also applies any pending EF Core migrations automatically on startup in Step 2, so catalog.db always matches the current shape of the Product model without a separate manual migration step during local development.

Step 1: Define the Product Model

Every attribute here does double duty. [Required] and [Range] are read by EF Core when it builds the database schema (a [Required] string becomes a NOT NULL column), and the exact same attributes are read again by ASP.NET Core's model binder on every POST to decide whether the submitted data is valid — one set of rules, enforced consistently in two different places. Price is declared as decimal, not double or float, which matters specifically for money: decimal avoids the small binary floating-point rounding errors that make double unsuitable for currency values.

Models/Product.cs

using System.ComponentModel.DataAnnotations;

namespace ProductCatalog.Models;

// Data annotations here are read twice: EF Core uses them to build column
// constraints in the database (Step 2), and ASP.NET Core's model binder uses
// the exact same attributes to validate a submitted form (Steps 4 and 5).
public class Product
{
    public int Id { get; set; }   // Primary key; EF Core recognizes "Id" by convention

    [Required(ErrorMessage = "Product name is required.")]
    [StringLength(100, MinimumLength = 2, ErrorMessage = "Name must be 2-100 characters.")]
    public string Name { get; set; } = string.Empty;

    [Required]
    [Range(0.01, 100000, ErrorMessage = "Price must be between 0.01 and 100,000.")]
    public decimal Price { get; set; }   // decimal, not double/float — the correct C# type for money, avoiding binary rounding error

    [Range(0, 10000, ErrorMessage = "Stock cannot be negative.")]
    public int StockQuantity { get; set; }

    [StringLength(500)]
    public string? Description { get; set; }   // Nullable: the one genuinely optional field on this model
}

Step 2: Configure the DbContext and Program.cs

AddControllersWithViews() is the MVC equivalent of the Web API project's AddControllers() — it registers everything AddControllers() does, plus Razor view rendering, so a controller action can call View() and have it actually resolve a .cshtml file. app.Database.Migrate() runs inside a DI scope created manually with CreateScope(), since AppDbContext/CatalogDbContext is registered as scoped (one instance per request) but startup code runs before any request exists — CreateScope() is what makes a scoped service resolvable from top-level code like this.

Data/CatalogDbContext.cs

using Microsoft.EntityFrameworkCore;
using ProductCatalog.Models;

namespace ProductCatalog.Data;

public class CatalogDbContext : DbContext
{
    public CatalogDbContext(DbContextOptions<CatalogDbContext> options) : base(options)
    {
    }

    public DbSet<Product> Products => Set<Product>();
}

Program.cs

using Microsoft.EntityFrameworkCore;
using ProductCatalog.Data;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();   // Adds Razor view rendering on top of what AddControllers() alone provides

// SQLite is a real, file-backed SQL database, not an in-memory stand-in — this
// catalog's data survives across restarts. A production deployment would point
// this same call at SQL Server or PostgreSQL instead, changing only the provider
// package and connection string, not any controller or view code below.
builder.Services.AddDbContext<CatalogDbContext>(options =>
    options.UseSqlite("Data Source=catalog.db"));

var app = builder.Build();

// Applies any pending EF Core migrations automatically on startup, so catalog.db
// always matches the current Product model. CreateScope() is required because
// CatalogDbContext is registered as scoped, but this code runs before any request exists.
using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService<CatalogDbContext>();
    db.Database.Migrate();
}

app.UseStaticFiles();   // Serves wwwroot/ (CSS and client-side validation scripts referenced by the views in Step 6)
app.UseRouting();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Products}/{action=Index}/{id?}");   // Products/Index becomes this app's default landing page

app.Run();

Before running the app for the first time, create the initial migration from the command line: dotnet ef migrations add InitialCreate (this requires the Microsoft.EntityFrameworkCore.Design and Microsoft.EntityFrameworkCore.Sqlite NuGet packages, plus the dotnet-ef global tool). db.Database.Migrate() in Program.cs then applies that migration to catalog.db automatically every time the app starts.

Step 3: Build the Index Action

The parameterless View(products) call is what makes the controller-to-view connection: it passes products as the view's strongly typed @model, and — because no view name is given explicitly — ASP.NET Core looks for Views/Products/Index.cshtml by convention, matching both the controller name (Products, from ProductsController) and the action name (Index).

Controllers/ProductsController.cs

using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using ProductCatalog.Data;
using ProductCatalog.Models;

namespace ProductCatalog.Controllers;

public class ProductsController : Controller   // "Controller", not "ControllerBase" — Controller adds View()/PartialView() support
{
    private readonly CatalogDbContext _db;   // Injected per-request by the DI container configured in Program.cs

    public ProductsController(CatalogDbContext db)
    {
        _db = db;
    }

    public async Task<IActionResult> Index()
    {
        var products = await _db.Products.OrderBy(p => p.Name).ToListAsync();
        return View(products);   // Renders Views/Products/Index.cshtml with products as its @model
    }
}

Step 4: Build the Create Action

This is the same GET-shows-a-form, POST-processes-it pattern used by the Contact Form Handler and Blog CMS PHP tutorials, expressed through ASP.NET Core's conventions instead: two methods share the name Create, distinguished by the [HttpPost] attribute on the second one. By the time Create(Product product) runs, model binding has already matched submitted form fields to Product's properties by name and validated every data annotation from Step 1 against the bound values — ModelState.IsValid is simply the yes/no answer to "did all of that validation pass?" [ValidateAntiForgeryToken] requires a hidden token the form tag helper in Step 6 embeds automatically, which is what stops a malicious site from submitting this form on a visitor's behalf (cross-site request forgery).

public IActionResult Create()
{
    return View();   // GET: renders Views/Products/Create.cshtml with a blank/default Product
}

[HttpPost]
[ValidateAntiForgeryToken]   // Requires the hidden token the form tag helper in Step 6 embeds, blocking cross-site request forgery
public async Task<IActionResult> Create(Product product)
{
    // Model binding already ran before this method started: ASP.NET Core matched submitted
    // form fields to Product's properties by name, then validated every [Required]/[Range]
    // attribute from Step 1 against the bound values.
    if (!ModelState.IsValid)
    {
        return View(product);   // Redisplay the form with the same values and validation messages attached
    }

    _db.Products.Add(product);
    await _db.SaveChangesAsync();
    return RedirectToAction(nameof(Index));   // Redirect-after-POST avoids a duplicate submission if the visitor refreshes the page
}

Step 5: Build the Edit Action

Edit(int id) follows the same overload pattern as Create, but its GET version first loads the existing product with FindAsync(id) so the form in Step 6 can pre-fill every field with the product's current values. The POST version checks id != product.Id before doing anything else — the route's id and the form's hidden Id field should always agree, and a mismatch here signals something is wrong with the request rather than a normal validation failure.

public async Task<IActionResult> Edit(int id)
{
    var product = await _db.Products.FindAsync(id);
    if (product is null)
    {
        return NotFound();
    }
    return View(product);   // Renders Views/Products/Edit.cshtml, pre-filled with the existing product's values
}

[HttpPost]
[ValidateAntiForgeryToken]
public async Task<IActionResult> Edit(int id, Product product)
{
    if (id != product.Id)   // The route id and the submitted hidden Id field must agree
    {
        return BadRequest();
    }
    if (!ModelState.IsValid)
    {
        return View(product);
    }

    _db.Update(product);              // Marks every property as modified, not just the ones that actually changed
    await _db.SaveChangesAsync();
    return RedirectToAction(nameof(Index));
}

Step 6: Build the Razor Views

Every view starts with @model declaring exactly what type the controller is expected to pass in — IEnumerable<Product> for the list, Product for the forms — which gives full IntelliSense and compile-time checking inside the .cshtml file itself. Tag helpers like asp-for="Name" and asp-validation-for="Name" read the same data annotations from Step 1 to generate the right <input> attributes and wire up client-side validation automatically, without a single line of validation logic being duplicated by hand in the view.

Views/Products/Index.cshtml

@model IEnumerable<ProductCatalog.Models.Product>

<h1>Product Catalog</h1>
<a asp-action="Create">+ New Product</a>

<table>
    <thead>
        <tr><th>Name</th><th>Price</th><th>Stock</th><th></th></tr>
    </thead>
    <tbody>
    @foreach (var product in Model)
    {
        <tr>
            <td>@product.Name</td>
            <td>@product.Price.ToString("C")</td>   <!-- "C" is a standard format string: renders as currency, e.g. $19.99 -->
            <td>@product.StockQuantity</td>
            <td><a asp-action="Edit" asp-route-id="@product.Id">Edit</a></td>
        </tr>
    }
    </tbody>
</table>

Views/Products/Create.cshtml

@model ProductCatalog.Models.Product

<h1>New Product</h1>

<form asp-action="Create" method="post">
    <div asp-validation-summary="ModelOnly"></div>   <!-- Lists any validation errors not tied to one specific field -->

    <label asp-for="Name"></label>
    <input asp-for="Name" />
    <span asp-validation-for="Name"></span>          <!-- Renders the [Required]/[StringLength] error message for Name, if any -->

    <label asp-for="Price"></label>
    <input asp-for="Price" />
    <span asp-validation-for="Price"></span>

    <label asp-for="StockQuantity"></label>
    <input asp-for="StockQuantity" />
    <span asp-validation-for="StockQuantity"></span>

    <label asp-for="Description"></label>
    <textarea asp-for="Description"></textarea>

    <button type="submit">Save</button>
</form>

Views/Products/Edit.cshtml

@model ProductCatalog.Models.Product

<h1>Edit Product</h1>

<form asp-action="Edit" method="post">
    <input type="hidden" asp-for="Id" />   <!-- Round-trips the product's id so the POST action can confirm it matches the route -->
    <div asp-validation-summary="ModelOnly"></div>

    <label asp-for="Name"></label>
    <input asp-for="Name" />
    <span asp-validation-for="Name"></span>

    <label asp-for="Price"></label>
    <input asp-for="Price" />
    <span asp-validation-for="Price"></span>

    <label asp-for="StockQuantity"></label>
    <input asp-for="StockQuantity" />
    <span asp-validation-for="StockQuantity"></span>

    <label asp-for="Description"></label>
    <textarea asp-for="Description"></textarea>

    <button type="submit">Save Changes</button>
</form>

Complete Code

Here is the full project across its files, ready to run with dotnet ef migrations add InitialCreate followed by dotnet run after installing the Microsoft.EntityFrameworkCore.Sqlite, Microsoft.EntityFrameworkCore.Design, and Microsoft.EntityFrameworkCore.Tools NuGet packages.

Models/Product.cs

using System.ComponentModel.DataAnnotations;

namespace ProductCatalog.Models;

public class Product
{
    public int Id { get; set; }

    [Required(ErrorMessage = "Product name is required.")]
    [StringLength(100, MinimumLength = 2, ErrorMessage = "Name must be 2-100 characters.")]
    public string Name { get; set; } = string.Empty;

    [Required]
    [Range(0.01, 100000, ErrorMessage = "Price must be between 0.01 and 100,000.")]
    public decimal Price { get; set; }

    [Range(0, 10000, ErrorMessage = "Stock cannot be negative.")]
    public int StockQuantity { get; set; }

    [StringLength(500)]
    public string? Description { get; set; }
}

Data/CatalogDbContext.cs

using Microsoft.EntityFrameworkCore;
using ProductCatalog.Models;

namespace ProductCatalog.Data;

public class CatalogDbContext : DbContext
{
    public CatalogDbContext(DbContextOptions<CatalogDbContext> options) : base(options)
    {
    }

    public DbSet<Product> Products => Set<Product>();
}

Program.cs

using Microsoft.EntityFrameworkCore;
using ProductCatalog.Data;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllersWithViews();

builder.Services.AddDbContext<CatalogDbContext>(options =>
    options.UseSqlite("Data Source=catalog.db"));

var app = builder.Build();

using (var scope = app.Services.CreateScope())
{
    var db = scope.ServiceProvider.GetRequiredService<CatalogDbContext>();
    db.Database.Migrate();
}

app.UseStaticFiles();
app.UseRouting();

app.MapControllerRoute(
    name: "default",
    pattern: "{controller=Products}/{action=Index}/{id?}");

app.Run();

Controllers/ProductsController.cs

using Microsoft.AspNetCore.Mvc;
using Microsoft.EntityFrameworkCore;
using ProductCatalog.Data;
using ProductCatalog.Models;

namespace ProductCatalog.Controllers;

public class ProductsController : Controller
{
    private readonly CatalogDbContext _db;

    public ProductsController(CatalogDbContext db)
    {
        _db = db;
    }

    public async Task<IActionResult> Index()
    {
        var products = await _db.Products.OrderBy(p => p.Name).ToListAsync();
        return View(products);
    }

    public IActionResult Create()
    {
        return View();
    }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Create(Product product)
    {
        if (!ModelState.IsValid)
        {
            return View(product);
        }

        _db.Products.Add(product);
        await _db.SaveChangesAsync();
        return RedirectToAction(nameof(Index));
    }

    public async Task<IActionResult> Edit(int id)
    {
        var product = await _db.Products.FindAsync(id);
        if (product is null)
        {
            return NotFound();
        }
        return View(product);
    }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public async Task<IActionResult> Edit(int id, Product product)
    {
        if (id != product.Id)
        {
            return BadRequest();
        }
        if (!ModelState.IsValid)
        {
            return View(product);
        }

        _db.Update(product);
        await _db.SaveChangesAsync();
        return RedirectToAction(nameof(Index));
    }
}

Sample Run

Click Run to see what this code prints.

Extend This Project

Add a Delete action (GET confirmation view + [HttpPost] DeleteConfirmed) following the same pattern as Edit, guarded by [ValidateAntiForgeryToken].
Add a Category model with a one-to-many relationship to Product, and a dropdown in the Create/Edit forms populated from _db.Categories.
Add server-side search and pagination to the Index action using .Where()/.Skip()/.Take() before ToListAsync().
Add image upload support for each product using IFormFile, saving files under wwwroot/images/ and storing the relative path on Product.
Add a custom [Remote] validation attribute that checks product name uniqueness against the database asynchronously as the visitor types.

Summary

You built a complete MVC application where a Product model's data annotations drive both the database schema and form validation, a ProductsController handles the full list/create/edit lifecycle with model binding turning submitted form fields straight into typed objects, and Razor views with tag helpers render forms and validation messages without hand-written HTML-generation logic. The GET-shows-a-form, POST-validates-and-saves pattern you wrote in Create and Edit is the backbone of nearly every data-entry screen you will build in ASP.NET Core MVC from here on.