Introduction

ASP.NET MVC 4 list model binding works by matching incoming form field names to the structure of your model. For collections, the binder looks for indexed names such as Items[0].Name and Items[1].Name and then reconstructs a list on the server. Once you understand that naming convention, most list-binding problems stop being mysterious.

The Binder Needs Indexed Field Names

Suppose your view model contains a list of items:

1public class OrderLineViewModel
2{
3    public string ProductName { get; set; }
4    public int Quantity { get; set; }
5}
6
7public class OrderViewModel
8{
9    public List<OrderLineViewModel> Lines { get; set; }
10}

To bind back correctly, the posted form data must use names such as:

• 'Lines[0].ProductName'
• 'Lines[0].Quantity'
• 'Lines[1].ProductName'
• 'Lines[1].Quantity'

That is what the default model binder is looking for.

A Simple Editor Example

Here is a plain Razor example that renders a list with indexed inputs:

1@model OrderViewModel
2
3@using (Html.BeginForm())
4{
5    for (var i = 0; i < Model.Lines.Count; i++)
6    {
7        @Html.TextBoxFor(m => m.Lines[i].ProductName)
8        @Html.TextBoxFor(m => m.Lines[i].Quantity)
9    }
10
11    <button type="submit">Save</button>
12}

And the controller action can receive the list naturally:

1[HttpPost]
2public ActionResult Save(OrderViewModel model)
3{
4    foreach (var line in model.Lines)
5    {
6        System.Diagnostics.Debug.WriteLine(line.ProductName);
7    }
8
9    return View(model);
10}

The TextBoxFor helpers matter because they generate the correct indexed name attributes automatically.

Why Dynamically Added Rows Often Break

List binding problems usually appear when rows are created dynamically with JavaScript. Developers often clone markup without updating the index in the input names. If two rows both post as Lines[0].ProductName, the binder cannot reconstruct the collection as intended.

The fix is to make sure every generated row uses a unique collection index in its input names. In classic MVC, helper templates such as EditorFor were often used to keep that naming consistent.

Sparse Indexes and Hidden Index Fields

MVC can also bind collections with non-sequential indexes if you post explicit index values. This is useful when rows are added and removed dynamically.

A common pattern is:

<input type="hidden" name="Lines.Index" value="abc" />
<input type="text" name="Lines[abc].ProductName" value="Widget" />
<input type="text" name="Lines[abc].Quantity" value="2" />

With that pattern, the binder knows which logical keys belong to the collection even though the indexes are not 0, 1, 2, and so on.

This is the technique behind many dynamic collection editor helpers in older MVC applications.

Practical Rules to Remember

The binder does not care how the HTML looked visually. It only cares about submitted key names and values.

So the practical rules are:

• collection items need indexed names
• nested properties use dot notation after the index
• helper methods are safer than hand-writing names
• dynamic rows must update indexes correctly

Once those rules hold, list model binding is reliable.

Common Pitfalls

• Generating repeated input names for cloned rows.
• Hand-writing collection field names and getting the index pattern wrong.
• Assuming visual order matters more than posted field names.
• Forgetting hidden index fields for dynamically keyed collections.
• Posting only some properties of an item and then wondering why the reconstructed list is incomplete.

Summary

• MVC 4 list binding is driven by input names such as Lines[0].ProductName.
• 'Html.*For helpers usually generate the correct names automatically.'
• Dynamic forms break when indexes are duplicated or not updated.
• Hidden CollectionName.Index fields help when indexes are sparse or dynamic.
• The binder rebuilds the list from posted keys, not from the visible structure of the HTML.