博客园_Artech

通过实例模拟ASP.NET MVC的Model绑定机制[上篇]

2012-05-23T00:20:00Z

总的来说，针对目标Action方法参数的Model绑定完全由组件ModelBinder来实现，在默认情况下使用的ModelBinder类型为DefaultModelBinder，接下来我们将按照逐层深入的方式介绍实现在DefaultModelBinder的默认Model绑定机制。[源代码从这里下载][本文已经同步到《How ASP.NET MVC Works?》中]

目录
一、简单类型
二、复杂类型
三、数组
四、集合
五、字典

一、简单类型

对于旨在绑定目标Action方法参数值的Model来说，最简单的莫过于简单参数类型的情况。通过《初识Model元数据》的介绍我们知道，复杂类型和简单类型之间的区别仅仅在于是否支持针对字符串类型的转换。由于参数值的数据源在请求中以字符串的形式存在，对于支持字符串转换的简单类型来说，可以直接通过类型转换得到参数值。我们通过一个简单的实例来模拟实现在DefaultModelBinder中针对简单类型的Model绑定。如下所示的是我们自定义的DefaultModelBinder，其属性ValueProvider用于从请求中提供相应的数据值，该属性在构造函数中被初始化。

        1: public class DefaultModelBinder       2: {       3:     public IValueProvider ValueProvider { get; private set; }       4:     public DefaultModelBinder(IValueProvider valueProvider)       5:     {       6:         this.ValueProvider = valueProvider;       7:     }       8:         9:      public IEnumerable<object> GetParameterValues(ActionDescriptor actionDescriptor)      10:     {      11:         foreach (ParameterDescriptor parameterDescriptor in actionDescriptor.GetParameters())      12:         {      13:             string prefix = parameterDescriptor.BindingInfo.Prefix ?? parameterDescriptor.ParameterName;      14:             yield return GetParameterValue(parameterDescriptor, prefix);      15:         }      16:     }      17:        18:     public object GetParameterValue(ParameterDescriptor parameterDescriptor, string prefix)      19:     {      20:         object parameterValue = BindModel(parameterDescriptor.ParameterType, prefix);      21:         if (null == parameterValue && string.IsNullOrEmpty(parameterDescriptor.BindingInfo.Prefix))      22:         {      23:             parameterValue = BindModel( parameterDescriptor.ParameterType, "");      24:         }      25:         return parameterValue ?? parameterDescriptor.DefaultValue;      26:      }      27:        28:     public object BindModel(Type parameterType, string prefix)      29:     {      30:         if (!this.ValueProvider.ContainsPrefix(prefix))      31:         {      32:             return null;      33:         }      34:         return this.ValueProvider.GetValue(prefix).ConvertTo(parameterType);      35:     }      36: }

方法GetParameterValues根据指定的用于描述Action方法的ActionDescriptor获取最终执行该方法的所有参数值。在该方法中，我们通过调用ActionDescriptor的GetParameters方法得到用于描述其参数的所有ParameterDescriptor对象，并将每一个ParameterDescriptor作为参数调用GetParameterValue方法得到具体某个参数的值。GetParameterValue除了接受一个类型为ParameterDescriptor的参数外，还接受一个用于表示前缀的字符串参数。如果通过ParameterDescriptor的BindingInfo属性表示的ParameterBindingInfo对象具有前缀，则采用该前缀；否则采用参数名称作为前缀。

对于GetParameterValue方法来说，它又通过调用另一个将参数类型作为参数的BindModel方法来提供具体的参数值，BindModel方法同样接受一个表示前缀的字符串作为其第二个参数。GetParameterValue最初将通过ParameterDescriptor获取到的参数值和前缀作为参数调用BindModel方法，如果返回值为Null并且参数并没有显示执行前缀，会传入一个空字符串作为前缀再一次调用BindModel方法，这实际上模拟了之前提到过的去除前缀的后备Model绑定机制（针对于ModelBindingContext的FallbackToEmptyPrefix属性）。如果最终得到的对象不为Null，则将其作为参数值返回；否则返回参数的默认值。

BindModel方法的逻辑非常简单。先将传入的前缀作为参数调用ValueProvider的ContainsPrefix方法判断当前的ValueProvider保持的数据是否具有该前缀。如果返回之为False，直接返回Null，否则以此前缀作为Key调用GetValue方法得到一个ValueProviderResult调用，并最终调用ConvertTo方法转换为参数类型并返回。

为了验证我们自定义的DefaultModelBinder能够真正地用于针对简单参数类型的Model绑定没我们将它应用到一个具体的ASP.NET MVC应用中。在通过Visual Studio的ASP.NET MVC项目模板创建的空Web应用中，我们创建了如下一个默认的HomeController。HomeController具有一个ModelBinder属性，其类型正是我们自定义的DefaultModelBinder，该属性通过方法GetValueProvider提供。

       1: public class HomeController : Controller       2: {       3:     public DefaultModelBinder ModelBinder { get; private set; }       4:     public HomeController()       5:     {       6:         this.ModelBinder = new DefaultModelBinder(GetValueProvider());       7:     }              8:     private void InvokeAction(string actionName)       9:     {      10:         ControllerDescriptor controllerDescriptor = new ReflectedControllerDescriptor(typeof(HomeController));      11:         ReflectedActionDescriptor actionDescriptor = (ReflectedActionDescriptor)controllerDescriptor      12:             .FindAction(ControllerContext, actionName);      13:         actionDescriptor.MethodInfo.Invoke(this,this.ModelBinder.GetParameterValues(actionDescriptor).ToArray());      14:     }      15:     public void Index()      16:     {      17:         InvokeAction("Action");      18:     }      19:        20:     private IValueProvider GetValueProvider()      21:     {      22:         NameValueCollection requestData = new NameValueCollection();      23:         requestData.Add("foo", "abc");      24:         requestData.Add("bar", "123");      25:         requestData.Add("baz", "123.45");      26:         return new NameValueCollectionValueProvider(requestData, CultureInfo.InvariantCulture);      27:     }      28:     public void Action(string foo, [Bind(Prefix="baz")]double bar)      29:     {      30:         Response.Write(string.Format("{0}: {1}<br/>", "foo", foo));      31:         Response.Write(string.Format("{0}: {1}<br/>", "bar", bar));      32:     }      33: }

InvokeAction方法用于执行指定的Action方法。在该方法中我们先根据当前Controller的类型创建一个ControllerDescriptor对象，并通过调其FindAction方法得到用于描述指定Action方法的ActionDescriptor对象。通过之前的介绍我们知道这是一个ReflectedActionDescriptor对象，所以我们将其转化成ReflectedActionDescriptor类型得到Action方法对应的MethodInfo对象。最后调用DefaultModelBinder的GetParameterValues方法得到目标Action方法所有的参数，将其传入MethodInfo的Invoke方法以反射的形式对指定的Action方法进行执行。

默认的Action方法Index中我们通过执行InvokeAction方法来执行定义在HomeController的Action方法。通过上面的代码片断可以看出，该方法的两个参数foo和bar均为简单类型（string和double），在参数bar上还应用了BindAttribute并指定了相应的前缀（“baz”）。在该Action方法中，我们将两个参数值呈现出来。

而在用于提供ValueProvider的GetValueProvider方法返回的是一个NameValueCollectionValueProvider对象。作为数据源的NameValueCollection对象包含三个名称为foo、bar和baz的数据（abc、123、123.45），我们可以将它们看成是Post的标单输入元素。

当我们运行该程序的时候会在浏览器中得到如下的输出结果。我们可以看到目标Action方法的两个参数值均通过我们自定义的DefaultModelBinder得到了有效的绑定。而实际上参数值的提供最终是通过ValueProvider实现的，它在默认的情况下会根据参数名称进行匹配（foo参数），如果参数应用BindAttribute并显式指定了前缀，则会按照这个前缀进行匹配（bar参数）。

1: foo: abc 2: bar: 123.45

二、复杂类型

对于简单类型的参数来说，由于支持与字符串类型之间的转换，相应ValueProvider可以直接从数据源中提取相应的数据并直接转换成参数类型。所以针对简单类型的Model绑定是一步到位的过程，但是针对复杂类型的Model绑定就没有这么简单了。复杂对象可以表示为一个树形层次化结构，其对象本身和属性代表相应的节点，叶子节点代表简单数据类型属性。而ValueProvider采用的数据源是一个扁平的数据结构，它通过基于属性名称前缀的Key实现与这个对象树中对应叶子节点的映射。

       1: public class Contact       2: {       3:     public string Name { get; set; }       4:     public string PhoneNo { get; set; }       5:     public string EmailAddress { get; set; }       6:     public Address Address { get; set; }       7: }       8: public class Address       9: {      10:     public string Province { get; set; }      11:     public string City { get; set; }      12:     public string District { get; set; }      13:     public string Street { get; set; }      14: }

以上面定于得这个Contact类型为例，它具有三个简单类型的属性（Name、PhoneNo和EmailAddress）和复杂类型Address的属性；而Address属性具有四个简单类型的属性。一个Contact对象的数据结构可以通过如下图所示的树来表示，这个树种的所有叶子节点均为简单类型。如果我们需要通过一个ValueProvider来构建一个完整的Contact对象，它必须能够提供所有所有叶子节点的数值，而ValueProvider通过基于属性名称前缀的Key实现与对应的叶子节点的映射。

实际上当我们调用HtmlHelper<TModel>的模板方法EditorFor/EditorForModel的时候就是按照这样的匹配方式对标单元素进行命名的。假设在将Contact作为Model类型的强类型View中，我们通过调用HtmlHelper<TModel>的扩展方法EditorFor将Model对象的所有信息以编辑的模式呈现出来。

       1: @model Contact       2: @Html.EditorFor(m => m.Name)       3: @Html.EditorFor(m => m.PhoneNo)       4: @Html.EditorFor(m => m.EmailAddress)       5: @Html.EditorFor(m => m.Address.Province)       6: @Html.EditorFor(m => m.Address.City)       7: @Html.EditorFor(m => m.Address.District)       8: @Html.EditorFor(m => m.Address.Street)

下面的代码片断代表了作为Model对象的Contact在最终呈现出来的View中代表的HTML，我们可以清楚地看到这些<input>表单元素完全是根据属性名称和类型层次结构进行命名的。随便提一下，对于基于提交表单的Model绑定来说，作为匹配的是表单元素的name属性而非id属性，所以这里的命名指的是name属性而非id属性。

       1: <input id="Name" name="Name" type="text" ... />       2: <input id="PhoneNo" name="PhoneNo" type="text" ... />       3: <input id="EmailAddress" name="EmailAddress" type="text" ... />       4: <input id="Address_Province" name="Address.Province" type="text" ... />       5: <input id="Address_City" name="Address.City" type="text" ... />       6: <input id="Address_District" name="Address.District" type="text" ... />       7: <input id="Address_Street" name="Address.Street" type="text"... />

对于用于模拟默认Model绑定机制的自定义DefaultModelBinder来说，我们仅仅提供了针对简单类型的绑定，现在我们对其进行完善是之可以提供对复杂类型的Model绑定。如下面的代码片断所示，在BindModel方法中我们创建了一个基于参数类型的ModelMetadata对象，并根据其IsComplexType属性判断参数类型是否为复杂类型。

       1: public class DefaultModelBinder       2: {       3:     //其他成员       4:     public object BindModel(Type parameterType, string prefix)       5:     {       6:         if (!this.ValueProvider.ContainsPrefix(prefix))       7:         {       8:             return null;       9:         }      10:         ModelMetadata modelMetadata = ModelMetadataProviders.Current.GetMetadataForType(() => null, parameterType);      11:         if (!modelMetadata.IsComplexType)      12:         {      13:             return this.ValueProvider.GetValue(prefix).ConvertTo(parameterType);      14:         }                  15:         object model = CreateModel(parameterType);      16:         foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(parameterType))      17:         {                      18:             string key = string.IsNullOrEmpty(prefix) ? property.Name : prefix + "." + property.Name;      19:             property.SetValue(model, BindModel(property.PropertyType, key));      20:         }      21:         return model;      22:     }      23:     private object CreateModel(Type modelType)      24:     {      25:         Type type = modelType;      26:         if (modelType.IsGenericType)      27:         {      28:             Type genericTypeDefinition = modelType.GetGenericTypeDefinition();      29:             if (genericTypeDefinition == typeof(IDictionary<,>))      30:             {      31:                 type = typeof(Dictionary<,>).MakeGenericType(modelType.GetGenericArguments());      32:             }      33:             else if (((genericTypeDefinition == typeof(IEnumerable<>)) || (genericTypeDefinition == typeof(ICollection<>))) ||(genericTypeDefinition == typeof(IList<>)))      34:             {      35:                 type = typeof(List<>).MakeGenericType(      36:                 modelType.GetGenericArguments());      37:             }      38:         }      39:         return Activator.CreateInstance(type);      40:     }      41: }

如果参数为复杂类型，则通过调用CreateModel方法以反射的方式创建Model对象。CreateModel方法会被用于后面我们会介绍的基于集合和字典的Model绑定，所以我们这里还针对泛型的IDictionary<,>、IEnumerable<>、ICollection<>和IList<>类型作了相应地处理。具体来说，如果参数类型为IDictionary<,>，则创建一个Dictionary<,>对象，而对后三者则创建一个List<>对象，具体的泛型参数根据参数类型获取。对于一般的类型，我们直接通过Activator的CreateInstance方法根据参数类型创建相应的Model对象。

通过CreateModel方法创建的是针对参数类型的“空”对象，我们需要通过Model绑定对它的相关属性进行初始化。在BindModel方法中，我们遍历参数类型的所有属性，并在现有前缀的基础上加上“.{属性名称}”（如果当前前缀为空，则直接采用属性名称）作为绑定对应属性的前缀递归地调用BindModel方法得到属性值。我们最终通过反射的方式将得到值对属性进行赋值。

现在我们采用我们完善后的DefaultModelBinder来进行针对复杂类型的Model绑定。如下面的代码片断所示，我们对HomeController的Action方法进行了相应的修改使之具有两个Contact类型的参数foo和bar。在Action方法中，我们将这两个参数代表的Contact对象的相关信息呈现出来。

       1: public class HomeController : Controller       2: {       3:     public DefaultModelBinder ModelBinder { get; private set; }       4:     public HomeController()       5:     {       6:         this.ModelBinder = new DefaultModelBinder(GetValueProvider());       7:     }       8:         9:     private IValueProvider GetValueProvider()      10:     {      11:         NameValueCollection requestData = new NameValueCollection();      12:         requestData.Add("Name", "张三");      13:         requestData.Add("PhoneNo", "123456789");      14:         requestData.Add("EmailAddress", "zhangsan@gmail.com");      15:         requestData.Add("Address.Province", "江苏");      16:         requestData.Add("Address.City", "苏州");      17:         requestData.Add("Address.District", "工业园区");      18:         requestData.Add("Address.Street", "星湖街328号");      19:         return new NameValueCollectionValueProvider(requestData, CultureInfo.InvariantCulture);      20:     }          21:        22:     public void Index()      23:     {      24:         InvokeAction("Action");      25:     }      26:        27:     public void Action(Contact foo, Contact bar)      28:     {      29:         Response.Write("Foo<br/>");      30:         Response.Write(string.Format("{0}: {1}<br/>", "Name", foo.Name));      31:         Response.Write(string.Format("{0}: {1}<br/>", "PhoneNo", foo.PhoneNo));      32:         Response.Write(string.Format("{0}: {1}<br/>", "EmailAddress", foo.EmailAddress));      33:         Response.Write(string.Format("{0}: {1} {2} {3} {4}<br/><br/>", "Address",       34:            foo.Address.Province, foo.Address.City, foo.Address.District,       35:            foo.Address.Street));      36:        37:         Response.Write("Bar<br/>");      38:         Response.Write(string.Format("{0}: {1}<br/>", "Name", bar.Name));      39:         Response.Write(string.Format("{0}: {1}<br/>", "PhoneNo", bar.PhoneNo));      40:         Response.Write(string.Format("{0}: {1}<br/>", "EmailAddress", bar.EmailAddress));      41:         Response.Write(string.Format("{0}: {1} {2} {3} {4}<br/>", "Address",       42:             bar.Address.Province, bar.Address.City, bar.Address.District,       43:             bar.Address.Street));       44:     }      45: }

通过GetValueProvider方法提供的依然是一个NameValueCollectionValueProvider对象，我们将一个Contact对象包含的信息包含在它对应的NameValueCollection对象中。对于添加到NameValueCollection中的针对Contact对象的某个属性的数据条目，我们按照上面介绍的匹配规则对其命名。运行我们的实例程序，我们会在浏览器中得到如下所示的输出结果，我们从中可以看到Action方法的两个参数foo和bar通过我们自定义的DefaultModelBinder进行了正确地绑定，并且它们具有相同的值。

       1: Foo       2: Name: 张三       3: PhoneNo: 123456789       4: EmailAddress: zhangsan@gmail.com       5: Address: 江苏 苏州 工业园区 星湖街328号       6:         7: Bar       8: Name: 张三       9: PhoneNo: 123456789      10: EmailAddress: zhangsan@gmail.com      11: Address: 江苏 苏州 工业园区 星湖街328号

之所以同一个Action方法中两个相同类型的参数会绑定相同的数据，使缘于之前介绍的去除前缀的后备Model绑定机制。由于请求数据中并不包含针对某个参数的前缀，所以在针对参数名称作为前缀的Model绑定失败的情况下，后备Model绑定会前缀为空字符串的情况下再次进行。

       1: public class HomeController : Controller       2: {       3:     //其他成员       4:     private IValueProvider GetValueProvider()       5:     {       6:         NameValueCollection requestData = new NameValueCollection();       7:         requestData.Add("foo.Name", "Foo");       8:         requestData.Add("foo.PhoneNo", "123456789");       9:         requestData.Add("foo.EmailAddress", "Foo@gmail.com");      10:        11:         requestData.Add("bar.Name", "Bar");      12:         requestData.Add("bar.PhoneNo", "987654321");      13:         requestData.Add("bar.EmailAddress", "Bar@gmail.com");      14:         return new NameValueCollectionValueProvider(requestData, CultureInfo.InvariantCulture);      15:     }      16:        17:     public void Action(Contact foo, Contact bar)      18:     {      19:         Response.Write("Foo<br/>");      20:         Response.Write(string.Format("{0}: {1}<br/>", "Name", foo.Name));      21:         Response.Write(string.Format("{0}: {1}<br/><br/>", "PhoneNo", foo.PhoneNo));      22:         Response.Write(string.Format("{0}: {1}<br/>", "EmailAddress", foo.EmailAddress));      23:        24:         Response.Write("Bar<br/>");      25:         Response.Write(string.Format("{0}: {1}<br/>", "Name", bar.Name));      26:         Response.Write(string.Format("{0}: {1}<br/>", "PhoneNo", bar.PhoneNo));      27:         Response.Write(string.Format("{0}: {1}<br/>", "EmailAddress",   bar.EmailAddress));      28:     }      29: }

在如上所示的代码中，我们为NameValueCollectionValueProvider设置了基于“foo”和“bar”的前缀的两套数据，目的在为Action方法的foo和bar参数提供不同的数据。运行我们的程序后会在浏览器上得到如下所示的输出结果，可以看出Action方法的两个参数被绑定了不同的值。

1: Foo 2: Name: Foo 3: PhoneNo: 123456789 4: EmailAddress: Foo@gmail.com 5: 6: Bar 7: Name: Bar 8: PhoneNo: 987654321 9: EmailAddress: Bar@gmail.com

通过实例模拟ASP.NET MVC的Model绑定的机制[上篇]
通过实例模拟ASP.NET MVC的Model绑定的机制[下篇]

本文链接

ModelBinder——ASP.NET MVC Model绑定的核心

2012-05-21T00:12:00Z

Model的绑定体现在从当前请求提取相应的数据绑定到目标Action方法的参数。通过前面的介绍我们知道Action方法的参数通过ParameterDescriptor来描述，ParameterDescriptor的BindingInfo属性表示的ParameterBindingInfo对象具有一个名为ModelBinder的组件用于完成针对当前参数的Model绑定。ModelBinder可以看成是整个Model绑定系统的核心，我们先来认识这个重要的组件。[本文已经同步到《How ASP.NET MVC Works?》中]

目录
一、 ModelBinder
二、CustomModelBinderAttribute与ModelBinderAttribute
三、ModelBinders
四、ModelBinderProvider

一、 ModelBinder

用于进行Model绑定的ModelBinder对象实现了接口IModelBinder。如下面的代码片断所示，IModelBinder接口具有唯一的BindModel方法用于实现针对某个参数的绑定操作，该方法的返回值表示的就是最终作为参数值的对象。

        1: public interface IModelBinder       2: {       3:     object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext);       4: }

IModelBinder的BindModel方法接受两个参数，一个是表示当前的Controller上下文，另一个是表示针对当前Model绑定的上下文，通过类型ModelBindingContext表示。在Controller初始化的时候，Controller上下文已经被创建出来，所以我们只要能够针对当前的Model绑定创建相应的ModelBindingContext，我们就能使用基于某个参数的ModelBinder得到对应的参数值。关于ModelBindingContext的创建我们会在后续部分进行的单独介绍，我们先来介绍一下ModelBinder的提供机制。

二、CustomModelBinderAttribute与ModelBinderAttribute

如果针对某个参数的ParameterDescriptor具有相应的ModelBinder，那么它会被优先选择用于针对该参数的Model绑定，那么ParameterDescriptor的ModelBinder是如何来提供的呢？这是实际上设置一个具有如下定义的CustomModelBinderAttribute特性。抽象类CustomModelBinderAttribute定义了唯一的抽象方法GetBinder用于获取相应的ModelBinder对象。

       1: [AttributeUsage(AttributeTargets.Parameter | AttributeTargets.Interface | AttributeTargets.Enum | AttributeTargets.Struct        2:     | AttributeTargets.Class, AllowMultiple=false, Inherited=false)]       3: public abstract class CustomModelBinderAttribute : Attribute       4: {       5:     public abstract IModelBinder GetBinder();       6: }

在ASP.NET MVC应用编程接口中，CustomModelBinderAttribute具有一个具有如下定义的唯一继承类型ModelBinderAttribute。我们可以通过应用ModelBinderAttribute特性动态地选择用于Model绑定的ModelBinder类型。

       1: [AttributeUsage(AttributeTargets.Parameter | AttributeTargets.Interface |        2:     AttributeTargets.Enum | AttributeTargets.Struct | AttributeTargets.Class,        3:     AllowMultiple=false, Inherited=false)]       4: public sealed class ModelBinderAttribute : CustomModelBinderAttribute       5: {          6:     public ModelBinderAttribute(Type binderType);       7:     public override IModelBinder GetBinder();       8:         9:     public Type BinderType { [CompilerGenerated] get;  }      10: }

从应用在ModelBinderAttribute类型上的AttributeUsageAttribute定义可以看出该特性不仅仅可以应用在参数上，也可以应用类型（接口、枚举、结构和类）上，这意味我们既可以将它应用在Action方法的某个参数上，也可以将它应用在某个参数的类型上。但是ParameterDescriptor只会解析应用在参数上的特性，所以应用在参数对象类型上的ModelBinderAttribute对它是无效的。

为了演示ModelBinderAttribute特性对ParameterDescriptor的影响，我们来进行一个简单的实例演示。在一个通过Visual Studio的ASP.NET MVC项目模板创建的空Web应用中定义了如下几个类型，其中FooModelBinder和BarModelBinder是显现了IModelBinder的自定义ModelBinder类型，而Foo、Bar和Baz是三个将被作为Action方法参数的数据类型，其中Bar上应用了ModelBinderAttribute特性并将ModelBinder类型设置为BarModelBinder。

       1: public class FooModelBinder : IModelBinder       2: {       3:     public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)       4:     {       5:         throw new NotImplementedException();       6:     }       7: }       8: public class BarModelBinder : IModelBinder       9: {      10:     public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)      11:     {      12:         throw new NotImplementedException();      13:     }      14: }      15:        16: public class Foo { }      17: [ModelBinder(typeof(BarModelBinder))]      18: public class Bar { }      19: public class Baz { }

然后再创建的默认HomeController中定义如下两个Action方法。DoSomething方法具有三个参数，类型分别是Foo、Bar和Baz，在第一个参数上应用了ModelBinderAttribute特性并将ModelBinder类型设置为FooModelBinder。

       1: public class HomeController : Controller       2: {       3:     public void Index()       4:     {       5:         ControllerDescriptor controllerDescriptor = new ReflectedControllerDescriptor(typeof(HomeController));       6:         ActionDescriptor actionDescriptor = controllerDescriptor.FindAction(ControllerContext, "DoSomething");       7:         IModelBinder foo = actionDescriptor.GetParameters().First(p => p.ParameterName == "foo").BindingInfo.Binder;       8:         IModelBinder bar = actionDescriptor.GetParameters().First(p => p.ParameterName == "bar").BindingInfo.Binder;       9:         IModelBinder baz = actionDescriptor.GetParameters().First(p => p.ParameterName == "baz").BindingInfo.Binder;      10:        11:         Response.Write(string.Format("foo: {0}<br/>", null == foo? "N/A": foo.GetType().Name));      12:         Response.Write(string.Format("bar: {0}<br/>", null == bar ? "N/A" : bar.GetType().Name));      13:         Response.Write(string.Format("baz: {0}<br/>", null == baz ? "N/A" : baz.GetType().Name));      14:     }      15:        16:     public void DoSomething([ModelBinder(typeof(FooModelBinder))]Foo foo,Bar bar, Bar baz)      17:     {}                      18: }

在默认的Action方法Index中，我们针对HomeController类型的ReflectedControllerDescriptor对象并获取到用于描述Action方法DoSomething的ActionDescriptor对象。最后我们通过该ActionDescriptor对象得到用于描述其三个参数的ParameterDescriptor对象，并将其ModelBinder类西国内呈现出来。当我们运行该程序的时候，会在浏览器中产生如下的输出结果，可以看出对于分别应用在参数和参数类型上的ModelBinderAttribute特性，只有前者会对ParameterDescriptor的ModelBinder的选择造成影响。

1: foo: FooModelBinder 2: bar: N/A 3: baz: N/A

三、ModelBinders

如果我们不曾通过ModelBinderAttribute特性为某个Action方法参数的ModelBinder类型进行显式定制，默认采用的Model是通过静态类型ModelBinders来提供的。如下面的代码片断所示，ModelBinders具有一个静态只读属性Binders，表示当前注册ModelBinder列表，其类型为ModelBinderDictionary。

       1: public static class ModelBinders       2: {          3:     public static ModelBinderDictionary Binders { get; }       4: }       5:         6: public class ModelBinderDictionary :        7:   IDictionary<Type, IModelBinder>,        8:   ICollection<KeyValuePair<Type, IModelBinder>>,        9:   IEnumerable<KeyValuePair<Type, IModelBinder>>,       10:   IEnumerable      11: {          12:     //其他成员      13:     public IModelBinder GetBinder(Type modelType);      14:    public virtual IModelBinder GetBinder(Type modelType, bool fallbackToDefault);      15: }

ModelBinderDictionary是一个以数据类型（Model类型）为Key，ModelBinder对象为Value的字典，即它定义了针对某种数据类型的ModelBinder。ModelBinderDictionary具有两个GetBinder方法重载用于获取针对某个数据类型的ModelBinder，布尔类型的参数fallbackToDefault表示在数据类型不存在的时候是否采用默认的ModelBinder，基于默认ModelBinder的后备机制会在第一个GetBinder方法重载中采用。在这里默认ModelBinder类型为DefaultModelBinder。

在为某个参数获取相应的ModelBinder的时候，如果对应的ParameterDescriptor的ModelBinder不存在，则通过ModelBinders的静态属性Binders表示获取到当前注册的ModelBinder列表的ModelBinderDictionary对象，并将参数类型作为参数调用其GetBinder方法获取相应ModelBinder对象。

我们根据ModelBinder的提供机制对上面演示的实例进行相应的修改。我们在HomeConroller中添加了一个CheckModelBinder方法，三个参数分别表示用于描述相应Action方法的ActionDescriptor对象、参数名称和类型。在该方法中我们先获取到用于描述制定参数的ParameterDescriptor对象，如果它具有相应的ModelBinder，则将具体的类型名称输出，否则输出通过ModelBinders获取的针对参数类型的ModelBinder类型。

       1: public class HomeController : Controller       2: {       3:     //其他成员       4:     public void Index()       5:     {       6:         ControllerDescriptor controllerDescriptor = new ReflectedControllerDescriptor(typeof(HomeController));       7:         ActionDescriptor actionDescriptor = controllerDescriptor.FindAction(ControllerContext, "DoSomething");       8:         9:         CheckModelBinder(actionDescriptor, "foo", typeof(Foo));      10:         CheckModelBinder(actionDescriptor, "bar", typeof(Bar));      11:         CheckModelBinder(actionDescriptor, "baz", typeof(Baz));                 12:     }      13:        14:     private void CheckModelBinder(ActionDescriptor actionDescriptor, string parameterName, Type modelType)      15:     {       16:         ParameterDescriptor parameterDescriptor = actionDescriptor.GetParameters().First(p=>p.ParameterName == parameterName);      17:         IModelBinder modelBinder = parameterDescriptor.BindingInfo.Binder ?? ModelBinders.Binders.GetBinder(modelType);      18:         Response.Write(string.Format("{0}: {1}<br/>", parameterName, null == modelBinder ? "N/A" : modelBinder.GetType().Name));      19:     }      20: }

在Index方法中，我们调用CheckModelBinder方法将Action方法DoSomething的三个参数对应的ModelBinder类型呈现出来。当我们运行该程序的时候，在浏览器上会得到如下的输出结果，应用在类型Bar上的BarModelBinder会用于针对参数bar的Model绑定，而参数baz则会使用默认的DefaultModelBinder。

       1: foo: FooModelBinder       2: bar: BarModelBinder       3: baz: DefaultModelBinder

对于上面的这个例子，由于数据类型Baz没有关联ModelBinder注册到通过ModelBinders的静态属性Binders表示的全局ModelBinder列表中，所以才导致DoSomething的baz参数采用默认的DefaultModelBinder。如果我们实现针对数据类型Baz进行了相应的ModelBinder注册，那么被注册的ModelBinder将会自动用于该类型参数的Model绑定。同样是针对上面演示的这个实例，我们定义了如下一个实现了IModelBinder的BazModelBinder。

       1: public class BazModelBinder : IModelBinder       2: {       3:     public object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)       4:     {       5:         throw new NotImplementedException();       6:     }       7: }

现在我们希望使用这个BazModelBinder用于针对所有类型为Bar的参数的Model绑定，那么我们可以通过Global.asax在应用启动的时候进行如下的ModelBinder注册。

       1: public class MvcApplication : System.Web.HttpApplication       2: {       3:     //其他成员       4:     protected void Application_Start()       5:     {       6:         //其他操作       7:         ModelBinders.Binders.Add(typeof(Baz), new BazModelBinder());       8:     }       9: }

再次运行我们的程序，在浏览器中会得到如下的输出结果，从中可以清楚地看出我们注册的BazModelBinder并用于baz参数的Model绑定。

       1: foo: FooModelBinder       2: bar: BarModelBinder       3: baz: BazModelBinder

四、ModelBinderProvider

ASP.NET MVC的Model绑定系统还涉及到另一个重要的组件ModelBinderProvider。顾名思义，ModelBinderProvider专门用于提供相应的ModelBinder对象，它们均实现了IModelBinderProvider面的代码片断所示，IModelBinderProvider接口定义了唯一的GetBinder方法用于根据数据类型获取相应的ModelBinder对象。不过在ASP.NET MVC现有的应用编程接口中并没有定义任何一个实现该接口的ModelBinderProvider类型。

       1: public interface IModelBinderProvider       2: {           3:     IModelBinder GetBinder(Type modelType);       4: }

我们可以利用ModelBinderProviders为应用注册一组ModelBinderProvider对象为某个数据类型提供相应的ModelBinder。如下面的代码片断所示，静态类型ModelBinderProviders具有一个静态只读属性BinderProviders，其类型ModelBinderProviderCollection实际上是一个型ModelBinderProvider的集合，该集合表示针对当前应用的ModelBinderProvider列表。

       1: public static class ModelBinderProviders       2: {           3:     public static ModelBinderProviderCollection BinderProviders { get; }       4: }       5:         6: public sealed class ModelBinderProviderCollection : Collection<IModelBinderProvider>       7: {       8:     //省略成员       9: }

通过ModelBinderProviders的静态属性BinderProviders表示的ModelBinderProvider列表最终被ModelBinderDictionary使用。如下面的代码片断所示，ModelBinderDictionary除了具有一个表示基于数据类型的ModelBinder字典（_innerDictionary字段）和一个默认ModelBinder（_defaultBinder）之外，还具有一个ModelBinderProvider列表（_modelBinderProviders字段）。

       1: public class ModelBinderDictionary       2: {       3:     //其他成员       4:     private IModelBinder _defaultBinder;       5:     private readonly Dictionary<Type, IModelBinder> _innerDictionary;       6:     private ModelBinderProviderCollection _modelBinderProviders;          7: }

当ModelBinderDictionary被创建的时候，通过ModelBinderProviders的静态属性BinderProviders表示的ModelBinderProvider列表会用于初始化_modelBinderProviders字段。围绕着ModelBinder的Model绑定系统中的核心组件之间的关系基本上可以通过下图所示的UML来表示。

当我们调用GetBinder或者指定数据类型对应的ModelBinder时，_innerDictionary字段表示的ModelBinder字典会被优先选择。如果数据类型在该字典中找不到，则选择使用通过_modelBinderProviders字段表示的ModelBinderProvider列表进行ModelBinder的提供。只有在两种ModelBinder提供方式均失败的情况下才会选择通过_innerDictionary字段表示的默认ModelBinder。也就是说，如果我们想为某个数据类型定制某种类型的ModelBinder，按照选择优先级具有如下几种方式供我们选择：

将ModelBinderAttribute应用在Action方法的相应参数上并指定相应的ModelBinder类型，或者在参数上应用一个自定义的CustomModelBinderAttribute特性。
将ModelBinderAttribute应用在数据类型上并制定相应的ModelBinder类型，或者在数据类型上应用一个自定义的CustomModelBinderAttribute特性。
通过ModelBinders的静态属性Binders实现针对基于某种数据类型的ModelBinder注册。
自定义ModelBinderProvider实现基于某个数据类型的ModelBinder提供机制，并通过注册当通过ModelBinderProviders的静态属性BinderProviders表示的ModelBinderProvider列表中。

前面三种方式的ModelBinder提供机制我们已经通过实例演示过了，现在我们来演示基于自定义ModelBinderProvider的ModelBinder提供机制。在前面的例子中我们为Foo、Bar和Baz这三种数据类型创建了相应的ModelBinder（FooModelBinder、BarModelBinder和BazModelBinder），现在我们创建如下一个自定义的ModelBinderProvider将两种（数据类型和ModelBinder对象）进行关联。

       1: public class MyModelBinderProvider : IModelBinderProvider       2: {       3:     public IModelBinder GetBinder(Type modelType)       4:     {       5:         if (modelType == typeof(Foo))       6:         {       7:             return new FooModelBinder();       8:         }       9:         if (modelType == typeof(Bar))      10:         {      11:             return new BazModelBinder();      12:         }      13:         if (modelType == typeof(Baz))      14:         {      15:             return new BazModelBinder();      16:         }      17:         return null;      18:     }      19: }

现在我们需要通过利用Global.asax通过如下的方式在应用启动时将一个我们自定义的MyModelBinderProvider注册到通过ModelBinderProviders的静态属性BinderProviders表示的ModelBinderProvider列表中。

       1: public class MvcApplication : System.Web.HttpApplication       2: {       3:     //其他成员       4:     protected void Application_Start()       5:     {       6:         //其他操作       7:        ModelBinderProviders.BinderProviders.Add(new MyModelBinderProvider());       8:     }       9: }

由于MyModelBinderProvider实现了针对Foo、Bar和Baz三种数据类型的ModelBinder的提供，所以我们可以将应用在Action方法参数和数据类型上的ModelBinderAttribute特性删除。再次运行我们的程序，会在浏览器中得到如下的输出结果，从中可以看到DoSomething方法的三个参数此时采用了我们期望的ModelBinder类型。

       1: foo: FooModelBinder       2: bar: BarModelBinder       3: baz: BazModelBinder

本文链接

ASP.NET MVC以ValueProvider为核心的值提供系统: ValueProviderFactory

2012-05-18T23:20:00Z

在ASP.NET Model绑定系统中，用于提供数据值的ValueProvider对象通过ValueProviderFactory来创建。在ASP.NET MVC应用编程接口中，ValueProviderFactory继承自ValueProviderFactory类。本篇文章只要介绍基于ValueProviderFactory的ValueProvider的提供机制，以及如何通过自定义ValueProviderFactory实现我们需要的数据值的绑定方式。[本文已经同步到《How ASP.NET MVC Works?》中]

目录
一、ValueProviderFactory
二、ValueProviderFactory的注册
三、实例演示：创建一个自定义ValueProviderFactory

一、ValueProviderFactory

如下面的代码片断所示，ValueProviderFactory是一个抽象类，唯一的抽象方法GetValueProvider用于实现基于指定Controller上下文的ValueProvider创建。

        1: public abstract class ValueProviderFactory       2: {       3:     public abstract IValueProvider GetValueProvider(ControllerContext controllerContext);       4: }

下面的列表列出了定义在Model绑定系统中的6个原生的ValueProviderFactory：

ChildActionValueProviderFactory：根据给定的Controller上下文创建一个ChildActionValueProvider对象。
FormValueProviderFactory：根据给定的Controller上下文创建一个FormValueProvider对象。
JsonValueProviderFactory：将以JSON形式表示的请求数据转换成一个Dictionary<string, object>对象，并最终创建一个DictionaryValueProvider<object>对象。
RouteDataValueProviderFactory：根据给定的Controller上下文创建一个RouteDataValueProvider对象。
QueryStringValueProviderFactory：根据给定的Controller上下文创建一个QueryStringValueProvider对象。
HttpFileCollectionValueProviderFactory：根据给定的Controller上下文创建一个HttpFileCollectionValueProvider对象。

二、ValueProviderFactory的注册

ValueProviderFactory在ASP.NET MVC应用中的注册通过静态类型ValueProviderFactories实现。如下面的代码片断所示，ValueProviderFactories具有一个静态只读属性Factories返回一个表示ValueProviderFactory集合的ValueProviderFactoryCollection类型。

       1: public static class ValueProviderFactories       2: {       3:     public static ValueProviderFactoryCollection Factories { get; }       4: }       5:         6: public class ValueProviderFactoryCollection : Collection<ValueProviderFactory>       7: {        8:     public ValueProviderFactoryCollection();       9:     public ValueProviderFactoryCollection(IList<ValueProviderFactory> list);          10:     public IValueProvider GetValueProvider(ControllerContext controllerContext);      11: }

ValueProviderFactoryCollection的GetValueProvider方法返回的是一个ValueProviderCollection对象，集合中的每个ValueProvider通过对应的ValueProviderFactory来创建。ValueProviderFactory在ValueProviderFactoryCollection集合中的先后次序决定了创建的ValueProvider在ValueProviderCollection中的次序，而次序决定了使用优先级。

在默认的情况下ValueProviderFactories的Factories属性表示的ValueProviderFactoryCollection包含了上面我们介绍的6种ValueProviderFactory，次序（优先级）为：ChildActionValueProviderFactory、FormValueProviderFactory、JsonValueProviderFactory、RouteDataValueProviderFactory、QueryStringValueProviderFactory和。如果具有相同的名称的请求书去同时存在于请求表单和查询字符串中，前者会被选用。

以ValueProvider为核心的值提供系统中涉及到了三类组件/类型，即用于具体实现数据值提供的ValueProvider，ValueProvider通过ValueProviderFactotry，而ValueProviderFactotry通过ValueProviderFactotries进行注册。图5-4所示的UML体现了三者之间的关系。

三、实例演示：创建一个自定义ValueProviderFactory

ASP.NET MVC提供的6种ValueProviderFactory基本上已经可以满足我们绝大部分Model绑定需求，不过对于一些比较极端的场景，我们有可能需要自定义ValueProviderFactory。作为演示，我们创建一个以HTTP请求报头集合作为数据源的自定义ValueProviderFactory。

我们将自定义的ValueProviderFactory命名为HttpHeaderValueProviderFactory。如下面的代码片断所示，HttpHeaderValueProviderFactory的定义非常简单，在重写的GetValueProvider方法中，我们将针对指定的Controller上下文得到HTTP报头集合，并借此创建NameValueCollection对象。由于作为报头名称具有“-”字符，为了与参数命名规则相匹配，我们将该字符剔除。最终创建的实际上是一个NameValueCollectionValueProvider对象。

       1: public class HttpHeaderValueProviderFactory : ValueProviderFactory       2: {          3:     public override IValueProvider GetValueProvider(ControllerContext controllerContext)       4:     {       5:         NameValueCollection requestData = new NameValueCollection();       6:         var headers = controllerContext.RequestContext.HttpContext.Request.Headers;       7:         foreach (string key in headers.Keys)       8:         {        9:             requestData.Add(key.Replace("-",""),headers[key]);      10:         }      11:         return new NameValueCollectionValueProvider(requestData, CultureInfo.InvariantCulture);      12:     }      13: }

我们通过Visual Studio的ASP.NET MVC项目模板创建一个空Web应用，并创建一个具有如下定义的HomeController。默认的Action方法Index具有一系列的参数，从参数名称我们可以看出它们代表一些常用的HTTP报头。我们最终将代表HTTP报头的参数值呈现出来。

       1: public class HomeController : Controller       2: {              3:     public void Index(string connection, string accept, string  acceptCharset, string acceptEncoding ,string acceptLanguage,        4:         string host, string userAgent)       5:     {       6:         Response.Write(string.Format("{0}: {1}<br/>", "Connection", accept));       7:         Response.Write(string.Format("{0}: {1}<br/>", "Accept-Charset", acceptCharset));       8:         Response.Write(string.Format("{0}: {1}<br/>", "Accept Encoding", acceptEncoding));       9:         Response.Write(string.Format("{0}: {1}<br/>", "Accept-Language", acceptLanguage));      10:         Response.Write(string.Format("{0}: {1}<br/>", "Host", "host"));      11:         Response.Write(string.Format("{0}: {1}<br/>", "User-Agent", userAgent));      12:     }      13: }

然后利用Global.asax中按照如下的方式利用静态类型对我们自定义的HttpHeaderValueProviderFactory进行注册。

       1: public class MvcApplication : System.Web.HttpApplication       2: {         3:     //其他成员       4:     protected void Application_Start()       5:     {       6:         //其他操作       7:         ValueProviderFactories.Factories.Add(new HttpHeaderValueProviderFactory());       8:     }       9: }

当我们运行该程序的时候，会在浏览器中呈现如下的输出结果，而输出的结果正是当前请求的HTTP报头列表。

       1: Connection: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8       2: Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3       3: Accept Encoding: gzip,deflate,sdch       4: Accept-Language: en-US,en;q=0.8       5: Host: host       6: User-Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.19

ASP.NET MVC以ValueProvider为核心的值提供系统: NameValueCollectionValueProvider
ASP.NET MVC以ValueProvider为核心的值提供系统: DictionaryValueProvider
ASP.NET MVC以ValueProvider为核心的值提供系统: ValueProviderFactory

本文链接

ASP.NET MVC以ValueProvider为核心的值提供系统: DictionaryValueProvider

2012-05-18T00:22:00Z

NameValueCollectionValueProvider采用一个NameValueCollection作为数据源，DictionnaryValueProvider的数据源类型自然就是一个Dictionnary。NameValueCollection和Dictionnary都是一个键值对的集合，它们之间的不同之处在NameValueCollection运行元素具有相同的Key，Dictionnary却要求元素的Key具有唯一性。[本文已经同步到《How ASP.NET MVC Works?》中]

目录
一、DictionaryValueProvider<TValue>
二、RouteDataValueProvider
三、HttpFileCollectionValueProvider
四、ChildActionValueProvider
五、实例演示：ChildActionValueProvider的值提供机制
六、ValueProviderCollection

一、DictionaryValueProvider<TValue>

DictionnaryValueProvider的类型全名为System.Web.Mvc.DictionaryValueProvider<TValue>，如下面的代码片断所示，DictionaryValueProvider<TValue>实现了IEnumerableValueProvider和IValueProvider接口，构造函数接受一个IDictionary<string, TValue>对象，该对象表示作为数据源的字典。定义在DictionaryValueProvider<TValue>中所有方法的逻辑与定义在NameValueCollectionValueProvider中的同名方法并没有本质区别。

        1: public class DictionaryValueProvider<TValue> : IEnumerableValueProvider, IValueProvider       2: {       3:     public DictionaryValueProvider(IDictionary<string, TValue> dictionary, CultureInfo culture);       4:     public virtual bool ContainsPrefix(string prefix);       5:     public virtual IDictionary<string, string> GetKeysFromPrefix(string prefix);       6:     public virtual ValueProviderResult GetValue(string key);       7: }

二、RouteDataValueProvider

将当前路由数据作为数据源的RouteDataValueProvider继承自DictionaryValueProvider<TValue>。如下面的代码片断所示，基于当前Controller上下文构建的RouteDataValueProvider直接将表示当前路由数据的RouteData对象的Values属性（这是一个RouteValueDictionary对象）作为数据来源。

       1: public sealed class RouteDataValueProvider : DictionaryValueProvider<object>       2: {       3:     public RouteDataValueProvider(ControllerContext controllerContext) :        4:         base(controllerContext.RouteData.Values, CultureInfo.InvariantCulture)       5:     {       6:     }       7: }

三、HttpFileCollectionValueProvider

我们可以通过类型为file的输入元素进行文件的上传，在表示HTTP请求的HttpRequestBase对象中，上传文件通过只读属性Files表示。从下面的代码片断所示，该属性类型为HttpFileCollectionBase，是一个元素类型为HttpPostedFileBase的集合。

       1: public abstract class HttpRequestBase       2: {          3:     public virtual HttpFileCollectionBase Files { get; }       4: }       5: public abstract class HttpFileCollectionBase : NameObjectCollectionBase, ICollection, IEnumerable       6: {          7:     public virtual string[] AllKeys { get; }       8:     public override int Count { get; }       9:     public virtual HttpPostedFileBase this[int index] { get; }      10:     public virtual HttpPostedFileBase this[string name] { get; }      11: }      12: public abstract class HttpPostedFileBase      13: {      14:     public virtual void SaveAs(string filename);      15:        16:     public virtual int ContentLength { get; }      17:     public virtual string ContentType { get; }      18:     public virtual string FileName { get; }      19:     public virtual Stream InputStream { get; }      20: }

用于处理上传文件的Action方法通常定义类型为HttpPostedFileBase及其列表的参数来表示上传的文件，针对HttpPostedFileBase参数的Model绑定选用的数据就来源于表示当前请求的HttpRequestBase的Files属性，而具体参数值的提供最终通过具有如下定义的HttpFileCollectionValueProvider来实现。

       1: public sealed class HttpFileCollectionValueProvider : DictionaryValueProvider<HttpPostedFileBase[]>       2: {           3:     public HttpFileCollectionValueProvider(ControllerContext controllerContext);       4: }

如上面的代码所示，HttpFileCollectionValueProvider继承自DictionaryValueProvider<TValue>，泛型参数TValue的类型为HttpPostedFileBase数组，这是因为在同一个表单中可以定义多个同名的文件输入元素，所以在以文件元素名称作为Key的字典中，字典元素的值自然就是一个HttpPostedFileBase的列表。

为了让读者对HttpFileCollectionValueProvider采用的针对上传文件的值对象提供机制具有一个深刻的认识，我们来进行一个简单的实例演示。在通过Visual Studio的ASP.NET MVC项目模板创建的空Web应用中创建一个具有如下定义的HomeController。该Controller类型中定义了两个Action方法，默认的Index方法会将默认的View呈现出来，DisplayPostedFiles方法则通过创建的HttpFileCollectionValueProvider对象将上传文件的文件名称呈现出来。

       1: public class HomeController : Controller       2: {       3:     public ActionResult Index()       4:     {       5:         return View();       6:     }       7:     [HttpPost]       8:     public void DisplayPostedFiles()       9:     {      10:         HttpFileCollectionValueProvider valueProvider = new HttpFileCollectionValueProvider(ControllerContext);      11:         IEnumerable<HttpPostedFileBase> foo = (IEnumerable<HttpPostedFileBase>)valueProvider.GetValue("foo").ConvertTo(typeof(IEnumerable<HttpPostedFileBase>));      12:         IEnumerable<HttpPostedFileBase> bar =  (IEnumerable<HttpPostedFileBase>)valueProvider.GetValue("bar").ConvertTo(typeof(IEnumerable<HttpPostedFileBase>));      13:        14:         Response.Write("foo<br/>");      15:         foreach (var file in foo)      16:         {      17:             Response.Write(file.FileName + "<br/>");      18:         }      19:        20:         Response.Write("<br/>bar<br/>");      21:         foreach (var file in bar)      22:         {      23:             Response.Write(file.FileName + "<br/>");      24:         }                  25:     }      26: }

在DisplayPostedFiles方法中，我们针对当前Controller上下文创建HttpFileCollectionValueProvider对象，然后分别将字符“foo”和“bar”作为Key得到两个HttpPostedFileBase对象列表，并将它们的文件名打印出来。下面的代码表示Action方法Index对应的View。在一个针对Action方法DisplayPostedFiles的表单中我们定义了三个文件输入元素，其中前两个名称为“foo”和“bar”。

       1: @{       2:    using(Html.BeginForm("DisplayPostedFiles","Home",        3:        FormMethod.Post,new {enctype="multipart/form-data"}))       4:    {       5:        <ul>       6:         <li>File 1: <input type="file" name="foo"/></li>       7:         <li>File 2: <input type="file"  name="foo"/></li>       8:         <li>File 3: <input type="file"  name="bar"/></li>       9:        </ul>        10:        <input type="submit" value="提交" />             11:     }      12: }

当我们运行该程序的时候，浏览器上会出现一个包含三个文件输入元素和提交按钮的页面。然后我们从本地选择任意三个文件（比如text1.txt、text2.txt和text2.txt）并点击“提交”按钮，界面上会出现如下所示的输出结果。

       1: foo       2: text1.txt       3: text2.txt       4:         5: bar       6: text3.txt

四、ChildActionValueProvider

子Action和普通意义上的Action的不同之处在于它不能用于响应来自客户端的请求，而在某个View中被调用以生成某个部分的HTML。View中针对某个子Action方法的调用通过如下所示的HtmlHelper的扩展方法Action来实现。

       1: public static class ChildActionExtensions       2: {       3:     //其他成员       4:     public static MvcHtmlString Action(this HtmlHelper htmlHelper, string actionName);       5:     public static MvcHtmlString Action(this HtmlHelper htmlHelper, string actionName, object routeValues);       6:     public static MvcHtmlString Action(this HtmlHelper htmlHelper, string actionName, string controllerName);       7:     public static MvcHtmlString Action(this HtmlHelper htmlHelper, string actionName, RouteValueDictionary routeValues);       8:     public static MvcHtmlString Action(this HtmlHelper htmlHelper, string actionName, string controllerName, object routeValues);       9:     public static MvcHtmlString Action(this HtmlHelper htmlHelper, string actionName, string controllerName, RouteValueDictionary routeValues);        10: }

顾名思义，ChildActionValueProvider专门服务于针对子Action方法参数的Model绑定。如下面的代码片断所示，ChildActionValueProvider依然是DictionaryValueProvider<TValue>的继承者，不过这里的泛型参数类型Object。那么在作为数据源的字典中，具体的Key和Value究竟是怎样一个对象呢？

       1: public sealed class ChildActionValueProvider : DictionaryValueProvider<object>       2: {       3:     public ChildActionValueProvider(ControllerContext controllerContext);       4:     public override ValueProviderResult GetValue(string key);       5: }

当我们创建针对指定的Controller上下文创建一个ChildActionValueProvider对象时，会获取描述针对该上下文路由信息的RouteData对象，并将其Values属性表示的RouteValueDictionary对象作为其数据源，这可以从如下所示的ChildActionValueProvider的构造函数定义看出来。

       1: public sealed class ChildActionValueProvider : DictionaryValueProvider<object>       2: {       3:     //其他成员          4:     public ChildActionValueProvider(ControllerContext controllerContext) :  base(controllerContext.RouteData.Values, CultureInfo.InvariantCulture)       5:     {       6:     }       7: }

但是ChildActionValueProvider的GetValue方法获取的值却并不是简单地来源于构造时针对当前上下文的路由信息，不然ChildActionValueProvider就和RouteDataValueProvider没有什么分别了。实际上，ChildActionValueProvider的GetValue方法获取的值来源于调用HtmHelper的扩展方法Action时通过参数routeValues指定的RouteValueDictionary。

现在我们来简单介绍一下定义在ChildActionValueProvider的GetValue方法中的对象值的提供机制。如下面的代码片断所示，ChildActionValueProvider具有一个字符串类型的静态字段_childActionValuesKey。当该类型第一次被加载时，该字段被初始化成一个GUID。

       1: public sealed class ChildActionValueProvider : DictionaryValueProvider<object>       2: {       3:     //其他成员       4:     private static string _childActionValuesKey = Guid.NewGuid().ToString();       5: }

在某个View中通过HtmlHelper的扩展方法Action执行子Action方法时，如果通过参数routeValues指定的RouteValueDictionary不为空，会基于这个对象创建一个DictionaryValueProvider<TValue>对象。然后将这个对象添加到通过routeValues表示的原始的RouteValueDictionary对象中，对应的Key就是ChildActionValueProvider的静态属性_childActionValuesKey表示的GUID。

这个RouteValueDictionary被进一步封装成表示请求上下文的RequestContext对象，目标子Action所在的Controller会在该请求上下文中被激活，而在Controller激活过程中表示Controller上下文的ControllerContext被创建出来，毫无疑问它包含了之前创建的RouteValueDictionary对象。而我们针对当前Controller上下文创建ChildActionValueProvider的时候指定的作为数据源的RouteValueDictionary对象就是这么一个对象。

1: @Html.Action("XxxChildAction", new {Foo=123, Bar = 456, Baz=789})

举个例子，假设我们在某个View中如果如下的方式调用当前Controller的子Action方法 XxxChildAction，并指定相应的路由数据（Foo、Bar和Baz）。最终作为ChildActionValueProvider数据源的Dictionary<string,object>对象结构如下图所示。

当调用ChildActionValueProvider的GetValue方法获取指定Key的值时，实际上并不会直接根据指定的Key去获取对应的值，而是根据通过其静态字段_childActionValuesKey值去获取对应的DictionaryValueProvider<object>对象。然后再调用该对象的GetValue根据指定的Key去获得相应的值。

五、实例演示：ChildActionValueProvider的值提供机制

为了印证上面介绍的关于ChildActionValueProvider的值提供机制，我们来演示一个简单的实例。在进行演示之前有一个点需要作一下简单说明，对于DictionaryValueProvider<TValue>对象来说，最终作为其数据源的通过私有字段_values表示的一个Dictionary<string, ValueProviderResult对象。当我们调用GetValue方法是，只需要根据指定的Key从该字典对象中返回相应的ValueProviderResult即可。

       1: public class DictionaryValueProvider<TValue> : IEnumerableValueProvider, IValueProvider       2: {       3:     //其他成员       4:     private readonly Dictionary<string, ValueProviderResult> _values;       5: }

在通过Visual Studio的ASP.NET MVC 项目模板创建的空Web应用中定义如下一个默认的HomeController。默认的Action方法Index仅仅是将默认的View呈现出来而已，并没有特别之处。在另一个Action方法DisplayRouteData中，我们名称分别为Foo、Bar和Baz的三个路由数据篡改成“abc”、“ijk”和“zyz”。然后根据当前Controller上下文创建一个ChildActionValueProvider对象，并通过反射的方式获取通过它的私有字段_values表示的Dictionary<string, ValueProviderResult对象。

       1: public class HomeController : Controller       2: {       3:     public ActionResult Index()       4:     {       5:         return View();       6:     }       7:         8:     public ActionResult DisplayRouteData()       9:     {      10:         ControllerContext.RouteData.Values["Foo"] = "abc";      11:         ControllerContext.RouteData.Values["Bar"] = "ijk";      12:         ControllerContext.RouteData.Values["Baz"] = "xyz";      13:        14:         StringBuilder sb = new StringBuilder();      15:         ChildActionValueProvider valueProvider = new ChildActionValueProvider(ControllerContext);      16:         FieldInfo valuesField = typeof(DictionaryValueProvider<object>).GetField("_values", BindingFlags.Instance|BindingFlags.NonPublic);      17:         Dictionary<string, ValueProviderResult> values = (Dictionary<string, ValueProviderResult>)valuesField.GetValue(valueProvider);      18:         foreach (string key in values.Keys)      19:         {      20:             sb.Append(string.Format("{0}: {1}<br/>", key, values[key].RawValue));      21:             DictionaryValueProvider<object> innerValueProvider = values[key].RawValue as DictionaryValueProvider<object>;      22:             if (innerValueProvider == null)      23:             {      24:                 continue;      25:             }      26:             sb.Append(string.Format("&nbsp;&nbsp;&nbsp;&nbsp;{0}: {1}<br/>", "Foo", innerValueProvider.GetValue("Foo").RawValue));      27:             sb.Append(string.Format("&nbsp;&nbsp;&nbsp;&nbsp;{0}: {1}<br/>", "Bar", innerValueProvider.GetValue("Bar").RawValue));      28:             sb.Append(string.Format("&nbsp;&nbsp;&nbsp;&nbsp;{0}: {1}<br/>", "Baz", innerValueProvider.GetValue("Baz").RawValue));      29:         }      30:        31:         sb.Append("<br/>ChildActionValueProvider.GetValue()<br/>");      32:         sb.Append(string.Format("{0}: {1}<br/>", "Foo", valueProvider.GetValue("Foo").RawValue));      33:         sb.Append(string.Format("{0}: {1}<br/>", "Bar", valueProvider.GetValue("Bar").RawValue));      34:         sb.Append(string.Format("{0}: {1}<br/>", "Baz", valueProvider.GetValue("Baz").RawValue));                  35:        36:         return Content(sb.ToString());      37:     }      38: }

我们创建一个StringBuilder对象，并将用于输出获取到的Dictionary<string, ValueProviderResult>对象的Key和Value的HTML添加其中。在进行遍历过程中，如果ValueProviderResult对象的RawValue属性是一个DictionaryValueProvider<object>对象，则调用其GetValue方法得到Key分别为Foo、Bar和Baz的值。相应的输出的HTML一并添加到StringBuilder中。

在程序的最后，我们直接调用ChildActionValueProvider的GetValue方法获取针对Foo、Bar和Baz作为Key的值，并将输出Key和Value的HTML添加到StringBuilder中。最终针对生成的HTML字符串返回一个ContentResult对象。如下所示的代码反映Action方法Index对应的View的定义，在这里我们直接调用HtmlHelper的扩展方法Action执行定义在HomeController的Action方法DisplayRouteData，并指定了相应的路由数据（Foo、Bar和Baz）。

1: @Html.Action("DisplayRouteData", new { Foo = 123, Bar = 456, Baz = 789 })

运行我们的程序会在浏览器中得到如下的输出结果。我们可以从中看到针对于Controller和Action名称的路由数据和调用HtmlHelper扩展方法Action指定的数据数据均在作为ChildActionValueProvider数据源的字典对象中。除此之外，还具有一个DictionaryValueProvider<object>对象，对应的Key是一个GUID，这正是我们上面介绍的针对在HtmlHelper扩展方法Action中指定的路由数据创建的DictionaryValueProvider<object>对象，而调用GetValue方法获取到的值最终是通过它提供的。

       1: Foo: abc       2: Bar: ijk       3: Baz: xyz       4: controller: Home       5: action: DisplayRouteData       6: 289594f6-dfba-45b9-8abb-158b4a582911:        7:     System.Web.Mvc.DictionaryValueProvider`1[System.Object]       8:     Foo: 123       9:     Bar: 456      10:     Baz: 789      11:        12: ChildActionValueProvider.GetValue()      13: Foo: 123      14: Bar: 456      15: Baz: 789

六、ValueProviderCollection

类型ValueProviderCollection不仅仅表示一个ValueProvider对象的集合，还作为一个单纯的ValueProvider来使用。如下面的代码片断所示，ValueProviderCollection不仅仅继承自Collection<IValueProvider>，还同时实现了IValueProvider、IEnumerableValueProvider和IUnvalidatedValueProvider三个接口。

       1: public class ValueProviderCollection : Collection<IValueProvider>, IUnvalidatedValueProvider, IEnumerableValueProvider, IValueProvider       2: {       3:     public ValueProviderCollection();       4:     public ValueProviderCollection(IList<IValueProvider> list);       5:         6:     public virtual bool ContainsPrefix(string prefix);       7:     public virtual IDictionary<string, string> GetKeysFromPrefix(string prefix);         8:     public virtual ValueProviderResult GetValue(string key);       9:     public virtual ValueProviderResult GetValue(string key, bool skipValidation);         10: }

对于两个实现值提供机制的GetValue方法重载来说，ValueProviderCollection会遍历集合直到找到一个GetValue方法返回值不为Null的ValueProvider，而该返回值就是该方法的返回值。如果所有ValueProvider的GetValue方法均返回Null，则ValueProviderCollection的GetValue方法也为Null。也就是说，ValueProvider在集合中的先后次序决定了其使用优先级。

如果有任何一个ValueProvider的ContainsPrefix方法返回True，则ValueProviderCollection的ContainsPrefix也返回True。GetKeysFromPrefix方法的逻辑与GetValue方法类似，它会遍历作为集合中实现了IEnumerableValueProvider接口的所有ValueProvider对象，并将指定的前缀作为参数调用ContainsPrefix方法，如果返回值为True，则直接返回GetKeysFromPrefix方法的结果；否则返回一个空的Dictionary<string, string>对象。

本文链接

ASP.NET MVC以ValueProvider为核心的值提供系统: NameValueCollectionValueProvider

2012-05-17T01:04:00Z

在进行Model绑定过程中，需要根据基于Action方法参数的绑定上下文从请求数据中提取相应的数据以提供相应的数据。具体来说，Model绑定的数据具有多个来源，可能来源于Post的表单或者JSON字符串，或者来源于当前的路由数据，也可能来源于请求地址的插叙字符串。ASP.NET MVC将这种基于不同数据来源的数据获取/提供机制实现在一个叫做ValueProvider的组件中。[本文已经同步到《How ASP.NET MVC Works?》中]

目录
一、IValueProvider与ValueProviderResult
二、NameValueCollectionValueProvider
三、两种前缀形式
四、实例演示：返回指定前缀的Key
五、FormValueProvider与QueryStringValueProvider

一、IValueProvider与ValueProviderResult

一般来讲，一个ValueProvider采用的数据源是一个字典类型的数据结构，我们通过它从这个字典中获取一个Key与当前绑定上下文匹配的值。ValueProvider实现了具有如下定义的接口IValueProvider，GetValue方法根据指定的Key从数据源中获取对应的值对象，这个Key是基于当前绑定上下文的。这个Key和存在于数据源中对应数据条目的Key可能并非完全一致，后者可能在前者基础上添加相应的前缀，而ContainsPrefix方法用于判断数据源字典的Key是否具有指定的前缀。

        1: public interface IValueProvider       2: {       3:     bool ContainsPrefix(string prefix);       4:     ValueProviderResult GetValue(string key);       5: }

IValueProvider的GetValue返回的是一个ValueProviderResult对象，我们可以将ValueProviderResult看成是对ValueProvider提供对象的封装。如下面的代码片断所示，ValueProviderResult具有三个只读属性，其中RawValue表示原始的值对象。而AttemptedValue表示以值对象的字符串表示，该属性主要用于显示。

       1: [Serializable]       2: public class ValueProviderResult       3: {           4:     public ValueProviderResult(object rawValue, string attemptedValue, CultureInfo culture);           5:     public object ConvertTo(Type type);       6:     public virtual object ConvertTo(Type type, CultureInfo culture);       7:         8:     public string AttemptedValue { get; }       9:     public CultureInfo Culture { get; }      10:     public object RawValue { get; }      11: }

ValueProviderResult提供了两个ConvertTo方法重载以实现向指定目标类型的转换。某些类型的格式化行为依赖于相应的语言文化（比如时间、日期和货币等），而这个辅助格式湖的语言文化信息通过Culture属性表示。其中第一个ValueProviderResult方法重载通过属性Culture表示的语言文化进行类型转化。

二、NameValueCollectionValueProvider

前面已经说过，Model数据源一般具有类似于字典的结构，而NameValueCollection可以表示为Key不具有唯一性的字典，将NameValueCollection对象作为数据源的ValueProvider通过具有如下定义的NameValueCollectionValueProvider类型表示。表示数据源的NameValueCollection对象在构造函数中指定，构造函数的另一个CultureInfo类型的参数表示服务于数据转换的语言文化信息。

       1: public class NameValueCollectionValueProvider : IUnvalidatedValueProvider, IEnumerableValueProvider, IValueProvider       2: {          3:     //其他成员       4:     public NameValueCollectionValueProvider(NameValueCollection collection,  CultureInfo culture);       5:         6:     public virtual bool ContainsPrefix(string prefix);       7:     public virtual IDictionary<string, string> GetKeysFromPrefix(string prefix);       8:     public virtual ValueProviderResult GetValue(string key);       9:     public virtual ValueProviderResult GetValue(string key, bool skipValidation);        10: }      11:        12: public interface IEnumerableValueProvider : IValueProvider      13: {      14:     IDictionary<string, string> GetKeysFromPrefix(string prefix);      15: }      16:        17: public interface IUnvalidatedValueProvider : IValueProvider      18: {      19:     ValueProviderResult GetValue(string key, bool skipValidation);      20: }

从上面的代码片断我们可以看到，除了IValueProvider接口，NameValueCollectionValueProvider还实现了IEnumerableValueProvider和IUnvalidatedValueProvider两个接口。顾名思义，IEnumerableValueProvider主要用于针对目标类型为集合的数据提供，方法GetKeysFromPrefix以一字典的形式返回具有指定前缀的Key。在默认的情况下，在进行数据提供的同时会对数据进行验证，而IUnvalidatedValueProvider接口提供了一个额外的GetValue方法是我们可以忽略对数据的验证。

三、两种前缀形式

辅助实现Model绑定的数据提供机制是以Model元数据为基础的，通过《初识Model元数据》我们知道用于描述一个复杂数据类型的Model元数据具有一个树型的层次化结构，而作为数据源的NameValueCollection却是一个“扁平”的结构，两者之前的匹配通过前缀来表示。举个简单的例子，假设通过NameValueCollectionValueProvider提供对象的目标类型为具有如下定义的Contact。表示联系地址的属性是一个复杂类型Address，所以针对Contact类型的Model元数据树具有两个层级。

       1: public class Contact       2: {       3:     public string Name { get; set; }       4:     public string PhoneNo { get; set; }       5:     public string EmailAddress { get; set; }       6:     public Address Address { get; set; }       7: }       8: public class Address       9: {      10:     public string Province { get; set; }      11:     public string City { get; set; }      12:     public string District { get; set; }      13:     public string Street { get; set; }      14: }

由于NameValueCollection中每个元数据的值都是一个字符串，所以不可能单独表示一个复杂类型，复杂类型对象需要通过多个元素值组装而成。如果通过NameValueCollectionValueProvider来初始化一个完整的Contact对象，表示数据源的NameValueCollection至少需要包含7个元素，分别针对Contact除Address属性的三个属性值和作为Address的四个属性值，两类元素在NameValueCollection中通过基于属性的前缀来区分，具体的结构如下所示。

       1: Name:Foo       2: PhoneNo:123456789       3: EmailAddress:Foomail.com       4: Address.Province: 江苏       5: Address.City: 苏州       6: Address.District: 工业园区       7: Address.Street: 星湖街328号

将点号(.)作为分隔符的前缀除了表示基于属性的层级关系之外，还可以用于数据筛选。如下面的代码片断所示，我们在ContactController中定义了一个用于添加联系人的AddContacts，它具有两个Contact类型的参数foo和bar，表示添加的两个不同的联系人。

       1: public class ContactController       2: {       3:     public void AddContacts(Contact foo, Contact bar)       4:     {        5:         //省略实现       6:     }       7: }

如果我们采用NameValueCollectionValueProvider来提供作为AddContacts方法参数的两个Contact对象，保存在NameValueCollection的数据元素必须能够与它们进行合理映射。一般情况下这可以通过针对参数名的前缀来实现，具体数据结构如下所示。

       1: foo.Name：Foo       2: foo.PhoneNo：123456789       3: foo.EmailAddress：Foo@gmail.com       4: foo.Address.Province: 江苏       5: foo.Address.City: 苏州       6: foo.Address.District: 工业园区       7: foo.Address.Street: 星湖街328号       8:         9: bar.Name：Bar      10: bar.PhoneNo：987654321      11: bar.EmailAddress：Bar@gmail.com      12: bar.Address.Province: 江苏      13: bar.Address.City: 苏州      14: bar.Address.District: 工业园区      15: bar.Address.Street: 机场路328号

除了采用基于“.”的前缀之外，数组或者集合类型的数据源元素可以采用基于“索引”的前缀，这样的前缀通过方括号“[]”表示，如下的数据结构就可以表示包含两个元素的Contact数组或者集合。

       1: [0].Name：Foo       2: [0].PhoneNo：123456789       3: [0].EmailAddress：Foo@gmail.com       4: ...       5: [1].Name：Bar       6: [1].PhoneNo：987654321       7: [1].EmailAddress：Bar@gmail.com       8: ...       9:  

除了采用数字作为索引之前，我们还可以按照如下的方式通过文字作为索引。针对两种不同形式的索引的Model绑定机制有所不同，我们会在后续的部分予以讲述。

       1: [foo].Name：Foo       2: [foo].PhoneNo：123456789       3: [foo].EmailAddress：Foo@gmail.com       4: ...       5: [bar].Name：Bar       6: [bar].PhoneNo：987654321       7: [bar].EmailAddress：Bar@gmail.com       8: ...

如果数据源元素针对不同的目标集合对象，同样需要采用相应的前缀予以区分，相面的数据结构可以看成是针对两个Contact列表（first和second）的数据源。

       1: first[0].Name：Zhao       2: first[0].PhoneNo：12       3: first[0].EmailAddress：zhao @gmail.com       4: ...       5: first[1].Name：Qian       6: first[1].PhoneNo：34       7: first[1].EmailAddress：qian@gmail.com       8: ...       9:        10: second[0].Name：Sun      11: second[0].PhoneNo：56      12: second[0].EmailAddress：sun@gmail.com      13: ...      14: second[1].Name：Li      15: second[1].PhoneNo：78      16: second[1].EmailAddress：li@gmail.com

四、实例演示：返回指定前缀的Key

在了解两种不同类型的前缀之后，我们来关注一下NameValueCollectionValueProvider实现的GetKeysFromPrefix方法。从该方法的定义可以看出它返回的是一个IDictionary<string, string>对象，但是这个对象具有怎样的数据呢？我们为此来进行一个实例演示。在通过Visual Studio的ASP.NET MVC项目模板创建的空Web应用中，我们定义了如下一个默认的HomeController。在Action方法Index中我们创建了一个NameValueCollection对象，并针对它创建一个NameValueCollectionValueProvider．

       1: public class HomeController : Controller       2: {       3:     public void Index()       4:     {       5:         NameValueCollection datasource = new NameValueCollection();       6:         datasource.Add("foo.Name", "Foo");       7:         datasource.Add("foo.PhoneNo", "123456789");       8:         datasource.Add("foo.EmailAddress", "Foo@gmail.com");       9:         datasource.Add("foo.Address.Province", "江苏");      10:         datasource.Add("foo.Address.City", "苏州");      11:         datasource.Add("foo.Address.District", "工业园区");      12:         datasource.Add("foo.Address.Street", "星湖街328号");      13:         NameValueCollectionValueProvider valueProvider = new NameValueCollectionValueProvider(datasource, CultureInfo.InvariantCulture);      14:        15:         var keyDictionary = valueProvider.GetKeysFromPrefix("foo");      16:         Response.Write("foo<br/>");      17:         foreach (var item in keyDictionary)      18:         {      19:             Response.Write(string.Format("{0}: {1}<br/>", item.Key, item.Value));      20:         }      21:        22:         keyDictionary = valueProvider.GetKeysFromPrefix("foo.Address");      23:         Response.Write("<br/>foo.Address<br/>");      24:         foreach (var item in keyDictionary)      25:         {      26:             Response.Write(string.Format("{0}: {1}<br/>", item.Key, item.Value));      27:         }      28:     }      29: }

通过上面的代码片断可以看出，作为NameValueCollectionValueProvider的数据元素是按照Contact类型的属性定义来添加的。我们分别将“foo”和“foo.Address”作为前缀返回以此作为前缀的Key。运行该程序后会在浏览器上得到如下的输出结果。我们可以看到对于针对指定前缀返回的字典对象，其Key和Value的不同之处在于前者没有包含指定的前缀而后者包含。此外，字典对象包含的元素全部处于同一级别，将“foo”指定为前缀时返回的元素针对于Contact的四个属性。虽然NameValueCollection中并不包含一个名为“foo.Address”的元素，但是依然会将其单独作为以“foo”为前缀的Key。

       1: foo       2: Name            : foo.Name       3: PhoneNo         : foo.PhoneNo       4: EmailAddress    : foo.EmailAddress       5: Address         : foo.Address       6:         7: foo.Address       8: Province        : foo.Address.Province       9: City            : foo.Address.City      10: District        : foo.Address.District      11: Street          : foo.Address.Street

接下来我们采用相应的方式来演示基于索引的前缀，为此我们将HomeController的Index反方法进行了如下的改写。作为数据源的NameValueCollection对象针对一个包含两个元素的Contact集合，前缀“first”可以作为集合对象的名称。

       1: public class HomeController : Controller       2: {       3:     public void Index()       4:     {       5:         NameValueCollection datasource = new NameValueCollection();       6:         datasource.Add("first[0].Name", "Foo");       7:         datasource.Add("first[0].PhoneNo", "123456789");       8:         datasource.Add("first[0].EmailAddress", "Foo@gmail.com");       9:        10:         datasource.Add("first[1].Name", "Bar");      11:         datasource.Add("first[1].PhoneNo", "987654321");      12:         datasource.Add("first[1].EmailAddress", "Bar@gmail.com");      13:         NameValueCollectionValueProvider valueProvider = new NameValueCollectionValueProvider(datasource, CultureInfo.InvariantCulture);      14:        15:         var keyDictionary = valueProvider.GetKeysFromPrefix("first");      16:         Response.Write("first<br/>");      17:         foreach (var item in keyDictionary)      18:         {      19:             Response.Write(string.Format("{0}: {1}<br/>", item.Key, item.Value));      20:         }      21:        22:         keyDictionary = valueProvider.GetKeysFromPrefix("first[0]");      23:         Response.Write("<br/>first[0]<br/>");      24:         foreach (var item in keyDictionary)      25:         {      26:             Response.Write(string.Format("{0}: {1}<br/>", item.Key, item.Value));      27:         }      28:        29:         keyDictionary = valueProvider.GetKeysFromPrefix("first[1]");      30:         Response.Write("<br/>first[1]<br/>");      31:         foreach (var item in keyDictionary)      32:         {      33:             Response.Write(string.Format("{0}: {1}<br/>", item.Key, item.Value));      34:         }      35:     }      36: }

我们分别针对三个前缀“first”、“first[0]”和“first[1]”获取相应字典对象并将其Key和Value呈现出来。该程序执行之后会在浏览器中产生如下的输出，如果我们将“[”和“]”视为和”.”一样的分割符，GetKeysFromPrefix针对索引作为前缀的规则与基于“.”前缀的规则没有本质的区别。

       1: first       2: 0: first[0]       3: 1: first[1]       4:         5: first[0]       6: Name        : first[0].Name       7: PhoneNo     : first[0].PhoneNo       8: EmailAddress: first[0].EmailAddress       9:        10: first[1]      11: Name        : first[1].Name      12: PhoneNo     : first[1].PhoneNo      13: EmailAddress: first[1].EmailAddress

五、FormValueProvider与QueryStringValueProvider

在ASP.NET MVC 应用编程接口中，NameValueCollectionValueProvider具有两个继承者，即FormValueProvider和QueryStringValueProvider。对于FormValueProvider来说，最终作为数据源的NameValueCollection对象通过请求表单创建，Name和Value分别来源于表单元素的名称和值，它的定义基本上可以通过如下的代码表示（实际定义有所差异）。

       1: public sealed class FormValueProvider : NameValueCollectionValueProvider       2: {       3:     public FormValueProvider(ControllerContext controllerContext)       4:         : base(controllerContext.RequestContext.HttpContext.Request.Form, CultureInfo.CurrentCulture)       5:     { }       6: }

对于QueryStringValueProvider来说，无须多说，其作为数据源的NameValueCollection对象爱那个自然来源于请求的查询字符串，其定义基本上可以通过如下的代码表示（实际定义有所差异）。

       1: public sealed class QueryStringValueProvider: NameValueCollectionValueProvider       2: {       3:     public NameValueCollection(ControllerContext controllerContext)       4:         : base(controllerContext.RequestContext.HttpContext.Request.QueryString, CultureInfo.CurrentCulture)       5:     { }       6: }

本文链接

ASP.NET MVC如何实现自定义验证（服务端验证+客户端验证）

2012-05-15T10:37:00Z

ASP.NET MVC通过Model验证帮助我们很容易的实现对数据的验证，在默认的情况下，基于ValidationAttribute的声明是验证被使用，我们只需要将相应的ValidationAttribute应用到Model的类型或者属性上即可。对于自定义验证，我们也只需要定义相应的Validation就可以了，不过服务端验证比较简单，而客户端验证就要稍微复杂一些，本文提供一个简单的实例说明在ASP.NET MVC中实现自定义验证的基本步骤。[源代码从这里下载]

一、AgeRangeAttribute

用于验证出生日期字段以确保年龄在制定的范围之内的AgeRangeAttribute定义如下，简单起见，我们直接让它直接继承自RangeAttribute。服务端验证逻辑定义在重写的IsValid方法中，并且重写了FormatErrorMessage方法以便生成针对年龄的验证消息。AgeRangeAttribute实现了IClientValidatable接口，并在实现的GetClientValidationRules方法中生成客户端验证规则。在生成的类型为“agerange”的ModelClientValidationRule 对象中包含三个参数（currentdate、minage和maxage），分别表示当前日期（用于计算年龄）、允许年龄的范围。

        1: public class AgeRangeAttribute : RangeAttribute, IClientValidatable       2: {       3:     public AgeRangeAttribute(int minimum, int maximum)       4:         : base(minimum, maximum)       5:     { }       6:         7:     public override bool IsValid(object value)       8:     {       9:         DateTime birthDate = (DateTime)value;      10:         DateTime age = new DateTime(DateTime.Now.Ticks - birthDate.Ticks);      11:         return age.Year >= (int)this.Minimum && age.Year <= (int)this.Maximum;      12:     }      13:        14:     public override string FormatErrorMessage(string name)      15:     {      16:         return base.FormatErrorMessage("年龄");      17:     }      18:        19:     public IEnumerable<ModelClientValidationRule> GetClientValidationRules(ModelMetadata metadata, ControllerContext context)      20:     {      21:         ModelClientValidationRule validationRule = new ModelClientValidationRule(){ ValidationType = "agerange", ErrorMessage= FormatErrorMessage(metadata.DisplayName)};      22:         validationRule.ValidationParameters.Add("currentdate",DateTime.Today.ToString("dd-MM-yyyy"));      23:         validationRule.ValidationParameters.Add("minage",this.Minimum);      24:         validationRule.ValidationParameters.Add("maxage",this.Maximum);      25:         yield return validationRule;      26:     }      27: }

二、注册客户端验证方法

由于ASP.NET MVC采用JQuery Validation进行客户端验证，我们可以通过如下的这段javascript来注册用于实现客户端验证的function和添加相应的adapter。添加到jQuery.validator的用于进行年龄范围验证的function具有三个参数（value、element、params）分别表示被验证的值、元素和传入的参数。验证逻辑必须的三个数值（当前日期、年龄范围最小和最大值）通过参数params获得。而该参数实际上是在添加adapter时从通过上面定义的GetClientValidationRules方法生成的验证规则中获取的。

       1: jQuery.validator.addMethod("agerange",       2: function (value, element, params) {       3:            4:     var minAge = params.minage;       5:     var maxAge = params.maxage;       6:         7:     var literalCurrentDate = params.currentdate;       8:     var literalBirthDate = value;       9:     var literalCurrentDates = literalCurrentDate.split('-');      10:     var literalBirthDates = literalBirthDate.split('-');      11:        12:     var birthDate = new Date(literalBirthDates[2], literalBirthDates[1], literalBirthDates[0]);      13:     var currentDate = new Date(literalCurrentDates[2], literalCurrentDates[1], literalCurrentDates[0]);      14:     var age = currentDate.getFullYear() - birthDate.getFullYear();      15:     return age >= minAge && age <= maxAge      16: });      17:        18: jQuery.validator.unobtrusive.adapters.add("agerange", ["currentdate", "minage", "maxage"], function (options) {      19:     options.rules["agerange"] = {      20:         currentdate: options.params.currentdate,      21:         minage: options.params.minage,      22:         maxage: options.params.maxage      23:     };      24:     options.messages["agerange"] = options.message;      25: });

三、AgeRangeAttribute的应用

现在我们将AgeRangeAttribute 应用到一个简单的ASP.NET MVC应用中。在通过VS的ASP.NET MVC项目模板创建的空Web应用中，我们定义了如下一个简单的Person类型，我们定义的AgeRangeAttribute 应用到了表示出生日期的BirthDate上，并将允许的年龄上、下限设置为１８和３０。

       1: public class Person       2: {       3:     [DisplayName("姓名")]       4:     public string Name { get; set; }       5:         6:     [AgeRange(18, 30, ErrorMessage = "{0}必须在{1}和{2}之间！")]          7:     [DisplayName("出生日期")]       8:     [DisplayFormat(ApplyFormatInEditMode = true, DataFormatString = "{0:dd-MM-yyyy}")]       9:     public DateTime? BirthDate { get; set; }      10: }

然后我们添加如下一个HomeController，在默认的Action方法Index中我们将创建的Person对象呈现在默认的View中。

       1: public class HomeController : Controller       2: {       3:     public ActionResult Index()       4:     {       5:         return View(new Person{ BirthDate = DateTime.Today, Name = "Foo"});       6:     }       7:     [HttpPost]       8:     public ActionResult Index(Person person)       9:     {      10:         return View(person);      11:     }      12: }

如下所示的代码片断代表了View的定义，我们直接调用HtmlHelper<TModel>的扩展方法EditorModel将作为Model的Person对象以编辑模式呈现在一个表单中。最后一点不要忘了在Layout文件中讲包含上述javascript片断的js文件包含进来。

       1: @model Person       2: @using (Html.BeginForm())       3: {            4:     @Html.EditorForModel()       5:     <input type="submit" value="Save" />       6: }

运行我们的程序，输入不合法出生日期并点击”Save”按钮提交表单（针对第一次客户端验证），客户端验证将会生效，具体效果如下图所示。

本文链接

通过ASP.NET Web API + JQuery创建一个简单的Web应用

2012-05-13T23:50:00Z

看了dudu的《HttpClient + ASP.NET Web API, WCF之外的另一个选择》一文，想起多很久之前体现ASP.NET Web API而创建的一个Demo。这是一个只涉及到简单CRUD操作的Web应用，业务逻辑以Web API的形式定义并以服务的形式发布出来，前台通过jQuery处理用户交互并调用后台服务。[源代码从这里下载]

目录
一、一个简单的基于CRUD
二、通过ASP.NET Web API提供服务
三、通过JQuery消费服务

一、一个简单的基于CRUD的Web应用

这个简单的Demo应用用于模拟“联系人管理”。当页面加载的时候，所有的联系人列表被列出来。在同一个页面中，我们可以添加一个新的联系人，也可以修改和删除现有联系人信息。整个应用唯一的页面在浏览器中的呈现效果如下图所示。

二、通过ASP.NET Web API提供服务

我们来简单介绍作为Web API形式发布的联系人管理服务的定义，先来看看用于表示联系人的Contact类型的定义。

        1: public class Contact       2: {       3:     public string Id { get; set; }       4:     public string FirstName { get; set; }       5:     public string LastName { get; set; }       6:     public string PhoneNo { get; set; }       7:     public string EmailAddress { get; set; }       8: }

“联系人服务”以具有如下定义的ContactController的形式定义，它是ApiController的子类。简单起见，我们采用静态字段作为对联系人信息的存储。ContactController定义了Get、Put、Post和Delete用于进行对联系人的获取、添加、修改和删除操作。我想对Web API不了解的人会感概，为了什么采用常用的四个HTTP方法作为操作的名称，因为它们在默认的情况下就可以映射为HTTP请求的方法。

       1: public class ContactController : ApiController       2: {       3:     private static List<Contact> contacts = new List<Contact>       4:     {       5:         new Contact{ Id="001", FirstName = "San", LastName="Zhang", PhoneNo="123", EmailAddress="zhangsan@gmail.com"},       6:         new Contact{ Id="002",FirstName = "Si", LastName="Li", PhoneNo="456", EmailAddress="lisi@gmail.com"}       7:     };       8:                9:     public IEnumerable<Contact> Get()      10:     {      11:         return contacts;      12:     }      13:        14:     public Contact Get(string id)      15:     {      16:         return contacts.FirstOrDefault(c => c.Id == id);      17:     }      18:        19:     public void Put(Contact contact)      20:     {      21:         if (string.IsNullOrEmpty(contact.Id))      22:         {      23:             contact.Id = Guid.NewGuid().ToString();      24:         }      25:         contacts.Add(contact);      26:     }      27:        28:     public void Post(Contact contact)      29:     {      30:         Delete(contact.Id);      31:         contacts.Add(contact);      32:     }      33:        34:     public void Delete(string id)      35:     {      36:         Contact contact = contacts.FirstOrDefault(c => c.Id == id);      37:         contacts.Remove(contact);      38:     }      39: }

和ASP.NET MVC Web应用一样，我们同样采用URL路由机制来实现请求地址与目标Controller和Action的映射，而针对API默认注册的路有如下所示。

       1: public class MvcApplication : System.Web.HttpApplication       2: {       3:     //...       4:     public static void RegisterRoutes(RouteCollection routes)       5:     {       6:          //...       7:         routes.MapHttpRoute(       8:             name: "DefaultApi",       9:             routeTemplate: "api/{controller}/{id}",      10:             defaults: new { id = RouteParameter.Optional }      11:         );      12: }

按照注册的路由规则和Action方法名称与HTTP方法的默认影射机制，我们可以直接在浏览器中分别访问地址“/api/contact”和“/api/contact/001”得到所有联系人列表和ID为“001”的联系人信息。得到的结果如下图所示。

三、通过JQuery消费服务

我们通过ASP.NET MVC来构建Web应用，默认的HomeController定义如下，默认的Index操作仅仅是将默认的View呈现出来而已。

       1: public class HomeController : Controller       2: {       3:     public ActionResult Index()       4:     {       5:         return View();       6:     }       7: }

View中对用户操作的相应和对后台服务的调用都通过JQuery来完成，整个View的定义如下所示。

1: <script type="text/javascript">

   1:     2:     $(function () {   3:         loadAllContacts();   4:        }   5:      )   6:     7:     function loadAllContacts() {   8:         $.ajax({   9:             url     : "api/contact",  10:             type    : "GET",  11:             dataType: "json",  12:             success : function (data) { renderContactList(data) }  13:            }  14:         );          15:     }  16:    17:     function renderContactList(contacts) {  18:         var html = "<table>";  19:         html += "<tr><th>First Name</th><th>Last Name</th><th>Phone No.</th><th>Email Address</th><th></th></tr>";  20:         for (i = 0; i < contacts.length; i++) {  21:             html += "<tr><td>" + contacts[i].FirstName + "</td><td>"  22:                  + contacts[i].LastName + "</td><td>" + contacts[i].PhoneNo + "</td><td>"  23:                  + "<input type=\"text\" class=\"textbox long\" id=\"" + contacts[i].Id + "\" value =\"" + contacts[i].EmailAddress + "\"/>" + "</td><td>"  24:                  + "<a href=\"#\" onclick = \"updateContact('" + contacts[i].Id + "')\">Update</a> &nbsp;&nbsp;&nbsp;&nbsp;"  25:                  + "<a href=\"#\" onclick = \"deleteContact('" + contacts[i].Id + "')\">Delete</a>" + "</td></tr>";  26:         }  27:         html += "<tr><td>" + "<input id=\"firstName\" type=\"text\" class=\"textbox\"/>" + "</td><td>"  28:             + "<input id=\"lastName\" type=\"text\" class=\"textbox\"/>" + "</td><td>"  29:             + "<input id=\"phoneNo\" type=\"text\" class=\"textbox\"/>" + "</td><td>"  30:             + "<input id=\"emailAddress\" type=\"text\" class=\"textbox long\"/>" + "</td><td>"   31:             + "<a href=\"#\" id=\"add\" onclick=\"addContact();\">Create</a> " + "</td></tr>";  32:         html += "</table>";  33:         $("#contacts").html(html);  34:         $("table tr:odd").addClass("oddRow");  35:     }  36:    37:     function deleteContact(id) {  38:         $.ajax({  39:             url     : "api/contact/" + id,  40:             type    : "DELETE",  41:             success : function () { loadAllContacts();}  42:         });  43:     }  44:    45:     function updateContact(id) {  46:         var emailAddress = $("#" +id).attr("value");  47:         $.ajax({  48:             url     : "api/contact/" + id,  49:             type    : "GET",  50:             success : function (contact) {  51:                 contact.EmailAddress = emailAddress;  52:                 update(contact);  53:             }  54:         });  55:     }  56:    57:     function update(contact) {  58:         $.ajax({  59:             url         : "api/contact/",  60:             type        : "POST",  61:             data        : contact,  62:             contentType : "application/json",  63:             success     : function () { loadAllContacts(); }  64:         });  65:     }  66:    67:     function addContact() {  68:         var contact = new Object();  69:         contact.FirstName       = $("#firstName").attr("value");  70:         contact.LastName        = $("#lastName").attr("value");  71:         contact.PhoneNo         = $("#phoneNo").attr("value");  72:         contact.EmailAddress    = $("#emailAddress").attr("value");  73:         $.ajax({  74:             url         : "api/contact/",  75:             type        : "PUT",  76:             data        : contact,  77:             contentType : "application/json",  78:             success     : function () { loadAllContacts(); }  79:         });  80:     }</script>

2: <div id="contacts"></div>

本文链接

ASP.NET MVC三个重要的描述对象：ParameterDescriptor

2012-05-13T10:37:00Z

Model绑定是为作为目标Action的方法准备参数列表的过程，所以针对参数的描述才是Model绑定的核心。在ASP.NET MVC应用编程接口中，服务于Model绑定的参数元数据通过ParameterDescriptor类型来表示，而ActionDescriptor的GetParameters方法返回的就是一个ParameterDescriptor数组。

如下面的代码片断所示，ParameterDescriptor同样实现了ICustomAttributeProvider接口提供应用在相应参数上的特性。ParameterDescriptor的只读属性ActionDescriptor表示描述所在Action方法的ActionDescriptor对象。属性ParameterName、ParameterType和DefaultValue分别表示参数的名称、类型和默认值。

        1: public abstract class ParameterDescriptor : ICustomAttributeProvider       2: {          3:     public virtual object[] GetCustomAttributes(bool inherit);       4:     public virtual object[] GetCustomAttributes(Type attributeType, bool inherit);       5:     public virtual bool IsDefined(Type attributeType, bool inherit);       6:            7:     public abstract ActionDescriptor ActionDescriptor { get; }       8:     public abstract string ParameterName { get; }       9:     public abstract Type ParameterType { get; }      10:     public virtual object DefaultValue { get; }      11:        12:     public virtual ParameterBindingInfo BindingInfo { get; }      13: }

ParameterDescriptor的只读属性BindingInfo表示的System.Web.Mvc.ParameterBindingInfo对象封装一些信息用于控制请求数据与参数的绑定行为。如下面的代码片断所示，抽象类ParameterBindingInfo具有四个属性，其中类型为IModelBinder的Binder属性返回的ModelBinder对象是整个Model绑定的核心，我们将在本章后续部分进行单独介绍。

       1: public abstract class ParameterBindingInfo       2: {       3:     public virtual IModelBinder Binder { get; }       4:            5:     public virtual ICollection<string> Include { get; }       6:     public virtual ICollection<string> Exclude { get; }       7:     public virtual string Prefix { get; }       8: }

如果参数类型是一个复杂类型，默认情况下会绑定其所有公共可读写属性，而两个ICollection<string>类型的属性Include和Exclude表示显示设置的参与/不参与绑定的属性名称列表。在默认情况下，请求数据与参数之间严格按照名称进行绑定，但是有时候请求数据名称具有相应的前缀，这个前缀体现在ParameterBindingInfo的Prefix属性上。

ReflectedParameterDescriptor

原生的ParameterBindingInfo是通过针对表示参数的ParameterInfo进行反射获得，这样的ParameterBindingInfo通过ReflectedParameterDescriptor类型表示。如下面的代码片断所示，这个ParameterInfo对象通过只读属性ParameterInfo表示，并在构造函数中被初始化。

       1: public class ReflectedParameterDescriptor : ParameterDescriptor       2: {          3:     public ReflectedParameterDescriptor(ParameterInfo parameterInfo, ActionDescriptor actionDescriptor);       4:     public override object[] GetCustomAttributes(bool inherit);       5:     public override object[] GetCustomAttributes(Type attributeType, bool inherit);       6:     public override bool IsDefined(Type attributeType, bool inherit);       7:            8:     public override ActionDescriptor ActionDescriptor { get; }       9:     public override ParameterBindingInfo BindingInfo { get; }      10:     public override object DefaultValue { get; }      11:     public override string ParameterName { get; }      12:     public override Type ParameterType { get; }      13:           14:     public ParameterInfo ParameterInfo { get; }      15: }

ReflectedParameterDescriptor的BindingInfo属性返回的是一个ReflectedParameterBindingInfo对象，这是一个内部类型。该BindingInfo的Include、Exclude和Prefix属性来源于对应用在参数上的BindAttribute特性的解析。如下面的代码片断所示，BindAttribute中同样定义了这三个属性，其中Include和Exclude为通过逗号作为分隔符的属性名称列表。

       1: [AttributeUsage(AttributeTargets.Parameter | AttributeTargets.Class, AllowMultiple=false, Inherited=true)]       2: public sealed class BindAttribute : Attribute       3: {       4:     public bool IsPropertyAllowed(string propertyName);          5:            6:     public string Include { get; set; }       7:     public string Exclude { get; set; }       8:     public string Prefix { get; set;}       9: }

布尔返回类型的IsPropertyAllowed方法用于判断指定的属性是否允许绑定，当指定在属性名在Include列表中（或者Include列表为空）并且不在Exclude列表的情况下返回True，否则返回False。

ASP.NET MVC三个重要的描述对象：ControllerDescriptor
ASP.NET MVC三个重要的描述对象：ActionDescriptor
ASP.NET MVC三个重要的描述对象：ControllerDescriptor与ActionDescriptor的创建机制
 ASP.NET MVC三个重要的描述对象：ParameterDescriptor

本文链接

《WCF全面解析》（上、下册）试读章节PDF下载

2012-05-12T02:41:00Z

《WCF全面解析》（上册）第3章绑定（Binding）

从整个基础构架的层次结构上讲，WCF可以分为服务模型层（Service Model Layer）和信道层（Channel Layer）两个层次。服务模型层建立在信道层之上，提供了一个统一的、可扩展的编程模型，而信道层通过信道栈（Channel Stack）实现对消息的传输和处理。作为终结点三要素之一的绑定在整个WCF架构体系中具有重要的地位。一方面，组成整个信道层的信道栈是由绑定创建的；另一方面，绑定又是连接两个层次的纽带。[PDF从这里下载]

《WCF全面解析》（上册）第6章消息（Message）

虽然我们一直在强调WCF基于消息通信的本质，但是一般的编程人员却感受不到消息的存在，这是因为WCF设计的目标就是在内部实现消息通信的所有细节，并为最终的编程人员提供一个完全面向对象的应用编程接口。他们面对的是接口，却不知道服务契约对于服务的描述；面对的是数据类型，却不知道数据契约对序列化的作用；面对的是方法调用和返回值的获取，却不了解底层消息交换的过程。只有从消息交换层面来认识WCF才能洞悉其本质，也只有对整个消息处理流程具有清晰的认识才能创建高效的WCF应用。[PDF从这里下载]

《WCF全面解析》（下册）第5章可靠会话（Reliable Sessions）

作为一个通信基础平台，WCF必须保证通信的可靠性。由于消息交换是WCF采用的通信手段，通信可靠性的保障体现在确保消息的可靠传输。WCF是一个消息处理框架，作为整个消息交换系统的两个终端，即发送端和接收端。WCF仅仅负责对消息的发送和接收，一旦消息通过WCF的信道层进入了网络，就脱离了WCF的控制范围。由于网络环境的限制，网络层不能百分之百地确保对消息的有效交付。如何克服中间环节的制约，确保从一端发送的消息能够被有效地交付给另一端，这就是可靠消息传输（Reliable Messaging）需要解决的问题。WCF通过可靠会话（Reliable Sessions）实现了端到端（End to End）的可靠消息传输。[PDF从这里下载]

《WCF全面解析》在正式销售不到一周的时间内已经进入互动网7日销量已经进入计算机类书籍排名第2位，关注排名首位，谢谢各位的支持。

本文链接

ASP.NET MVC三个重要的描述对象：ControllerDescriptor和ActionDescriptor的创建

2012-05-11T00:52:00Z

不论是用于描述Controller的ControllerDescriptor，还是用于描述Action方法的ActionDescriptor，都具有同步和异步两个版本，那么这些不同类型的ControllerDescriptor的ActionDescriptor是在什么情况下创建的呢？

一、ControllerActionInvoker与AsyncControllerActionInvoker

ControllerDescriptor的创建设计到一个重要的名为ActionInvoker的组件，顾名思义，ActionInvoker专门用于Action方法的执行。我们会在本书第7章“Action方法的执行”中对ActionInvoker进行深入介绍，在这里我们只需要对其作一个简单的了解。

ActionInvoker实现了具有如下定义的IActionInvoker接口，唯一的方法实现了对指定Action方法的执行，而作为Controller的默认基类的Controller具有一个ActionInvoker属性，该属性表示的ActionInvoker被真正用于定义在该Controller类型中的所有Action方法的执行。

        1: public interface IActionInvoker       2: {       3:     bool InvokeAction(ControllerContext controllerContext, string actionName);       4: }       5:         6: public abstract class Controller       7: {          8:     //其它成员       9:     public IActionInvoker ActionInvoker { get; set; }      10: }

而具有如下定义的System.Web.Mvc.Async.IAsyncActionInvoker接口是ActionInvoker的异步版本。IAsyncActionInvoker继承了IActionInvoker接口，并在此基础上定义了两个BeginInvokeAction/EndInvokeAction方法用于Action方法的异步执行。

       1: public interface IAsyncActionInvoker : IActionInvoker       2: {       3:     IAsyncResult BeginInvokeAction(ControllerContext controllerContext,  string actionName, AsyncCallback callback, object state);       4:     bool EndInvokeAction(IAsyncResult asyncResult);       5: }

ASP.NET MVC真正用于Action方法同步和异步执行的ActionInvoker分别是ControllerActionInvoker和AsyncControllerActionInvoker。如下面的代码片断所示，ControllerActionInvoker定义了一个受保护的方法GetControllerDescriptor用于根据指定的Controller上下文获取相应的ControllerDescriptor，它的子类AsyncControllerActionInvoker对这个方法进行了重写。

       1: public class ControllerActionInvoker : IActionInvoker       2: {       3:     //其它成员       4:     protected virtual ControllerDescriptor GetControllerDescriptor( ControllerContext controllerContext);       5: }       6:         7: public class AsyncControllerActionInvoker : ControllerActionInvoker,  IAsyncActionInvoker, IActionInvoker       8: {       9:     //其它成员      10:     protected override ControllerDescriptor GetControllerDescriptor( ControllerContext controllerContext);      11: }

我们所有要了解的是在默认情况下（没有对Controller类型的ActionInvoker属性进行显式设置）采用的ActionInvoker类型是哪个。ASP.NET MVC对Conroller采用的ActionInvoker类型的选择机制是这样的：

通过当前的DependencyResolver以IAsyncActionInvoker接口去获取注册的ActionInvoker，如果返回对象不为Null，则将其作为默认的ActionInvoker。
通过当前的DependencyResolver以IActionInvoker接口去获取注册的ActionInvoker，如果返回对象不为Null，则将其作为默认的ActionInvoker。
创建AsyncControllerActionInvoker对象作为默认的ActionInvoker。

在默认的情况下，当前的DependencyResolver直接通过对指定的类型进行反射来提供对应的实例对象，所以对于前面两个步骤返回的对象均为Null，所以默认创建出来的ActionInvoker类型为AsyncControllerActionInvoker。我们可以通过如下一个简单的实例来验证这一点。在通过Visual Studio的ASP.NET MVC项目模板创建的空Web应用中，我们创建了如下一个默认的HomeController，在Action方法Index中直接通过ContentResult将ActionInvoker属性的类型名称呈现出来。

       1: public class HomeController : Controller       2: {         3:     public ActionResult Index()       4:     {       5:         return Content("默认ActionInvoker类型:" + this.ActionInvoker.GetType().FullName);       6:     }       7: }   

当运行该Web应用时，会在浏览器上产生如下的输出结果，我们可以清楚地看到默认采用的ActionInvoker类型正是AsyncControllerActionInvoker。

1: 默认ActionInvoker类型:System.Web.Mvc.Async.AsyncControllerActionInvoker

为了进一步验证基于DependencyResolver对ActionInvoker的提供机制，我们将在《ASP.NET MVC Controller激活系统详解：IoC的应用[下篇]》创建的基于Ninject的自定义NinjectDependencyResolver应用在这里。如下面的代码片断所示，在初始化NinjectDependencyResolver的时候，我们将IActionInvoker和IAsyncActionInvoker影射到两个自定义ActionInvoker类型，即FooActionInvoker和FooAsyncActionInvoker，它们分别继承自ControllerActionInvoker和AsyncControllerActionInvoker。

       1: public class NinjectDependencyResolver : IDependencyResolver       2: {       3:     public IKernel Kernel { get; private set; }       4:     public NinjectDependencyResolver()       5:     {       6:         this.Kernel = new StandardKernel();       7:         AddBindings();       8:     }       9:     private void AddBindings()      10:     {      11:         this.Kernel.Bind<IActionInvoker>().To<FooActionInvoker>();      12:         this.Kernel.Bind<IAsyncActionInvoker>().To<FooAsyncActionInvoker>();      13:     }      14:     public object GetService(Type serviceType)      15:     {      16:         return this.Kernel.TryGet(serviceType);      17:     }      18:     public IEnumerable<object> GetServices(Type serviceType)      19:     {      20:         return this.Kernel.GetAll(serviceType);      21:     }      22: }      23: public class FooActionInvoker : ControllerActionInvoker      24: {}      25: public class FooAsyncActionInvoker : AsyncControllerActionInvoker      26: {}

在Global.asax中对NinjectDependencyResolver进行注册后运行我们的程序，会在浏览器中得到如下的输出结果。IAsyncActionInvoker和FooAsyncActionInvoker进行了影射，NinjectDependencyResolver可以通过IAsyncActionInvoker提供一个FooAsyncActionInvoker实例。

1: 默认ActionInvoker类型:Artech.Mvc.FooAsyncActionInvoker

现在我们对NinjectDependencyResolver的定义稍加修改，将针对IAsyncActionInvoker接口的类型影射删除，只保留针对IActionInvoker的映射。

       1: public class NinjectDependencyResolver : IDependencyResolver       2: {       3:     //其它成员       4:     private void AddBindings()       5:     {       6:         this.Kernel.Bind<IActionInvoker>().To<FooActionInvoker>();       7:         //this.Kernel.Bind<IAsyncActionInvoker>().To<FooAsyncActionInvoker>();       8:     }       9: }

再次运行我们的程序则会得到如下的输出结果。由于NinjectDependencyResolver只能通过IActionInvoker接口提供具体的ActionInvoker，所以最终被创建的是一个FooActionInvoker对象。这个实例演示告诉我们：当我们需要使用到自定义的ActionInvoker的时候，可以通过自定义DependencyResolver以IoC的方式提供具体的ActionInvoker实例。

1: 默认ActionInvoker类型:Artech.Mvc.FooActionInvoker

二、ActionInvoker与ControllerDescriptor/ActionDescriptor

ControllerDescriptor和ActionDescriptor最终是为Model绑定服务的，而Model绑定是Action执行的一个环节，所以ControllerDescriptor最终是由相应的ActionInvoker创建的。总的来说，用于同步Action执行的ControllerActionInvoker创建ReflectedControllerDescriptor，而用于异步Action执行的AsyncControllerActionInvoker则创建ReflectedAsyncControllerDescriptor。ActionInvoker和ControllerDescriptor之间的关系可以通过如下图所示的UML来表示。

对于ReflectedControllerDescriptor来说，包含其中的ActionDescriptor类型均为ReflectedActionDescriptor。而ReflectedAsyncControllerDescriptor描述的Controller可以同时包含同步和异步的Action方法，所以它可以包含任何类型的ActionDescriptor。

具体来说，如果Action方法的返回类型为Task，对应的ActionDescriptor是一个TaskAsyncActionDescriptor对象。如果Action方法名称包含“Async”后缀，并且存在一个对应的以“Completed”后缀的方法，则对应的ActionDescriptor是一个ReflectedAsyncActionDescriptor对象；如果对应Completed方法不存在，对应的FindAction方法会直接抛出一个InvalidOperationException异常。在其它情况下的Action方法均是同步的，所以对应的ActionDescriptor类型为ReflectedActionDescriptor。ControllerDescriptor与ActionDescriptor之间的关系如下图所示的UML来表示。

三、实例演示：AsyncActionInvoker对ControllerDescriptor的创建

为了让读者对ActionInvoker对ControllerDescriptor的解析机制具有一个深刻的理解，同时也作为对该机制的验证，我们做一个简单的实例演示。通过前面的介绍我们知道在默认的情况下Controller采用AsyncControllerActionInvoker进行Action方法的执行，这个例子就来演示一下它生成的ControllerDescriptor是个怎样的对象。我们通过Visual Studio的ASP.NET MVC项目模板创建一个空Web应用，并创建一个默认的HomeController，然后对其进行如下的修改。

       1: public class HomeController : AsyncController       2: {       3:     public void Index()       4:     {       5:         MethodInfo method = typeof(AsyncControllerActionInvoker).GetMethod("GetControllerDescriptor", BindingFlags.Instance | BindingFlags.NonPublic);       6:         ControllerDescriptor controllerDescriptor = (ControllerDescriptor)method.Invoke(this.ActionInvoker, new object[] { this.ControllerContext });       7:         Response.Write(controllerDescriptor.GetType().FullName + "<br/>");       8:         CheckAction(controllerDescriptor, "Foo");       9:         CheckAction(controllerDescriptor, "Bar");      10:         CheckAction(controllerDescriptor, "Baz");      11:        12:     }      13:     private void CheckAction(ControllerDescriptor controllerDescriptor, string actionName)      14:     {      15:         ActionDescriptor actionDescriptor = controllerDescriptor.FindAction(this.ControllerContext, actionName);      16:         Response.Write(string.Format("{0}:{1}<br/>",actionName, actionDescriptor.GetType().FullName));      17:     }      18:        19:     public void Foo() { }      20:     public void BarAsync() { }      21:     public void BarCompleted() { }      22:     public Task Baz()      23:     {      24:         return new Task(DoNothing);      25:     }      26:     public void DoNothing() { }      27: }

我们首先将HomeController的基类从Controller改为AsyncController，并定义了Foo、BarAsync/BarCompleted和Baz四个方法，我们知道它们对应着Foo、Bar和Baz三个Action，其中Foo是同步Action，Bar和Baz分别是两种不同定义形式（XxxAsync/XxxCompleted和Task）的异步Action。

CheckAction用于根据指定的Action名称从ControllerDescriptor对象中获取用于表示对应Action的ActionDescriptor对象，最终将类型名称呈现出来。在Index方法中，我们通过反射的方式调用当前ActionInvoker（一个AsyncControllerActionInvoker对象）的受保护方法GetControllerDescriptor或者用于描述当前Controller（HomeController）的ControllerDescriptor的对象，并将类型名称呈现出来。最后通过调用CheckAction方法将包含在创建的ControllerDescriptor对象的三个ActionDescriptor类型呈现出来。

当我们运行该程序的时候，在浏览器中会产生如下的输出结果，从中可以看出ControllerDescriptor类型为ReflectedAsyncControllerDescriptor。同步方法Foo对象的ActionDescriptor是一个ReflectedActionDescriptor对象；以XxxAsync/XxxCompleted形式定义的异步方法Bar对应的ActionDescriptor是一个ReflectedAsyncActionDescriptor对象；而返回类型为Task的方法Baz对应的ActionDescriptor类型则是TaskAsyncActionDescriptor。

       1: System.Web.Mvc.Async.ReflectedAsyncControllerDescriptor       2: Foo:System.Web.Mvc.ReflectedActionDescriptor       3: Bar:System.Web.Mvc.Async.ReflectedAsyncActionDescriptor       4: Baz:System.Web.Mvc.Async.TaskAsyncActionDescriptor

本文链接