views:

568

answers:

1

I have a model that looks something like this:

public class SampleModel
{
    public static SampleModel Create()
    {
        return new SampleModel
        {
            Boolean = true,
            // set several more properties...
            Colors = new SelectList(new[] { "Red", "Green", "Blue" }, "Green")
        };
    }

    public bool Boolean { get; set; }
    // define several more properties...
    public SelectList Colors { get; set; }
}

I'm letting ASP.NET MVC automatically scaffold the properties using Html.DisplayForModel() for my Details view and Html.EditorForModel() for my Edit view.

Results:

  • The Edit view works great. Colors shows up as a menu with three items (Red, Green, and Blue), and Green is selected by default.

  • For the Details view, however, I get "False True False", which is apparently a list of the IsSelected value for each item of the menu. That is definitely not want I want. I would like it to just display "Green".

  • A further problem is that, if I try to do UpdateModel(sampleModel) in my controller, I get the error, "No parameterless constructor defined for this object." This is presumably because Colors is a SelectList, and there is no parameterless constructor for SelectList, so it can't complete the binding.

So, I think I understand what the problems are, but I could really use a good solution for this scenario, which seems to come up a lot when you have models objects with foreign keys.

Some questions:

  1. How do I get Colors to show up as a menu for the Edit view but as just a simple string value (e.g., "Green") in the Details view?
  2. How can I prevent a "no parameterless constructor" error when updating a model that contains a SelectList?
  3. If my Model/ViewModel actually contained a foreign key, ColorId, instead of Colors, what would be the best practice for getting the Details view to show the name of the current color and the Edit view to show a menu containing all the color names listed in the Color table of my database. If it helps, I'm using LinqToSql (SqlMetal) to generate my model classes.
+1  A: 

Your problems all stem from the fact that you're exposing a SelectList as a model property. Depending on the exact situation, I'd probably do something like:

  1. Create 3 separate model classes: one "domain" model consisting of your LinqToSql objects (or wrappers around them) and two view models, one for the Details view and one for the Edit view.

  2. The Details view model should contain the currently selected color name. The Details action would set this property, either using the FK relationship in your domain objects or by manually looking up the details for the selected color.

  3. The Edit view model should contain a property for the selected color's ID. It should also contain a select list of available color options, with the selected value set to the currently selected ID.

  4. The Edit action that handles the form post should accept an instance of the Edit view model and should map those changes onto the domain model. Since the selected color is exposed a simple property, rather than a select list, it's easy to validate and map back onto the business object.

If your situation is very simple you might be able to get away with a single view model for both View and Edit, or even passing the domain object directly to the Details view. In any case, as long as you remove the SelectList from your model and expose the selected color as a simple ID then you should be OK.

Seth Petry-Johnson
True, separate Edit and View models does lead to pairs of classes with lots of the same properties, but it also makes it very easy to modify one view without impacting the other. I'm much more vigilant about keeping my logic DRY than I am my DTOs. You could also have one view model derive from the other, but unless your views are very simple this might be more trouble than its worth.
Seth Petry-Johnson