实体框架是否使用反射和损害性能？

Question

我最终有两个领域,每个领域都有一些关于实体框架的问题,但是让我给出一些背景知识,以便你知道我要求提供这些信息的背景.

在我的工作地点,我的团队正计划完全重写我们的应用程序结构,以便我们能够遵循更现代的标准.这种重写包括一个全新的数据层项目.在这个项目中,大多数团队都想使用Entity Framework.我也想使用它,因为我在个人项目中使用它非常熟悉它.但是,一个团队成员强烈反对这一点,并指出实体框架使用反射并杀死性能.他的另一个论点是EF使用生成的SQL,其效率远远低于存储过程.我不太熟悉EF的内部工作,我的搜索没有发现任何非常有用的东西.

这是我的问题.我试图让它们尽可能具体.如果您需要澄清,请询问.

问题1问题 - 反思

1. 关于使用反射和伤害性能的EF,这是真的吗？
2. EF如果使用反射,它在哪里？
3. 有没有比较性能的资源？我可以用什么来客观地比较.NET中的数据访问技术,然后将它呈现给我的团队？

问题2问题 - SQL

1. 这有什么影响？
2. 是否可以使用存储过程来填充EF实体？
3. 还有一些资源可以将生成的查询与存储过程进行比较,以及使用存储过程填充实体(如果可以)的含义是什么？

---

我自己做了一些搜索,但没有提出太多关于引擎盖下的EF.任何帮助深表感谢.

编辑

这些都是一些非常有用的答案.谢谢.我将暂时搁置这个问题一段时间,以便可以提供一些文章和其他外部资源的硬性参考.也许这个问题将有助于未来的人在我的困境中.

Answer 1

是的,它确实像许多其他ORM(NHibernate)和有用的框架(DI工具).例如,没有Reflection,WPF无法工作.

虽然使用Reflection的性能影响在.NET 1.0以来的最近10年中没有发生太大变化(尽管已经有了改进),但随着硬件速度的提高和可读性的普遍趋势,它现在变得越来越不受关注.

请记住,主要的性能影响是在反映aka绑定时将类型元数据读入xxxInfo(例如MethodInfo),这发生在应用程序启动时.

调用反射方法肯定是慢的,但不是一个问题.

UPDATE

我用Reflector来查看EF的源代码,我可以确认它大量使用Reflection.

Answer 2

问题1的答案：

您可以通过检查生成的文件来准确查看 EF 输出的内容Foo.Designer.cs。您将看到生成的容器不使用反射，但大量使用泛型。

以下是实体框架确实使用反射的地方：

1. 该Expression<T>接口用于创建 SQL 语句。中的扩展方法System.Linq基于表达式树的思想，它使用中的类型System.Reflection来表示函数调用和类型等。
2. 当您使用这样的存储过程时： db.ExecuteStoreQuery<TEntity>("GetWorkOrderList @p0, @p1", ...)，实体框架必须填充实体，并且至少必须检查TEntity所提供的类型是否被跟踪。

问题2的答案：

确实，查询通常看起来很奇怪，但这并不表明它的效率较低。您将很难想出一个实际查询计划更差的查询。

最重要的是，您当然可以使用存储过程，甚至是带有实体框架的内联 SQL 来进行查询以及创建、更新和删除。

在旁边：

即使它到处都使用反射，并且不允许您使用存储过程，为什么这会成为不使用它的理由呢？我认为你需要让你的同事证明这一点。