View models
5.3 More complex models for both display and input
return View(input);
}
By declaring the action’s parameter as a NewCustomerInput object, the value is wired up by ASP.NETMVC’s DefaultModelBinder and delivered properly. This is the default behavior in ASP.NETMVC.
Our action works with our strong input model object, not a dictionary of key-value pairs. In this case, it’s not doing much (just sending it as the model of a different view, so in the example we can inspect the “saved” values), but in a real action we’d have the opportunity to work with it like any other class: persist it or pass it along to collaborat-ing classes for further processcollaborat-ing.
Many views aren’t just displays or input forms but combine elements of both to achieve a rich user experience. In the next section, we’ll apply the concepts you’ve already learned in this chapter to a more complex view.
5.3 More complex models for both display and input
Figure 5.3 shows a table that has a list of customer summaries as well as an input ele-ment for each row. End users can see a list of customer summaries, but they can also modify the status of the customer, checking the box if the user should be activated.
Figure 5.3 A combined display and input form
In this section, we’ll build a view model to represent this screen and define an input model that represents the data that the user sends back to the server.
5.3.1 Designing a combined display and input model
This is familiar now, but it’s important enough to reiterate: the presentation model we design represents the screen, and the input model represents user input. Both are as simple as possible, with C# properties reflecting the reality of the UI. Listing 5.7 shows the code for a model that represents the table in figure 5.3.
public class CustomerSummary {
public string Name { get; set; }
public string ServiceLevel { get; set; } public string OrderCount { get; set; }
public string MostRecentOrderDate { get; set; }
public CustomerSummaryInput Input { get; set; } interface, the input elements are nested inside the display. The Input property is the input model for each item
B
. Keeping it as part of the presentation model ensures that it will be easy to maintain: there’s only one class that represents this screen.Note the Number property in CustomerSummaryInput—it’s the ID of each customer and exists to distinguish the inputs. We don’t want our users to intend to activate Jim Doe only to have our application actually activate Susan Power. On this screen it’s important that our application have a logical connection to a specific customer.
5.3.2 Working with the input model
Model binding works the same way. We must be specific in our action signature about which type we intend to model bind. It’s just slightly different because we’re editing multiple customers:
public ViewResult Save
(List<CustomerSummary.CustomerSummaryInput> input) {
return View(input);
}
We direct the model binder to collect all the inputs by accepting a List<Customer-Summary.CustomerSummaryInput>. This works out of the box.
Listing 5.7 A combined display and input model
Input model
5.4 Summary
The main concept in this chapter is designing a model by crafting it to represent the user interface. You saw how a view model designed to support a screen makes the cor-responding view easy to work with. By representing user input with an explicit model object, you can use ASP.NETMVC model binding to work with typed objects. You saw how representing a complex screen with a focused model can make it easier to manage.
With strong presentation models comes an avalanche of simplicity that enables maintainability and rapid construction. Refactoring, renaming, adding fields, and changing behaviors are returned to the world of programming. Freed from the shack-les of the designer and a constant effort to maintain consistency across a myriad of magic strings that may or may not make sense, developers can focus on one thing at a time. The model is at the core of the Model-View-Controller pattern. Armed with knowledge of the M in MVC, you are now ready to move on to chapter 6, where we’ll closely examine user input validation in ASP.NETMVC.
92
Validation
We covered models in the previous chapter, and we’ll continue our examination of the M in MVC by looking at advanced scenarios related to models enabled by ASP.NETMVC. The framework provides support for rich and extensible user input validation. Validation support in the framework is important because user feedback is a common requirement in web applications. It makes sense for the framework to enable things most projects need.
Validation is a big feature in ASP.NETMVC, but it has grown over time. In the first version of the framework it was absent, and integrating third-party validation frame-works was difficult because the extensibility points didn’t exist. ASP.NET MVC 2 brought full support for validation frameworks, as well as built-in support for Micro-soft’s Data Annotations library. The third version of the framework significantly has improved the client-side validation story, rounding out support for scenarios required by today’s web applications.
Many web applications require some level of easy validation from the initial login screen. In this chapter, we’ll examine the built-in validators provided in the Data
This chapter covers
■ Implementing Data Annotations
■ Extending the ModelMetadataProvider
■ Enabling client-side validation
■ Creating custom client side validators
Annotations library. Then we’ll look at extending the model metadata providers with richer, more convention-driven behavior. Finally, we’ll describe how to enable client-side validation, because today’s savvy website visitors demand a rich experience and fast feedback.