Brad Wilson

Unobtrusive Client Validation in ASP.NET MVC 3

Introduction

In ASP.NET MVC 2, we shipped both client- and server-side validation support. The client-side validation that we included in MVC 2 was a custom validation system written against ASP.NET Ajax. We also included an experimental version written against jQuery in the MVC Futures project.

In ASP.NET MVC 3 Beta, we’ve updated the runtime to enable a feature we’re calling “Unobtrusive Client Validation”. We have also created a consumer for these unobtrusive client validation attributes that uses jQuery and jQuery Validate to perform the validation on our behalf.

Unobtrusive Ajax in ASP.NET MVC 3

Introduction

In ASP.NET MVC 1.0, we shipped Ajax helpers implemented as extension methods on the AjaxHelper class (and available via the Ajax property of your views). In the box, we shipped two category of Ajax helpers: Ajax links and Ajax forms. Both fundamentally did the same thing: make an asynchronous request, and do something with the result when you’re finished (including knowing whether you got back a success or failure response from the server).

In ASP.NET MVC 3 Beta, we've updated the runtime to enable a feature we're calling "Unobtrusive Ajax". We have also created a consumer for these unobtrusive Ajax attributes that uses jQuery to perform the Ajax requests on our behalf.

ASP.NET MVC 3 Service Location, Part 11: View Page Activator

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

View Page Activator

In ASP.NET MVC, it’s common for views to be compiled into classes. In MVC 1.0, we shipped the WebFormViewEngine as the default view engine, which allowed the user to write views using the familiar <% %> syntax from ASP.NET WebForms. The first time the view is rendered, the view file goes through a code generation step, which is compiled into a class. The WebFormView class is responsible for creating and executing the class that resulted from the view.

In ASP.NET MVC 3, we introduced a new Razor view engine. Like the WebForm view engine, the .cshtml and .vbhtml files from Razor go through a code generation step at run-time which compiles down into classes. The RazorView class is the Razor view engine counterpart to the WebFormView class.

We have introduced a new base class (BuildManagerCompiledView) and a new service (IViewPageActivator) which is responsible for instantiating instances of the view classes that were compiled from the view files. We have made the IViewPageActivator instance findable via the dependency resolver.

ASP.NET MVC 3 Service Location, Part 10: Controller Activator

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Controller Activator

In MVC 1.0, we introduced IControllerFactory to allow better dependency injection of controller instances. We also provided the DefaultControllerFactory, which created controller instances with Activator.CreateInstance. Some of this is discussed in Part 2 of this series.

We realized that DefaultControllerFactory was actually doing two things: turning the controller name into the controller type, and then instantiating the instance of that type. In ASP.NET MVC 3, we’ve split out the action of instantiating the controller instance into a new service: IControllerActivator. We have made the IControllerActivator instance findable via the dependency resolver.

ASP.NET MVC 3 Service Location, Part 9: Model Binders

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Model Binders

ASP.NET MVC 1.0 introduced the IModelBinder interface. Developers who implement this interface are responsible for creating models from values obtained from value providers. In ASP.NET MVC 3, we introduced a new interface (IModelBinderProvider) which allows developers to dynamically provide implementations of IModelBinder. We have made IModelBinderProvider instances findable via the dependency resolver.

ASP.NET MVC 3 Service Location, Part 8: Value Providers

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Value Providers

ASP.NET MVC 2 introduced a new method to find value providers: the ValueProviderFactory class. Value providers are used by the model binding system in MVC to populate the values of model objects. MVC includes value providers for several common value sources (including query string, form, route data, uploaded files, and JSON postbacks); MVC Futures includes several mode (including cookies, server values, session values, and temp data values). In ASP.NET MVC 3, we have made ValueProviderFactory instances findable via the dependency resolver.

ASP.NET MVC 3 Service Location, Part 7: Model Metadata

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Model Metadata

ASP.NET MVC 2 introduced an extensible model metadata system where developers could implement a class which derived from ModelMetadataProvider to provide meta-information about the models in the system. In ASP.NET MVC 3, we have made the metadata provider findable via the dependency resolver.

ASP.NET MVC 3 Service Location, Part 6: Model Validation

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

Model Validators

ASP.NET MVC 2 introduced an extensible model validation system where developers could implement a class which derived from ModelValidatorProvider to influence the validation process on both the client-side and server-side. In ASP.NET MVC 3, we have made these validator providers findable via the dependency resolver.

ASP.NET MVC 3 Service Location, Part 5: IDependencyResolver

Series Index

• Part 1: Introduction
• Part 2: Controllers
• Part 3: View Engines and View Pages
• Part 4: Filters
• Part 5: IDependencyResolver
• Part 6: Model Validation
• Part 7: Model Metadata
• Part 8: Value Providers
• Part 9: Model Binders
• Part 10: Controller Activator
• Part 11: View Page Activator

What's New Since Preview 1?

We shipped ASP.NET MVC 3 Beta today, and with it we’ve made some significant progress (and departures) from the MVC 3 Preview 1 build released in July as it pertains to service location.

We received significant feedback during the Preview 1 time frame about our use proposed use of the Common Service Locator. The majority opinion was that MVC should allow Common Service Locators to integrate with MVC, but strict dependence on it was not necessary (or even desirable, since it adds an extra binary dependency for redistribution and deployment).

We have introduced a new interface: System.Web.Mvc.IDependencyResolver. This interface is intended to simplify the requirements for service location/dependency resolution with MVC.