c#中的反射 作者： YAOTIEBING
反射的概述
反射的定义：审查元数据并收集关于它的类型信息的能力。元数据（编译以后的最基本数据单元）就是一大堆的表，当编译程序集或者模块时，编译器会创建一个类定义表，一个字段定义表，和一个方法定义表等，。System.reflection命名空间包含的几个类，允许你反射（解析）这些元数据表的代码
和反射相关的命名空间（我们就是通过这几个命名空间访问反射信息）：
System.Reflection.MemberInfo
System.Reflection.EventInfo
System.Reflection.FieldInfo
System.Reflection.MethodBase
System.Reflection.ConstructorInfo
System.Reflection.MethodInfo
System.Reflection.PropertyInfo
System.Type
System.Reflection.Assembly
反射的层次模型：
注：层次间都是一对多的关系
反射的作用：
1． 可以使用反射动态地创建类型的实例，将类型绑定到现有对象，或从现 有对象中获取类型
2． 应用程序需要在运行时从某个特定的程序集中载入一个特定的类型，以便实现某个任务时可以用到反射。
3． 反射主要应用与类库，这些类库需要知道一个类型的定义，以便提供更多的功能。
应用要点：
1． 现实应用程序中很少有应用程序需要使用反射类型
2． 使用反射动态绑定需要牺牲性能
3． 有些元数据信息是不能通过反射获取的
4． 某些反射类型是专门为那些clr 开发编译器的开发使用的，所以你要意识到不是所有的反射类型都是适合每个人的。
反射appDomain 的程序集
当你需要反射AppDomain 中包含的所有程序集，示例如下：
static void Main
{
//通过GetAssemblies 调用appDomain的所有程序集
foreach (Assembly assem in Appdomain.currentDomain.GetAssemblies())
{
//反射当前程序集的信息
reflector.ReflectOnAssembly(assem)
}
}
说明：调用AppDomain 对象的GetAssemblies 方法 将返回一个由System.Reflection.Assembly元素组成的数组。
反射单个程序集
上面的方法讲的是反射AppDomain的所有程序集，我们可以显示的调用其中的一个程序集，system.reflecton.assembly 类型提供了下面三种方法：
1． Load 方法：极力推荐的一种方法，Load 方法带有一个程序集标志并载入它，Load 将引起CLR把策略应用到程序集上，先后在全局程序集缓冲区，应用程序基目录和私有路径下面查找该程序集，如果找不到该程序集系统抛出异常
2． LoadFrom 方法：传递一个程序集文件的路径名（包括扩展名），CLR会载入您指定的这个程序集，传递的这个参数不能包含任何关于版本号的信息，区域性，和公钥信息，如果在指定路径找不到程序集抛出异常。
3． LoadWithPartialName：永远不要使用这个方法，因为应用程序不能确定再在载入的程序集的版本。该方法的唯一用途是帮助那些在.Net框架的测试环节使用.net 框架提供的某种行为的客户，这个方法将最终被抛弃不用。
注意：system.AppDomain 也提供了一种Load 方法，他和Assembly的静态Load 方法不一样，AppDomain的load 方法是一种实例方法，返回的是一个对程序集的引用，Assembly的静态Load 方发将程序集按值封装发回给发出调用的AppDomain.尽量避免使用AppDomain的load 方法
利用反射获取类型信息
前面讲完了关于程序集的反射，下面在讲一下反射层次模型中的第三个层次，类型反射
一个简单的利用反射获取类型信息的例子：
using system;
using sytem.reflection;
class reflecting
{
static void Main(string[]args)
{
reflecting reflect=new reflecting();//定义一个新的自身类
//调用一个reflecting.exe程序集
assembly myAssembly =assembly.loadfrom(“reflecting.exe”)
reflect.getreflectioninfo(myAssembly);//获取反射信息
}
//定义一个获取反射内容的方法
void getreflectioninfo(assembly myassembly)
{
type[] typearr=myassemby.Gettypes();//获取类型
foreach (type type in typearr)//针对每个类型获取详细信息
{
//获取类型的结构信息
constructorinfo[] myconstructors=type.GetConstructors;
//获取类型的字段信息
fieldinfo[] myfields=type.GetFiedls()
//获取方法信息
MethodInfo myMethodInfo=type.GetMethods();
//获取属性信息
propertyInfo[] myproperties=type.GetProperties
//获取事件信息
EventInfo[] Myevents=type.GetEvents;
}
}
}
其它几种获取type对象的方法：
1． System.type 参数为字符串类型，该字符串必须指定类型的完整名称（包括其命名空间）
2． System.type 提供了两个实例方法：GetNestedType,GetNestedTypes
3． Syetem.Reflection.Assembly 类型提供的实例方法是：GetType,GetTypes,GetExporedTypes
4． System.Reflection.Moudle 提供了这些实例方法：GetType,GetTypes,FindTypes
设置反射类型的成员
反射类型的成员就是反射层次模型中最下面的一层数据。我们可以通过type对象的GetMembers 方法取得一个类型的成员。如果我们使用的是不带参数的GetMembers，它只返回该类型的公共定义的静态变量和实例成员，我们也可以通过使用带参数的GetMembers通过参数设置来返回指定的类型成员。具体参数参考msdn 中system.reflection.bindingflags 枚举类型的详细说明。
例如：
//设置需要返回的类型的成员内容
bindingFlags bf=bingdingFlags.DeclaredOnly|bingdingFlags.Nonpublic|BingdingFlags.Public;
foreach (MemberInfo mi int t.getmembers(bf))
{
writeline(mi.membertype) //输出指定的类型成员
}
通过反射创建类型的实例
通过反射可以获取程序集的类型，我们就可以根据获得的程序集类型来创建该类型新的实例，这也是前面提到的在运行时创建对象实现晚绑定的功能
我们可以通过下面的几个方法实现：
1． System.Activator 的CreateInstance方法。该方法返回新对象的引用。具体使用方法参见msnd
2． System.Activator 的createInstanceFrom 与上一个方法类似，不过需要指定类型及其程序集
3． System.Appdomain 的方法：createInstance,CreateInstanceAndUnwrap,CreateInstranceFrom和CreateInstraceFromAndUnwrap
4． System.type的InvokeMember实例方法：这个方法返回一个与传入参数相符的构造函数，并构造该类型。
5． System.reflection.constructinfo 的Invoke实例方法
反射类型的接口
如果你想要获得一个类型继承的所有接口集合，可以调用Type的FindInterfaces GetInterface或者GetInterfaces。所有这些方法只能返回该类型直接继承的接口，他们不会返回从一个接口继承下来的接口。要想返回接口的基础接口必须再次调用上述方法。
反射的性能：
使用反射来调用类型或者触发方法，或者访问一个字段或者属性时clr 需 要做更多的工作：校验参数，检查权限等等，所以速度是非常慢的。所以尽量不要使用反射进行编程，对于打算编写一个动态构造类型（晚绑定）的应用程序，可以采取以下的几种方式进行代替：
1． 通过类的继承关系。让该类型从一个编译时可知的基础类型派生出来，在运行时生成该类 型的一个实例，将对其的引用放到其基础类型的一个变量中，然后调用该基础类型的虚方法。
2． 通过接口实现。在运行时，构建该类型的一个实例，将对其的引用放到其接口类型的一个变量中，然后调用该接口定义的虚方法。
3．通过委托实现。让该类型实现一个方法，其名称和原型都与一个在编译时就已知的委托相符。在运行时先构造该类型的实例，然后在用该方法的对象及名称构造出该委托的实例，接着通过委托调用你想要的方法。这个方法相对与前面两个方法所作的工作要多一些，效率更低一些
上次在MSDN网站看到一个比较动态调用代码的文章，用到的例子似乎比较复杂，为计算一个复杂多项式子而将其中部分割开，动态形成代码段来被循环调用。详细看.NET下几种动态生成代码方式比较。今天看到微软C#团队的Eric Gunnerson写的另外一篇关于动态调用代码性能的比较文章，为了说明结果和计算的准确性，减少由于函数复杂而受编译优化的影响，他使用了一个极为简单的例子：
输入一个参数，然后返回这个参数加一，这么简单的函数，优化和没有优化的代码应该不会有差别的了。
public
class
Processor
{
public int Process(int value)
{ return value + 1;
}
}
而对比方面，除了上次那几种外，还加了代理方式调用来进行比较。
1. 直接调用
int
value
=
processor.Process(i);
2. 用反射机制，Type.InvokeMember()调用。
Type t
=
typeof
(Processor);
int
value
=
(
int
) t.InvokeMember(
"
Process
"
, BindingFlags.Instance
|
BindingFlags.Public
|
BindingFlags.InvokeMethod,
null
, processor,
new
object
[]
{i}
);
3. 通过一个接口
public
interface
IProcessor
{ int Process(int value); }
4. 通过一个委托Delegate
public
delegate
int
ProcessCaller(
int
value); ProcessCaller processCaller
=
new
ProcessCaller(processor.Process);
int
value
=
processCaller(i);
5. 也通过反射机制建立委托再动态调用
Type delegateType
=
CreateCustomDelegate(methodInfo); Delegate p
=
Delegate.CreateDelegate(delegateType, process,
"
Process
"
);
int
value
=
(
int
) p.DynamicInvoke(
new
object
[]
{i}
);
6. 元编程方式
对于2和5由于使用反射机制，不可避免需要建立中间的临时对象去传递参数，将参数和返回值装箱等操作，因此花费了大量的机器时间。
下面是运行的某次结果（循环100000次）：
结论：
1.直接调用速度最快是肯定的。
2.接口调用比元编程速度快，而元编程又比委托方式快，但微软相信Whidbey会极大优化委托调用方式，从而使它接近接口调用的水平。
3.直接用Type的反射机制是速度最慢的，比用反射机制建立委托来动态调用还慢。
4.直接使用委托不够灵活，有时候需要用反射机制建立委托来调用，但会减低性能，希望Whidbey优化了委托的性能后这种情况可以改善，灵活是需要牺牲性能的。
在实际开发中，我们经常需要从数据库中读取数据并赋值给实体类的相应属性。在.Text的DataDTOProvider中存在大量这样的代码, 比如:
public
Role[] GetRoles(
int
BlogID)
{ System.Collections.ArrayList al=new System.Collections.ArrayList(); IDataReader reader=DbProvider.Instance().GetRoles(BlogID); try
{ while(reader.Read()) { Role role=new Role(); if(reader["RoleID"]!=DBNull.Value) { role.RoleID=(int)reader["RoleID"]; } if(reader["Name"]!=DBNull.Value) { role.Name=(string)reader["Name"]; } if(reader["Description"]!=DBNull.Value) { role.Description=(string)reader["Description"]; } //ReaderToObject(reader,role); al.Add(role); } } finally { reader.Close(); } return (Role[])al.ToArray(typeof(Role)); }
对于上面的代码，我觉得有几点不优雅之处：
1、每次对Role的属性进行赋值时，都要检查reader的值是否为DBNull，出现了很多重复代码
2、每次对Role的属性进行赋值时，都要进行类型转换, 而Role属性的类型是已知的，是不是可以自动完成这样的转换？
3、每次对Role的属性进行赋值时，都要进行Role属性与数据库字段的对应。如果我们在设计数据库与实体类时，保证数据库字段与实体类属性采用同样的名称，那利用反射，我们可以通过代码自动进行属性与字段的对应。即使数据库字段与属性不同名，我们也可以通过更改查询语句，来做到这一点。
是不是可以对上面的代码进行改进，使代码变得更优雅?那优雅的代码应该是什么样的呢?如果我们用上面代码中注释的代码行ReaderToObject(reader,role);取代它之前的对Role属性进行赋值的语句，是不是会使代码变得更优雅?ReaderToObject的作用就是自动完成将reader中的值写入到role中对应的属性中(前提是reader中的字段与role中对应的属性具有相同的名称)。现在我们的任务就是实现ReaderToObject, 有了强大的武器—Reflection，我们的任务就变得很轻松, 也不多说了，下面的代码是我的实现方法:
private
void
ReaderToObject(IDataReader reader,
object
targetObj)
{ for(int i=0;i<reader.FieldCount;i++) { System.Reflection.PropertyInfo propertyInfo=targetObj.GetType().GetProperty(reader.GetName(i)); if(propertyInfo!=null) { if(reader.GetValue(i)!=DBNull.Value) { propertyInfo.SetValue(targetObj,reader.GetValue(i),null); } } } }
ReaderToObject可以将reader中的数据读入到任何实体类中。数据库字段与实体类属性的映射原则是名称相同。当然，我们也可以通过配置文件来进行两者映射。
个人想法：在开发中，面对那么多设计思想和设计模式，常常令人感到迷惑，当你把更多的精力放在选用哪个设计思想或设计模式时，我觉得不要忽略很重要的一点，尽可能地减少重复代码，只要我们能有效地减少重复代码，我们采用的方法就是好方法，而不要太在乎采用了哪种模式。就像独孤九剑，正因为摆脱了传统招式的束缚，才能战无不胜!
.NET Quick Tip: Runtime Type Conversion for Enumeration
先来看这段NUnit测试代码，我们希望用反射机制在运行时访问一个对象的枚举类型的域或属性：
[TestFixture]
public class PaymentInfo
{
public enum PaymentType
{
Cash, CreditCard, Check
}
public PaymentType Type;
public void Test()
{
PaymentInfo payment = new PaymentInfo();
payment.Type = PaymentType.Cash;
System.Reflection.FieldInfo enumField = GetType().GetField("Type");
int paymentTypeInt32;
paymentTypeInt32 = (int)enumField.GetValue(payment);
Assert.AreEqual((int)PaymentType.Cash, paymentTypeInt32);
enumField.SetValue(payment, paymentTypeInt32);
Assert.AreEqual(PaymentType.Cash, payment.Type);
}
}
实际上运行测试时发现在标红的这行上抛出一个异常：“对象类型无法转换为目标类型”。究其原因，原来是因为CLR的反射机制不允许枚举类型与整数类型之间隐式转换。不过C#编译器还是允许我们通过强制类型转换的语法来进行两者间的显式转换。
在这个测试中，使之通过的办法其实非常简单：把划线部分强制转换为枚举类型即可，如：(PaymentType)paymentTypeInt32。可问题是：在运行时如何动态转换类型呢？比如说我在写ElegantDAL的时候，需要将从数据库读出的一个类型为int的数值写入到要返回的对象的一个枚举型字段中，此时我只有fieldInfo、columnValue和resultObject，然而写成fieldInfo.SetValue(resultObject, columnValue)就会出现前面提到的错误，可是我又只有一个运行时的Type信息（fieldInfo.FieldType），我又不能写成fieldInfo.SetValue(resultObject, (fieldInfo.FieldType)columnValue)……
只好将这种情况列为一个特例处理，而我们的救兵则是Enum.ToObject()方法——你知道有更好的方法解决这个问题吗？
BTW: 很多朋友写信来问偶承诺的下一篇文章什么时候才能搞定，其实我也不想拖，可最近工作确实比较紧张，而我的最佳写作时间又都在深更半夜（之前还要热身进入状态），所以迟迟不能结稿。目前其实已经写了好多（已经和第一篇长度差不多了），可是发现要写的内容还太多（也许是我写得太细了，因为我的目标不仅是讲how，更多的是what和why），所以现在决定把本篇文字再细分为两部分（上篇只讲TP/RP+MBR对象；把CBO相关的内容放到下篇再写），以便能够尽快让大家看到新的内容——嗯，争取周五release吧。至于还有朋友希望我能够深入写些关于ElegantDAL的设计与实现细节，这个留待稍后吧，正好我们将要整理的项目文档中也要有这一块内容（现在在我们这个企业级项目中用得还真挺好），到时候一起写啦（希望能够和canyue尽快完成第三版本的重写工作，目前使用的是第二版）。
1220
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
