最近在自己瞎整设计自己的数据访问层（纯属深入了解C#用），遇到了反射。网传反射性能很差，可是我们项目中也有功能用到了反射，总体来说还不错（小项目）。由于居安思危的感觉越发沉重，不得不去打破传统，去寻求可以替代反射，稍加提高性能的方式，于是乎就到了现在。

我最讨厌，什么看见别人用反射就说性能差，以一言以带过，去问他怎么优化，半天都不知所云（在项目中用反射的时候，很多同事都是这样）。如果是真正的大神都会先列出自己以前用到的反射，然后给出优化方案。

以下就是博客园最盛行的关于dynamic简化反射的文章

1，改善C#程序的建议2：C#中dynamic的正确用法

2，使用dynamic来简化反射实现

3，使用.NET4.0的dynamic实现反射

4，编写高质量代码改善C#程序的157个建议[为类型输出格式化字符串、实现浅拷贝和深拷贝、用dynamic来优化反射]

………………………………….

用自己的方式，稍加改动吧

大神Fish Li说得好目前最常见的优化反射性能的方法就是采用委托：用委托的方式调用需要反射调用的方法（或者属性、字段）接下来就跟着大神走，构建委托吧

//通过dynamic获取对象中的字段
 Func<T, string> DynamicGetter<T>()
 {
      return s => { dynamic d = s; return d.name; };
 }

//通过dynamic调用对象中的方法（此处是动态调用List内部Add方法）
 Action<T> DynamicGetter2<T>()
 {
      return t => { dynamic d = t; d.Add("str"); };
 }

再来个需要用到的类

public class ProductEntity
    {
        ";

        [DataField("nid")]
        public string ProductNo { get; set; }

        [DataField("pname")]
        public string ProductName { get; set; }
    }

接下来就是调用了

var s = DynamicGetter<ProductEntity>();
var sss = s(new ProductEntity());

var t = DynamicGetter2<List<string>>();
List<string> list = new List<string>();
t(list);

dynamic理论：它是C#引入的新类型，它的特点是申明为dynamic类型的变量，不是在编译时候确定实际类型的, 而是在运行时。

所以我们构建 t => { dynamic d = t; d.Add("str"); }; 表达式的时候就不会报 "dynamic" 不包含 "Add()" 的定义，并找不到可接受类型为……的错误了

这样当到达了运行的时候，会动态的获取【t】的类型，去调用【t】中的Add方法。

因为dynamic类型要在运行时才去检测确定，所以很多错误无法在编译时重现，这样使用的时候就需要非常小心了。

下一篇：给自己的数据访问层的实体反射赋值