ASP.NET

The three ASP.NET programming models: Web Forms, MVC and Web Pages

ASP.NET · By the Postback Notes editorial team · Published 2026-10-11

Classic ASP.NET on .NET Framework offered three ways to build a web application: Web Forms, MVC and Web Pages. They share the same runtime, configuration and hosting on IIS, but they organise code very differently. Knowing which model a project uses tells you where to look for things and what kind of changes are easy.

Diagram of three columns, Web Forms, MVC and Web Pages, standing on a shared layer labelled ASP.NET runtime on .NET Framework and IIS
Three programming models on one shared runtime.

Web Forms

Web Forms, the original model released in 2002, imitates desktop development. A page is an .aspx file containing server controls, with a code-behind class that handles their events:

<asp:TextBox ID="txtName" runat="server" />
<asp:Button ID="btnHello" runat="server" Text="Greet" OnClick="btnHello_Click" />
<asp:Label ID="lblHello" runat="server" />
protected void btnHello_Click(object sender, EventArgs e)
{
    lblHello.Text = "Hello, " + Server.HtmlEncode(txtName.Text);
}
Rendered example of a Web Forms page: a text box, a Greet button and the resulting greeting label, with the markup that produced it
A Web Forms page: controls in the markup, an event handler in the code-behind.

Behind this simplicity sit the postback (the page posts to itself), view state (a hidden field that remembers control values) and the page life cycle (Init, Load, control events, PreRender, Render). Server controls generate the HTML and JavaScript for you, and a rich ecosystem of grids, calendars and charts grew around them.

Strengths: very fast development of data-entry screens, drag-and-drop designers, event-driven code familiar to desktop developers. Weaknesses: limited control over generated HTML (much improved in .NET 4 with ClientIDMode and list rendering), large view state on complex pages, and code that is hard to unit-test because logic tends to sit in event handlers.

MVC

ASP.NET MVC (first released in 2009) separates the application into models, views and controllers. A URL is routed to a controller action, which prepares a model and chooses a view to render it:

public class GreetingController : Controller
{
    [HttpGet]
    public ActionResult Index() => View(new GreetingModel());

    [HttpPost]
    [ValidateAntiForgeryToken]
    public ActionResult Index(GreetingModel model)
    {
        if (ModelState.IsValid)
            model.Message = "Hello, " + model.Name;
        return View(model);
    }
}

public class GreetingModel
{
    [Required] public string Name { get; set; }
    public string Message { get; set; }
}
@model GreetingModel
@using (Html.BeginForm())
{
    @Html.AntiForgeryToken()
    @Html.LabelFor(m => m.Name) @Html.TextBoxFor(m => m.Name)
    <button type="submit">Greet</button>
}
<p>@Model.Message</p>

Razor encodes @Model.Message automatically. There is no view state and no postback life cycle: each request is handled by an action, and you write the HTML yourself.

Strengths: full control over markup and URLs, testable controllers, clear separation of concerns, natural fit for JavaScript-heavy front ends. Weaknesses: more code for simple forms, and a learning curve for developers used to controls and events. Handling several buttons in one form is shown in Multiple submit buttons in one MVC form.

Web Pages

ASP.NET Web Pages (2010), introduced with the WebMatrix tool, aimed at small sites and beginners. Each .cshtml file is a page that mixes Razor markup and code, with routing based on file names:

@{
    var name = Request.Form["name"];
    var message = IsPost && !name.IsEmpty() ? "Hello, " + name : "";
}
<form method="post">
    <input name="name" value="@name" />
    <button type="submit">Greet</button>
</form>
<p>@message</p>

Its single-file approach resembles PHP or classic ASP, with Razor's automatic encoding. Web Pages had a small footprint in enterprise projects and WebMatrix was discontinued; its idea lives on in ASP.NET Core Razor Pages.

Comparison

Comparison chart of Web Forms, MVC and Web Pages across state handling, HTML control, testability and typical project size
The three models compared on the criteria that usually decide a choice.
Web FormsMVCWeb Pages
Unit of codePage + code-behindController action + viewSingle .cshtml page
State between requestsView state, postbacksNone built in; model bindingNone built in
Control of HTMLIndirect, through controlsCompleteComplete
TestabilityLow without extra patternsHighLow
Typical useLine-of-business and intranet appsPublic sites, APIs, larger teamsSmall sites

The models can coexist in one application: an MVC area can be added to a Web Forms project, and many teams migrated that way, page by page.

Where they stand today

All three run only on .NET Framework, whose last version, 4.8.1, is supported as a component of Windows and still receives security fixes. Microsoft does not add features to Web Forms, MVC 5 or Web Pages any more. New development happens in ASP.NET Core, which runs on Windows, Linux and macOS and offers:

Web Forms itself was not ported to ASP.NET Core. Moving an application means rewriting its pages, typically to Razor Pages or Blazor, while reusing business and data-access code compiled for .NET Standard or modern .NET. The website vs web application article covers another choice you will meet in older Web Forms code.

How to tell which model a project uses

Official documentation