Performance of Linq to Entities vs ESQL使用Entity Framework时，ESQL的性能是否比Linq to Entities更好？ 我更喜欢对实体使用Linq(主要是由于强类型检查)，但是我的其他一些团队成员则将性能作为使用ESQL的理由。 我想全面了解使用这两种方法的优点/缺点。 最明显的区别是： Linq to Entities是强类型代码，包括不错的查询理解语法。" from"位于" select"之前的事实使IntelliSense可以为您提供帮助。 实体SQL使用传统的基于字符串的查询以及更熟悉的SQL之类的语法，其中SELECT语句位于FROM之前。因为eSQL是基于字符串的，所以动态查询可以在运行时使用字符串操作以传统方式进行组合。 不太明显的主要区别是： Linq to Entities允许您使用" select new {...}"语法将形状更改或"查询"查询结果为所需的任何形状。 C＃3.0新增的匿名类型允许这样做。 使用实体SQL不能进行投影，因为您必须始终返回ObjectQuery < T >。在某些情况下，可以使用ObjectQuery
团队成员之一在此处和此处详细描述了其他更细微的差异。 ESQL还可以生成一些特别有害的sql。我不得不跟踪使用继承类的查询的问题，我发现我的4行小巧的ESQL被翻译成100000个字符的怪兽SQL语句。 用Linq做同样的事情，并且编译后的代码更易于管理，比方说20行SQL。 另外，正如其他人所提到的，Linq是强类型的，尽管在没有编辑并继续功能的情况下进行调试非常烦人。 广告
在这里显示性能比较的漂亮图形： 实体框架使用两层对象映射(与LINQ to SQL中的单层相比)，并且附加映射会降低性能。至少在EF版本1中，仅当建模和ORM映射功能可以证明该成本合理时，应用程序设计人员才应选择实体框架。 与LINQ to Entities相比，Entity-SQL(eSQL)使您更轻松地执行诸如动态查询之类的事情。但是，如果您没有需要eSQL的场景，那么我将不愿意在LINQ上依赖它，因为它将很难维护(例如，不再进行编译时检查等)。 我相信LINQ也可以让您预编译查询，这可能会提高性能。 Rico Mariani不久前在博客中发表了有关LINQ性能的文章，并讨论了编译查询。 您可以用更多的代码来检查编译时间，这对我来说比性能要高得多。话虽这么说，在这个阶段我可能倾向于ESQL不仅是因为性能，而且(目前)它在功能上也更加灵活。没有比使用没有真正需要的功能的技术堆栈更糟糕的了。 实体框架不支持自定义属性，自定义查询(当您需要真正调整性能时)之类的功能，并且与linq-to-sql的功能不同(即，有些功能根本无法在实体中使用)框架)。 我对Entity Framework的个人印象是，它具有很大的潜力，但是在其当前状态下的生产环境中使用它的实现可能有点"僵化"。 对于直接查询，我使用linq到实体，对于动态查询，我使用ESQL。也许答案不是"要么/或"，而是" //也"。 |
