Best Practice for Lists of Complex Types in ASP.NET MVC 3

This is my first SO question, and it's less of a "how do I do this" and more of a "what is the cleanest way to do this", because there are several approaches I see but none of them seem very appealing to me.

This is a bit of a complicated issue to describe. Essentially, I have an Add/Edit view that allows the user to edit the fields of some object. This object is pretty complex: it has some fields, and it has a sub-list of complex objects. Each complex object is about 40 fields large (mostly checkboxes, radio buttons and dates/times). I have represented this as a select list:


(source: fortheloot.com)

The Add button spawns the dialog with the various fields.

The question comes here. When the user accepts the dialog, and the dialog closes, I now have to store this data somewhere, so that the user can edit it further or add other sub-items before actually submitting the form.

The most obvious way to do this is to create a set of hidden fields for every sub-object. So, adding a sub-item would add 40-something hidden elements to the

element. Add 10 sub-items and you have 400 hidden fields. This will work fine, and will bind to this model if the fields are named properly:

public class AddEditModel
{
  [Display(Name = "ID")]
  public int? Id { get; set; }

  [Display(Name = "Name")]
  [Required]
  [StringLength(100)]
  public string Name { get; set; }

  public IList Entries { get; set; }
  public class EntryModel { /* fields */ }
}

On the model binding side of things, this seems to look pretty good, but from the client side, I'm having to keep track of hundreds of DOM elements and this seems cumbersome to me. Loading and unloading the dialog's various form elements from 40 other elements seems ... like it could be better.

Ideally, I'd like to be able to just store the data as a javascript object on the element using either data- HTML 5 attributes or jQuery's data() function, which are really one and the same. This would make the javascript side of things much cleaner, but it wouldn't automatically bind to the model on postback.

If there was a way to have the best of both worlds -- storing a single JS object on the element, or even a single element (per sub-item) -- that would still bind to the model properly on postback, I'd feel this issue resolved.

17
задан Glorfindel 10 August 2019 в 11:39
поделиться