views:

55

answers:

1

We had a View Model that looked like this:

public class myViewModel {
    public Contract contract {get;set;}
    public Vendor vendor {get;set;}
}

public class Contract {
    public int contractID {get;set;}
    // ... various string properties
    public IList<ContractDetail> contractDetails {get;set;}
    pubilc Vendor vendor {get;set;}
}

Coming back from the form was the completed contract.

[HttpPost]
public ActionResult Edit(Contract contract) { ... }

Everything worked binding form post values back to to the contract parameter properties.

When we moved vendor in to Contract as a value object, all the first level "primitive" properties of the Contract fail to bind. All the IList<> properties are fine.

Any ideas or what more information we would need to solve this riddle? Is there any way to test how MVC binds form values back to object parameters? Is the solution something to do with Vendor not being an IList, i.e., why would the IList properties work fine?

Edit:

The fix was to absolutely specify the object hierarchy names in all fields, e.g., for vendor name to bind, it required a name of "Contract.vendor.name". This prefix was done for us using the ViewModel, but not done for us using the Contract model. We ended up doing this for all view templates (partial views):

EditorFor(m => m.vendor, "Vendor", "Contract.vendor")

where "Vendor" is the name of the EditorTemplate "Vendor.ascx" and "Contract.vendor" prefixes all form field names.

I guess because the ViewModel nested all data, it caused MVC to prefix all properties correctly. That would mean that "loose" form fields not qualified by object prefixes will not bind to named parameter objects.

+1  A: 

Just download the mvc source code , do a project reference and debug through the default binder.

redsquare