I absolutely disdain times that I have to modify the domain model to accommodate the inflexibility of UI components. For example, I've encountered situations wherein I'd have to write "pass through" or concatenation properties that would simply append other properties together and expose the summary data to a UI component that could only handle a single property. To illustrate, in previous releases of ASP.NET MVC, if you wanted to use the DropDownList helper, and wanted to have a customer's full name and email address as the text of the DropDownList (e.g., "Čapek, Karel (rur@example.com)"), you might be tempted to add a concatenation property as follows:
public class Customer {
public FirstName { get; set; }
public LastName { get; set; }
public Email { get; set; }
public FullNameAndEmail {
return LastName + ", " + FirstName + " (" + Email + ")";
}
}
There are various approaches you can take to keep the above example out of the domain object, but it'll still likely be done somewhere other than within the view itself; incidentally, the view is, ideally, the only artifact which should actually care about how the data is displayed. The problem with this is that you're introducing UI concerns into the domain object (or wherever you end up handling it) when it should be up to the view itself.
With each release of ASP.NET MVC, I'm further impressed with the flexibility that it exhibits. For the task at hand, ASP.NET MVC RC 1 has extended DropDownList and ListBox helpers to accept IEnumerable<ListItem> in addition to SelectList and MultiSelectList. A great benefit of this is that it enables a select list to include a "summary property" as its text field without having to add such a concatenation, summary property to the domain object itself. The following LINQ select could be passed as the argument to the DropDownList helper to accomplish what we're trying to do:
from customer in ViewData.Model.Customers
select new SelectListItem {
Text = (customer.LastName + ", " + customer.FirstName + " (" + customer.Email + ")"),
Value = customer.Id,
Selected = (customer.Id == ViewData.Model.SelectedCustomerId
}
Regardless of how the data is being given to the view, e.g., as a DTO or as the domain object itself, this added flexibility allows us to remove one more view concern out of all the layers accept the view itself.
Billy McCafferty
Posted
02-07-2009 7:27 PM
by
Billy McCafferty