很久以前，我正在使用反射创建一个迷你ORM。
在阅读关于反思时，我得到了类似的答案：
这完全有道理，我退出了我的迷你orm并锐化我的CTRL + C，CTRL + V键（lib旨在避免不得不一次又一次地重写我正在工作的Web应用程序中不同表的相同片段在））
多年以后由于某些原因我现在不记得了（也不想记得）我正在阅读（或试图...）Hibernate源代码，因为我想知道他们是否使用AOP来生成代码飞行并避免反射惩罚，但令我惊讶的是，我所看到的只是纯粹的反思。
这是否意味着最受欢迎的ORM框架，确切地说是在几年之前阻止我继续我天真的努力？ ：“）
我的问题是：有人可以确认我对Hibernate实现的理解吗？他们是否会动态生成字节码以提高性能？或者我们（当我们使用它时）总是支付反射惩罚（顺便说一下，如果差异在某些时间内，我们都没有注意到或抱怨过）
我们是否支付反射罚款？如果我们是，我认为值得！
问候。
答案 0 :(得分：9)
我认为重要的是要记住整个应用程序的相对成本。反射比普通对象创建慢吗？是。反射变得越来越快了吗？是。但是，在比较反射成本与线路上的成本并对数据库做一些事情时，这些点并不是非常重要，这就是hibernate的作用 - 成本完全可以忽略不计，我说我们不付出代价。
答案 1 :(得分：8)
Hibernate会让您的模型具备休眠意识。
使用Reflection有不同程度的成本。不断地查找特定类的方法特别昂贵。使用缓存副本通过反射执行方法并不是那么慢。如果考虑到反射api必须完成的任务来调用方法，那么每个部分都很慢并且消耗cpu周期都是有意义的。
典型课程中方法数量的一个因素，其中一些操作并不重要，显然这可能代价高昂。
每个反射方法相当于一些字节代码，它使用一些样板来调用目标方法以匹配反射接口。在它可以做到这一点之前，它必须执行一些健全性检查，以便它可以抱怨好消息，而不是让运行时抛出ClassCastException和类似的异常。
所有这些额外费用增加了一些成本 - 不是很多，但确实会让事情变得更慢。
在一般的缓存方法和调用不成本但速度有点慢。反射api本身会尝试缓存方法和类，但找到正确的方法等仍然是一个缓慢的操作。
答案 2 :(得分：4)
持久性和检索的成本是反射成本的很多倍。要从数据库访问记录可能需要1-10毫秒，构建带反射的对象可能需要0.001到0.01毫秒。
答案 3 :(得分：1)
NHibernate不会缓存通过反射收集的课程信息，所以你只需要第一次支付罚款吗？
答案 4 :(得分：0)
你真的通过使用NHibernate来支付反射惩罚但是如果你通过NHibernate.Bytecode.IBytecodeProvider提供所有优化的反射实现，它的可扩展性允许你避免90％的反射惩罚。