Data Binding in Web Forms

Analogy categoryAnalogies

What Is Data Binding?

Data binding in Web Forms is the mechanism that connects server controls like GridView, Repeater, DropDownList, and ListView to a data source such as a DataTable, a List<T>, or a data source control, and renders that data as HTML without you writing manual loops to build markup. Binding can be declarative, wiring a control's DataSourceID attribute to a SqlDataSource or ObjectDataSource on the page, or programmatic, where code-behind sets a control's DataSource property (for example gvProducts.DataSource = productList) and then explicitly calls DataBind() to trigger rendering. Nothing appears on the page until DataBind() runs, whether that call happens automatically inside a data source control or explicitly in your Page_Load handler.

🏏

Cricket analogy: A scoreboard operator doesn't invent numbers themselves, they wire the display to the live match feed so runs and wickets update automatically, just as a GridView doesn't build its own rows but binds to a DataSource and calls DataBind() to render them.

Data Source Controls

SqlDataSource and ObjectDataSource are declarative data source controls that let you configure select, insert, update, and delete commands entirely in markup, with a bound GridView or DetailsView automatically wiring paging, sorting, and editing to those commands with almost no code-behind. The alternative, programmatic binding, gives you full control: you write the query yourself in code-behind (typically via ADO.NET), assign the results to a control's DataSource property, and call DataBind(); this is more verbose but keeps SQL out of markup and is easier to unit test. Many real Web Forms codebases mix the two: SqlDataSource for simple CRUD grids, and manual binding for anything involving business logic, caching, or complex joins.

🏏

Cricket analogy: A franchise using an auto-auction algorithm to pick its squad versus a coach hand-selecting every player based on scouting reports mirrors the choice between letting SqlDataSource auto-generate CRUD commands versus a developer writing custom ADO.NET code in code-behind.

aspx-cs

<!-- Markup: GridView bound programmatically -->
<asp:GridView ID="gvProducts" runat="server" AutoGenerateColumns="False">
    <Columns>
        <asp:BoundField DataField="Name" HeaderText="Product" />
        <asp:BoundField DataField="Price" HeaderText="Price" DataFormatString="{0:C}" />
    </Columns>
</asp:GridView>

// Code-behind
protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        gvProducts.DataSource = ProductRepository.GetByCategory(categoryId);
        gvProducts.DataBind();
    }
}

Binding Expressions

Inside a templated control's markup, <%# Eval("FieldName") %> is a one-way, read-only binding expression that pulls a value out of the current data item for display; it is evaluated only when DataBind() runs, and it uses reflection internally, so it carries a small performance cost compared to strongly-typed code. <%# Bind("FieldName") %> looks similar but supports two-way binding: it is used inside EditItemTemplate or InsertItemTemplate so that when a user submits an edit, the control can read the new value back out of the input and pass it to the underlying data source's Update or Insert command. A common mistake is using Bind where only Eval is needed (adding overhead) or trying to use Eval inside an edit template and then wondering why edited values never save.

🏏

Cricket analogy: Reading the current score off the scoreboard is one-way, like Eval, but a scorer updating the board after every ball based on umpire signals is two-way, like Bind, where changes flow back into the official record.

Eval() is read-only and slightly slower due to reflection; use it for ItemTemplate display. Bind() is required inside EditItemTemplate/InsertItemTemplate for two-way data binding so edits flow back to the SqlDataSource's UpdateCommand or InsertCommand parameters.

Repeater, GridView, and ListView Differences

Repeater is the lightest-weight templated control: it renders exactly the HTML you define in its templates with no default styling and no built-in paging or sorting, making it ideal when you need full markup control, such as building a custom card layout. GridView renders an HTML table by default, has rich built-in support for automatic paging, sorting, and inline editing with minimal code, but is harder to restyle away from a tabular layout. ListView sits between the two: it is fully templated like Repeater (no forced table markup) but can be paired with a DataPager control to get GridView-style paging, making it the most flexible choice when you need both custom markup and paging.

🏏

Cricket analogy: Choosing a fully customizable practice net setup (Repeater, build exactly what you want) versus a standard stadium scoreboard with built-in features (GridView, paging/sorting included) versus a modular indoor facility you can reconfigure and still track stats in (ListView, both flexible and pageable).

Rebinding a data control (calling DataBind() again) on every postback without checking !IsPostBack will overwrite any in-progress edits or selections and can also silently break features like sorting and paging that rely on ViewState. Wrap your initial DataBind() call in an if (!IsPostBack) block in Page_Load.

Data binding connects server controls (GridView, Repeater, ListView, DropDownList) to a data source and renders markup automatically when DataBind() runs.
SqlDataSource/ObjectDataSource offer declarative, low-code binding; manual code-behind binding offers full control and keeps SQL out of markup.
Eval() is one-way, read-only, and reflection-based; Bind() is two-way and required in edit/insert templates for changes to persist.
Repeater gives full markup control with no built-in paging; GridView gives table markup with built-in paging/sorting; ListView combines custom templates with optional DataPager-based paging.
DataBind() must be explicitly called (or triggered by a data source control) before any bound data appears.
Always guard initial DataBind() calls with if (!IsPostBack) to avoid wiping out user edits or state on every postback.

Practice what you learned

1. What must be called before data assigned to a control's DataSource property actually renders on the page?

2. Which binding expression is required inside an EditItemTemplate for a value to be saved back to the data source?

3. Which control offers the most markup flexibility while still supporting built-in paging via a DataPager?

4. Why should the initial DataBind() call in Page_Load typically be wrapped in if (!IsPostBack)?

5. What is a performance consideration with using Eval() heavily inside a large GridView?

Was this page helpful?

ADO.NET Basics

Working with SQL in Web Forms

Related Study Notes in Microsoft Technologies

Browse all study notes

Microsoft Technologies

Windows 10 / UWP Development Study Notes

.NET · 30 topics

Microsoft Technologies

Windows Batch Scripting Study Notes

Batch · 30 topics

Microsoft Technologies

MFC (Microsoft Foundation Classes) Study Notes

C++ · 30 topics

Microsoft Technologies

Silverlight Study Notes

.NET · 30 topics

Microsoft Technologies

XAML Study Notes

.NET · 30 topics

Microsoft Technologies

WPF (Windows Presentation Foundation) Study Notes

.NET · 30 topics

Topics covered

#NETFramework#ClassicASPNETWebFormsWebPagesStudyNotes#MicrosoftTechnologies#DataBindingInWebForms#Data#Binding#Web#Forms#WebDevelopment#StudyNotes#SkillVeris

What Is Data Binding?

Data Source Controls

Binding Expressions

Repeater, GridView, and ListView Differences

Practice what you learned

You May Also Like

Related Reading

Related Study Notes in Microsoft Technologies

Topics covered