我们在一个项目中遇到了一个非常棘手的场景。我们在项目中使用了很多反射。
我们有..
- 由属性和反射驱动的验证框架
- 使用属性和反射将 DataRow 转换为实体对象的扩展方法，反之亦然。我们为 DataTable 和 EntityCollections 做了同样的事情。
- IComparer 接口(interface)在使用反射比较两个实体对象的通用 EntityComparer 类上实现。
像上面的场景一样，我们在应用程序的许多其他部分使用了反射。使用反射后，我们注意到应用程序使用反射占用了更多的处理周期。
在我们的项目中我们应该在多大程度上使用反射？就处理而言，反射对项目的哪些方面影响最大？哪里反射不会对性能产生任何影响？是否有任何使用反射的指南？
最佳答案
反射功能强大，但也有缺点。一般来说，尝试在没有它的情况下进行编码 - 但它对于“框架”库非常有用，在这些库中您对实际对象的了解很少/有限；例如:
- ORM/DAL 工具(加载/保存任意数据)
- 数据绑定(bind)
- 序列化
临时反射会导致性能下降，但如果您打算很多(在您的库中，并且在一个紧密的循环中)，您可以减轻这种情况:
- 通过使用
Delegate.CreateDelegate(作为类型化委托(delegate)；不要使用DynamicInvoke) - 通过编写动态 IL
- 在 .NET 3.5 中使用
Expression
当然，任何此类代码都应该被缓存并重新使用(您不想为每次调用编译+执行；只执行第一个 - 其余的应该只执行)。
或者有库对此进行抽象；例如，HyperPropertyDescriptor在熟悉的 PropertyDescriptor API 中包装自定义 IL(用于成员访问)- 使其非常快速但无痛。您的问题提到了数据表和实体；这听起来很很多像this previous question ，其中我使用 HyperDescriptor 做了一些指标，带有摘要(以毫秒为单位):
Vanilla 27179
Hyper 6997
所以我的“接受”:
- 在应用程序中；很少 - 作为最后的手段，通常
- 在您的公共(public)图书馆；在适当的情况下(注意接口(interface)等在可能的情况下更可取)
关于.net - 应该在多大程度上使用反射？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1115453/