Server Controls
A server control in ASP.NET Web Forms is any element in an .aspx page marked with runat="server", which tells the ASP.NET runtime to instantiate a corresponding .NET object on the server, track its state, and render it to HTML as part of the response. This is fundamentally different from plain HTML elements: a server control is a live object with properties, methods, and events you can manipulate in code-behind (e.g., MyLabel.Text = "Done"), whereas plain HTML is just static markup passed through untouched.
Cricket analogy: A server control is like a player registered on the official team sheet who the umpire and scorer actively track, versus a spectator in the crowd (plain HTML) who plays no tracked role in the match record.
Types of Server Controls
HTML server controls are ordinary HTML elements (like <input type="text" runat="server">) promoted to server-side objects, keeping the same tag names but gaining a server-side object model (System.Web.UI.HtmlControls). Web server controls, by contrast, use the asp: prefix (like <asp:TextBox>, <asp:DropDownList>, <asp:Calendar>) and belong to a richer, more abstract object model (System.Web.UI.WebControls) with consistent styling properties and built-in behaviors such as validation and automatic type conversion that don't map one-to-one to a single HTML tag.
Cricket analogy: HTML server controls are like a domestic league using largely the same rules as international cricket with minor tweaks, while Web server controls are like a fully redesigned franchise format (T20) built from scratch with its own distinct rulebook and conventions.
Data-bound and composite controls like GridView, Repeater, DataList, and ListView render collections of data by generating a set of child controls for each row at data-bind time, and they expose events like RowCommand, RowDataBound, or ItemDataBound to let you customize individual rows during rendering. Because these controls dynamically build their child control hierarchy from a data source, that hierarchy must be rebuilt via DataBind() on every postback for events (like a delete LinkButton inside a GridView row) to be wired up and fire correctly.
Cricket analogy: A GridView rendering rows from a data source is like a scorecard printing one line per over from the raw ball-by-ball data, and RowDataBound is like the scorer annotating a specific over with a special note, such as a hat-trick, as it's generated.
Control Events and the Control Tree
Server controls raise their events (Click, SelectedIndexChanged, TextChanged) through the postback mechanism: when a control triggers a postback, ASP.NET reads the __EVENTTARGET hidden field to identify which control caused it, walks the reconstructed control tree to find that control, and calls RaisePostBackEvent on it, which in turn fires the appropriate .NET event and invokes your handler. This only works reliably if the control tree at postback time matches the tree that was rendered, which is precisely why data-bound controls must be rebuilt with the same IDs and structure via DataBind() before event dispatch happens, typically in Page_Init or Page_Load, not after.
Cricket analogy: Dispatching a control event via __EVENTTARGET is like a video referee identifying exactly which fielder appealed from a replay tagged with a player number, then routing the decision review to that specific player's claim rather than a generic team appeal.
<asp:GridView ID="CustomersGrid" runat="server" AutoGenerateColumns="false"
OnRowCommand="CustomersGrid_RowCommand" DataKeyNames="CustomerId">
<Columns>
<asp:BoundField DataField="Name" HeaderText="Customer Name" />
<asp:TemplateField>
<ItemTemplate>
<asp:LinkButton ID="DeleteLink" runat="server" CommandName="Delete"
CommandArgument='<%# Eval("CustomerId") %>' Text="Delete" />
</ItemTemplate>
</asp:TemplateField>
</Columns>
</asp:GridView>
protected void Page_Load(object sender, EventArgs e)
{
if (!IsPostBack)
{
BindCustomers();
}
}
private void BindCustomers()
{
CustomersGrid.DataSource = CustomerRepository.GetAll();
CustomersGrid.DataBind();
}
protected void CustomersGrid_RowCommand(object sender, GridViewCommandEventArgs e)
{
if (e.CommandName == "Delete")
{
int customerId = Convert.ToInt32(e.CommandArgument);
CustomerRepository.Delete(customerId);
BindCustomers();
}
}
Because controls like GridView and Repeater rebuild a full child control hierarchy every time they bind, they can carry substantial ViewState overhead, since every generated LinkButton, Label, and BoundField's state gets serialized into __VIEWSTATE by default. For read-heavy grids that don't need per-row postback events, disabling ViewState on the control (or its columns) can meaningfully shrink page size.
- A server control is any element marked runat="server", instantiated as a live server-side object.
- HTML server controls keep familiar HTML tag names but gain a server-side object model.
- Web server controls use the asp: prefix and belong to a richer, more abstract control library.
- Data-bound controls like GridView and Repeater build a child control tree per row via DataBind().
- Events like RowCommand and RowDataBound let you customize behavior for individual data rows.
- Control events are routed via __EVENTTARGET, which requires the control tree to match what was rendered.
- Data-bound controls carry ViewState overhead proportional to their generated child controls.
Practice what you learned
1. What attribute turns an ordinary HTML element into a server control?
2. What prefix identifies a Web server control in markup?
3. Why must a GridView typically be re-bound with DataBind() on every postback where its events need to fire?
4. Which event lets you customize an individual GridView row as it is being generated?
5. What is a common performance downside of rich data-bound controls like GridView?
Was this page helpful?
You May Also Like
The Page Lifecycle
A walkthrough of the ASP.NET Web Forms page lifecycle — Init, Load, events, PreRender, and Unload — and why the order determines where your code belongs.
ViewState Explained
How ASP.NET Web Forms' ViewState mechanism preserves control state across postbacks, how it's serialized, and when to disable it for performance.
The Postback Model
How ASP.NET Web Forms simulates a stateful, event-driven experience over stateless HTTP through postbacks, __doPostBack, and cross-page posting.
What Is ASP.NET Web Forms?
An introduction to ASP.NET Web Forms, the event-driven, stateful web framework in the classic .NET Framework built around .aspx pages and code-behind classes.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics