一旦获得所有必要的反射实例对象，即可根据需要遵循检查或操作的步骤继续。检查时，您在反射类中使用各种描述性属性，获得您需要的信息(这是通用类型吗?这是实例方法吗?)。操作时，您可以动态地调用并执行方法，通过调用构造函数创建新对象，等等。
检查类型和成员
让我们跳转到一些代码中，探索如何运用基本反射进行检查。我将集中讨论类型分析。从一个对象开始，我将检索它的类型，而后考察几个有意思的成员(请参见图 2)。
首先需要注意的是，在类定义中，乍看起来说明方法的篇幅比我预期的要多很多。这些额外的方法是从哪里来的呢?任何精通 .NET Framework 对象层次结构的人，都会识别从通用基类 Object 自身继承的这些方法。(事实上，我首先使用了 Object.GetType 检索其类型。)此外，您可以看到属性的 getter 函数。现在，如果您只需要 MyClass 自身显式定义的函数，该怎么办呢?换句话说，您如何隐藏继承的函数?或者您可能只需要显式定义的实例函数?
随便在线看看 MSDN，就会发现大家都愿意使用 GetMethods 第二个重载方法，它接受 BindingFlags 参数。通过结合来自 BindingFlags 枚举中不同的值，您可以让函数仅返回所需的方法子集。替换 GetMethods 调用，代之以：
GetMethods(BindingFlags.Instance | BindingFlags.DeclaredOnly |BindingFlags.Public)
结果是，您得到以下输出(注意这里不存在静态帮助器函数和继承自 System.Object 的函数)。
Reflection Demo Example 1
Type Name: MyClass
Method Name: MyMethod1
Method Name: MyMethod2
Method Name: get_MyProperty
Property Name: MyProperty
如果您事先知道类型名称(完全限定)和成员，又该如何?您如何完成从枚举类型向检索类型的转换?有了前两个示例中的代码，您已经有了能够实现基元类浏览器的基本组件。通过名称您可以找到一个运行时实体，然后枚举其各种相关属性。
动态调用代码
迄今为止，我已经获得运行时对象的句柄(如类型和方法)，仅作描述用，例如输出它们的名称。但是如何做得更多呢?如何实际调用某个方法呢?
此例的几个要点是：首先，从一个 MyClass, mc1 实例检索一个 System.Type 实例，然后，从该类型检索一个 MethodInfo 实例。最后，当调用 MethodInfo 时，通过把它作为调用的第一个参数来传递，将其绑定到另一个 MyClass (mc2) 实例中。
前面讲过，对于您预期在源代码中见到的类型和对象使用之间的区别，这个示例使这种区别变得模糊。逻辑上，您检索了一个方法的句柄，然后调用该方法，就象它属于一个不同的对象一样。对于熟悉函数式编程语言的程序员来说，这可能轻而易举;但对于只熟悉 C# 的程序员来说，要分离对象实现和对象实例化，可能就不是那么直观了。
组合在一起
至此我已经探讨过检查和调用的基本原理，接下来我会用具体的例子把它们组合在一起。设想您希望交付一个库，带有必须处理对象的静态帮助器函数。但在设计的时候，您对这些对象的类型没有任何概念!这要看函数调用方的指示，看他希望如何从这些对象中提取有意义的信息。函数将接受一个对象集合，和一个方法的字符串描述符。然后它将遍历该集合，调用每个对象的方法，用一些函数聚合返回值。
就此例而言，我要声明一些约束条件。首先，字符串参数描述的方法(必须由每个对象的底层类型实现)不会接受任何参数，并将返回一个整数。代码将遍历对象集合，调用指定的方法，逐步计算出所有值的平均值。最后，因为这不是生产代码，在求和的时候我不用担心参数验证或整数溢出。
在浏览示例代码时，可以看到主函数与静态帮助器 ComputeAverage 之间的协议除了对象自身的通用基类之外，并不依赖任何类型信息。换句话说，您可以彻底改变正在传送的对象的类型和结构，但只要总是能使用字符串描述一个方法，且该方法返回整数，ComputeAverage 就可以正常工作!
需要注意的一个关键问题跟隐藏在最后这个例子中的 MethodInfo(一般反射)有关。注意，在 ComputeAverage 的 foreach 循环中，代码只从集合中的第一个对象中抓取一个 MethodInfo，然后绑定用于所有后续对象的调用。正如编码所示，它运行良好 — 这是 MethodInfo 缓存的一个简单例子。但此处有一个根本性的局限。MethodInfo 实例仅能由其检索对象同等层级类型的实例调用。因为传入了 IntReturner 和 SonOfIntReturner(继承自 IntReturner)的实例，才能这样运行。
在示例代码中，已经包含了名为 EnemyOfIntReturner 的类，它实现了与其他两个类相同的基本协议，但并没有共享任何常见共享类型。换句话说，该接口逻辑上等同，但在类型层级上没有重叠。要探讨 MethodInfo 在该情形下的使用，请尝试向集合添加其他对象，通过“new EnemyOfIntReturner(10)”得到一个实例，再次运行示例。您会遇到一个异常，指出 MethodInfo 不能用于调用指定的对象，因为它和获得 MethodInfo 时的原始类型完全无关(即使方法名称和基本协议是等同的)。要使您的代码达到生产水准，您需要做好遇到这一情形的准备。
一个可能的解决方案可以是通过自己分析所有传入对象的类型，保留对其共享的类型层级(如果有)的解释。如果下一对象的类型与任意已知类型层级相异，就需要获取和存储一个新的 MethodInfo。另一解决方案是捕获 TargetException，并重新获取一个 MethodInfo 实例。这里提到的两种解决方案都各有其优缺点。Joel Pobar 为本杂志 2007 五月期写过一篇优秀的文章，内容关于 MethodInfo 缓冲和我所极力推荐的反射性能。
希望此示例演示的向应用程序或框架中添加反射，可以为日后的自定义或可扩展性增加更多的灵活性。不可否认，较之本机编程语言中的同等逻辑，使用反射可能会有些繁琐。如果您感到对您或您的客户来说，向代码中添加基于反射的后期绑定过于麻烦(毕竟他们需要以某种方式在您的框架中说明他们的类型和代码)，那么可能仅需要适度的灵活性以取得某种平衡。
序列化的高效类型处理
至此我们已通过若干示例讲述了 .NET 反射的基本原理，接下来让我们看一下现实世界中的情形。如果您的软件通过 Web 服务或其他进程外远程技术与其他系统进行交互，那么您很可能已经遇到序列化问题。序列化本质上是将活动的、占用内存的对象，转变成适合线上传输或磁盘存储的数据格式。
文章整理：西部数码--专业提供域名注册、虚拟主机服务
http://www.west263.com
以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!
