Asp.net MVC model binding to List<T>

Asp.net MVC is really a great platform to build performant and very controllable web applications. But sometimes some functionality is scarcely documented if at all. Internet proves (thank you Google) to be an invaluable wealth of information in this regard since other developers are usually solving similar problems. But sometimes you either don't find usable information or you want to test things for yourself as well and learn something new as you go along.

Something similar happened to me on my previous project. I had to dynamically generate a list of objects in the browser and then reliably POST them back to web server so that data would be reliably model bound and validated as well. I wanted to avoid manual validation at all costs because it would unnecessarily overcomplicate server code.

The problem in detail

I had to develop functionality for sending messages to other users. So I've written a HttpPost controller action that looked similar to this: public ActionResult SendPrivateMessage(Message message) { ... } At first this looked pretty straight forward if you think of an object of type Message. It would most probably have a title and a message body. But thinking further this class would also need a list of recipients. So I've written a view model class similar to this:

   1:  public class Message

   2:  {

   3:      /// <summary>

   4:      /// Message identifier. Only set when fetching messages.

   5:      /// </summary>

   6:      public int? ID { get; set; }

   7:      

   8:      /// <summary>

   9:      /// Message title.

  10:      /// </summary>

  11:      [Required]

  12:      public string Title { get; set; }

  13:      

  14:      /// <summary>

  15:      /// Message body.

  16:      /// </summary>

  17:      [Required]

  18:      public string Body { get; set; }

  19:      

  20:      /// <summary>

  21:      /// A list of message recipients.

  22:      /// </summary>

  23:      [Required]

  24:      public List<Recipient> Recipients { get; }

  25:  }

As we can see in this class there's a list of recipients of type List<Recipient>.

Recipient class looks like this:

   1:  public class Recipient

   2:  {

   3:      /// <summary>

   4:      /// Recipient identifier.

   5:      /// </summary>

   6:      [Required]

   7:      public int ID { get; set; }

   8:      

   9:      /// <summary>

  10:      /// Recipient's public display name.

  11:      /// </summary>

  12:      [Required]

  13:      public string PublicName { get; set; }

  14:  }

The main objective

The main question here is: How do I prepare a client side <form> that would have an arbitrary number of fields with recipients so that my controller action would be able to model bind it to my Message class.

Client side data preparation

As much as it looks complicated at first it turns out to be pretty straight forward when you make it work. The non trivial part here are of course recipients, because I have to generate these on the client side and name the input fields correctly so default model binder will be able to bind them to my action parameter.

Ok so based on upper classes field naming should look exactly like this:

   1:  <!-- These two are trivial -->

   2:  <input type="text" name="message.Title" value="" />

   3:  <textarea name="message.Body"></textarea>

   4:   

   5:  <!-- And here are recipients -->

   6:  <input type="hidden" name="message.Recipients[0].PublicName" value="John Doe" />

   7:  <input type="hidden" name="message.Recipients[0].Id"         value="1" />

   8:  <input type="hidden" name="message.Recipients[1].PublicName" value="Jane Doe" />

   9:  <input type="hidden" name="message.Recipients[1].Id"         value="2" />

  10:  ...

All I had to guarantee is that:

• every recipient has two input elements (of any type; could be text boxes or hidden fields) with names that correlate to class property names
• recipients list index must start with index 0
• recipients list index mustn't have any gaps

Recipients (input fields) were added/deleted using Javascript. Recipients index number re-indexing was of course done the same way so the second and third requirements were met when a user added/deleted a recipient.

Since I created this functionality to be as usable as possible, a user was able to:

• input few characters into a textbox and an Ajax call returned a List<Recipient> JSON formatted data I could consume and display a list of possible recipients to the user
• select a recipient from a displayed list which added it to the list of selected recipients - at this point new input fields were added and re-indexing was executed
• delete an already added recipient from the list of selected recipients - at his point index gap should be removed (when user didn't delete last entered recipient)

All's well that ends well

Doing my client side form this way I was able to keep my controller action signature as shown at the beginning of this post. My posted data was automatically validated by the framework as well. So my server code didn't have to become more complex due to this at all. It's a win-win situation.