应该在多大程度上使用反射？

Question

我们在一个项目中陷入了一个非常棘手的场景。我们在项目中使用了很多反射。

我们有..

• 由属性和反射驱动的验证框架
• 使用Attributes和Reflection将DataRow转换为实体对象的扩展方法，反之亦然。我们为DataTable和EntityCollections做了同样的事情。
• 在通用EntityComparer类上实现的IComparer接口，该类使用反射来比较两个实体对象。

与上述场景一样，我们在应用程序的许多其他部分使用了Reflections。使用反射后，我们注意到应用程序正在进行更多带反射的处理循环。

在我们的项目中，我们应该在多大程度上使用Reflection？在处理方面，反射受到最不利影响的项目有哪些方面？反射不会对性能产生任何影响？是否有关于使用Reflection的指南？

Answer 1

反思很强大，但也有缺点。一般来说，尝试在没有它的情况下进行编码 - 但它对于“框架”库非常有用，在这些库中，您对实际对象的了解很少/有限;例如：

• ORM / DAL工具（加载/保存任意数据）
• 数据绑定
• 序列

ad-hoc反射存在性能损失，但是如果你打算很多（在你的库中，并且在一个紧凑的循环中），你可以减轻这种情况：

• 使用Delegate.CreateDelegate（作为键入的委托;不要使用DynamicInvoke）
• 编写动态IL
• 在.NET 3.5中使用Expression

当然，任何这样的代码都应该被缓存和重用（你不想为每次调用编译+执行;只是第一次 - 其余的应该只执行）。

或者有些图书馆可以抽象出来;例如，HyperPropertyDescriptor在熟悉的PropertyDescriptor API中包装自定义IL（用于成员访问） - 使其快速但无痛。您的问题提到了数据表和实体;这听起来像this previous question一样很多，我使用HyperDescriptor做了一些指标，总结（以毫秒为单位）：

Vanilla 27179
Hyper   6997

所以我的“拿”：

应用;很少 - 作为最后的手段，一般 在您的公共库/库中;在适当的地方（注意尽可能接口等）

Answer 2

如果鞋子适合，那就戴上它...如果它解决了手头的问题，并且不会因为某种测试（最好是剖析器）测量而导致过度加工，那么不要担心它。有许多问题可以通过反思轻松解决。

我决定不使用反射的唯一指导是使用它来获取你通常无法访问的属性（即其他人的类中的私有属性）。

Answer 3

您的非功能性要求/ QoS应该决定是否适合使用反射，以及我的评论，测试，测试，测试（单元，性能测试等）。如果您的客户对表现感到满意，我会说要去做。如果使用得当，它可以而且确实可以提高生产率。

就个人而言，我会尽可能选择不使用反射。

Answer 4

反射可以为可扩展性和灵活性提供真正的好处。使用反射时性能会受到影响，但这不应该立即让你失望，特别是如果它给你带来更多好处。尽量少量使用反射，但不要认为在需要时会有很大的伤害。这篇文章很好： http://www.west-wind.com/weblog/posts/351.aspx

Answer 5

我的建议是始终首先尝试找到面向对象的解决方案，而不是在第一次机会时采用反思。使用反射来完成某些操作可能更容易，但代码通常使用OO解决方案更加有条理，并且您可以摆脱反射的开销。

在我作为开发人员的这些年里，我只使用了两次反射......首先是访问一些私有变量来获取Web请求的上传进度。第二个是从数据读取器读取时动态创建对象实例，我后来很高兴用通用解决方案替换它。