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

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

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

反射性能将取决于实现(重复调用应该被缓存，例如:entity.GetType(). getproperty ("PropName"))。由于我每天看到的大多数反射都用于从数据阅读器或其他存储库类型结构填充实体，所以我决定在反射用于获取或设置对象属性时对其性能进行基准测试。

我设计了一个测试，我认为是公平的，因为它缓存所有重复的调用，只乘以实际的SetValue或GetValue调用。性能测试的所有源代码都在bitbucket中:https://bitbucket.org/grenade/accessortest。审查是受欢迎和鼓励的。

我得出的结论是，在反射实现做得很好的情况下，在数据访问层中删除反射是不实际的，也不能提供明显的性能改进。

上图展示了我的小基准测试的输出，并显示了优于反射的机制，只有在100,000次循环之后才会明显表现出来。大多数dal一次只返回几百行或数千行，在这些级别反射执行得很好。

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的数据集相比，你还失去了编译时的安全性，这似乎不值得付出努力。

我想你会发现答案是，这要看情况。如果您想把它放在任务列表应用程序中，这不是什么大问题。如果你想把它放在Facebook的持久性库中，这是一件大事。