在何种程度上应该使用反射?

反思是强大的,但也有缺点。一般来说,尝试在没有它的情况下编写代码——但是对于“框架”库来说,它非常有用,因为您对实际对象的了解很少/有限;例如:

• ORM/DAL工具(加载/保存任意数据)
• 数据绑定
• 串行化

有一些特殊反射的性能惩罚,但是如果你打算这样做的话 太多了 (在您的库中,并在一个紧密的循环中)您可以减轻这一点:

• 通过使用 Delegate.CreateDelegate (作为) 类型化的 委派;不使用 DynamicInvoke )
• 通过编写动态IL
• 通过使用 Expression 在.NET 3.5中

当然,任何这样的代码都应该被缓存并重新使用(您不想为每个调用编译+执行;只是第一个——其余的应该只执行)。

或者有一些库抽象了这一点;例如, HyperPropertyDescriptor 将自定义IL(用于成员访问)包装在熟悉的 PropertyDescriptor API-让它非常快但无痛。您的问题涉及数据表和实体;听起来 许多 喜欢 this previous question ,其中我使用超描述符执行了一些度量,并使用摘要(毫秒):

Vanilla 27179
Hyper   6997

所以我的“取”:

• 在 应用 很小——一般来说,作为最后手段
• 在你 公共图书馆 ;在适当的情况下(注意,在可能的情况下,最好使用接口等)

如果鞋子合适,那就穿上它…如果它解决了手头的问题,并且不会导致通过某种测试(最好是分析器)测量到的过度处理,那么不要担心它。有很多问题很容易通过反思来解决。

关于决定不使用反射,我唯一的指导原则是使用反射来获取通常无法访问的属性(即,其他类中的私有属性)。

您的非功能性需求/QoS应该决定是否适合使用反射,正如我的评论、测试、测试(单元、性能测试等)一样。如果你的客户对你的表现满意,我会说去做吧。如果使用得当,它可以并且确实会带来一定的生产率增长。

就我个人而言,我会尽量不使用反省。

反射可以为扩展性和灵活性提供真正的好处。在使用反射时,性能会受到影响,但这不应该让您立即感到厌烦,尤其是当反射给您带来更多好处时。尽量少用反射,但不要以为它会伤害到你需要时使用。这篇文章在这方面很好: http://www.west-wind.com/weblog/posts/351.aspx

我的建议是总是首先尝试找到一个面向对象的解决方案,而不是在第一次机会时求助于反思。通过反射可能更容易完成一些事情,但是代码通常通过OO解决方案变得更有组织性,并且您可以消除反射的开销。

在我作为开发人员的这些年里,我只使用过两次反射…第一种方法是访问某个私有变量,以获取Web请求的上载进度。第二种方法是在从数据阅读器读取数据时动态地创建对象实例,稍后我很高兴用一个通用的解决方案替换它。