我最相关的经验是编写代码来比较大型对象模型中相同类型的任何两个数据实体的属性。把它修好，试了试，显然跑得像条狗。

我很沮丧，然后在一夜之间意识到，在不改变逻辑的情况下，我可以使用相同的算法自动生成方法来进行比较，但静态地访问属性。为了这个目的调整代码完全不花时间，而且我有能力对实体与静态代码进行深入的属性比较，每当对象模型发生变化时，只要单击按钮就可以更新静态代码。

我的观点是:在与同事的对话中，因为我已经多次指出他们使用反射可以自动生成代码来编译，而不是执行运行时操作，这通常值得考虑。

它是。但这取决于你要做什么。

我使用反射动态加载程序集(插件)，它的性能“惩罚”不是问题，因为操作是我在应用程序启动期间所做的事情。

然而，如果你在一系列嵌套循环中反射，每个循环都有反射调用，我想说你应该重新审视你的代码:)

对于“几次”操作，反射是完全可以接受的，您不会注意到任何延迟或问题。它是一种非常强大的机制，甚至被。net使用，所以我不明白为什么你不应该尝试一下。

As with all things in programming you have to balance performance cost with with any benefit gained. Reflection is an invaluable tool when used with care. I created a O/R mapping library in C# which used reflection to do the bindings. This worked fantastically well. Most of the reflection code was only executed once, so any performance hit was quite small, but the benefits were great. If I were writing a new fandangled sorting algorithm, I would probably not use reflection, since it would probably scale poorly.

很抱歉，我还没有完全回答你的问题。我的观点是，这并不重要。在适当的地方使用反射。它只是你需要学习如何以及何时使用的另一种语言功能。

和所有事情一样，这都是关于评估形势。在DotNetNuke中，有一个相当核心的组件叫做FillObject，它使用反射从数据箭头填充对象。

这是一个相当常见的场景，在MSDN上有一篇文章，使用反射将业务对象绑定到ASP。NET表单控件，涵盖了性能问题。

除了性能之外，我不喜欢在这种特定情况下使用反射的一件事是，它往往会降低快速理解代码的能力，对我来说，当你考虑到与强类型数据集或类似LINQ to SQL的数据集相比，你还失去了编译时的安全性，这似乎不值得付出努力。

如果你不是在循环中，也不用担心。

在Jeff Richter的演讲The Performance of Everyday Things中，他展示了通过反射调用一个方法要比正常调用慢1000倍。

Jeff的建议:如果需要多次调用该方法，请使用一次反射来找到它，然后将其分配给委托，然后调用委托。