什么是.NETreflection的“成本”？
可能重复：
.NETreflection代价如何？
我目前处于编程心态，反思是我最好的朋友。 我使用它很多dynamic加载的内容，允许“松散实现”，而不是严格的接口，以及许多自定义属性。
什么是使用reflection的“真实”成本？
对于经常reflection的types来说，是否值得为cachingreflection付出努力，比如我们自己的LINQ DAL目标代码在所有属性上的表定义？
高速caching的内存占用是否会反映CPU使用率？
reflection需要加载大量的types元数据，然后进行处理。 这可能会导致更大的内存开销和更慢的执行。 根据这篇文章，属性修改慢了大约2.5x-3x，方法调用慢了3.5x-4x。
下面是一篇很好的MSDN文章，概述了如何更快地进行reflection以及开销。 我强烈build议阅读，如果你想了解更多。
reflection会增加代码的复杂性，使得代码变得更加混乱，因此很难处理。 有些人，比如斯科特·汉塞尔曼（Scott Hanselman）认为，通过反思，你经常会遇到比解决问题更多的问题 如果你的团队大多是初级开发者，情况尤其如此。
如果您需要大量的dynamic行为，则可以更好地查看DLR（dynamic语言运行时）。 随着.NET 4.0中出现的新变化，您可能需要了解是否可以将其中的一些内容纳入到您的解决scheme中。 从VB和C＃中dynamic添加的支持使得使用dynamic代码非常优雅，创build自己的dynamic对象相当简单。
祝你好运。
编辑：我做了更多的斯科特的网站戳，发现这个播客反思。 我没有听过，但可能是值得的。
有很多事情可以加速思考。 例如，如果你正在做很多的属性访问，那么HyperDescriptor可能是有用的。
如果你正在做很多的方法调用，那么你可以caching方法来使用Delegate.CreateDelegate键入委托 – 然后这样做只有一次（在CreateDelegate ）的types检查等。
如果你正在做很多的对象构造，那么Delegate.CreateDelegate将不会帮助（你不能在构造函数中使用它） – 但是（在3.5中） Expression可以用来做这个，再次编译到一个types化的委托。
所以是的：reflection是缓慢的，但你可以优化它没有太多的痛苦。
拥有权利的同时也被赋予了重大的责任。
正如你所说，reflection与其相关的成本，取决于你做了多lessreflection，它可以显着减慢应用程序。
其中一个使用它的地方是IoC（Inversion of Control），因为根据应用程序的大小，可能会有更多的好处。
感谢这些伟大的联系和伟大的意见，特别是在Jr Devs方面，这正是它的正确select。
对于我们来说，对于我们的初级开发者来说这样做更容易：
[TableName("Table")] public class SomeDal : BaseDal { [FieldName("Field")] public string Field }
而不是DAL的一些更大的推动。 这加快了DAL对象的构build，同时隐藏了高级开发人员的所有内部工作。
太糟糕了，LINQ没有早点出来，我觉得有时我们写了一半。
在使用reflection时，有时候可能会咬你的东西不是在重构时使用reflection来更新调用。 像resharper这样的工具会提示你在更改方法名时更新注释和string，所以你可以用这种方法来捕获大部分的方法，但是当你调用dynamic生成的方法或者dynamic生成方法名的时候，你可能会错过了什么。
唯一的解决scheme是良好的文档和彻底的unit testing。
