使用实体框架时,ESQL的性能是否优于Linq to Entities?
我更喜欢使用Linq to Entities(主要是因为强类型检查),但我的其他一些团队成员都将性能作为使用ESQL的理由。我想充分了解使用这两种方法的专业人士/想法。
答案 0 :(得分:17)
最明显的区别是:
Linq to Entities是强类型代码,包括很好的查询理解语法。事实上“from”出现在“select”之前,IntelliSense可以帮助你。
实体SQL使用传统的基于字符串的查询,使用更熟悉的SQL语法,其中SELECT语句位于FROM之前。因为eSQL是基于字符串的,所以动态查询可以在运行时使用字符串操作以传统方式组合。
不太明显的关键区别是:
Linq to Entities允许您使用“select new {...}”语法更改形状或将查询结果“投影”为您需要的任何形状。匿名类型,C#3.0的新功能,允许这样做。
使用Entity SQL无法进行投影,因为您必须始终返回ObjectQuery< T>。在某些情况下,可以使用ObjectQuery< object>但是你必须解决这个问题.Select总是返回ObjectQuery< DbDataRecord>。请参阅下面的代码......
ObjectQuery<DbDataRecord> query = DynamicQuery(context,
"Products",
"it.ProductName = 'Chai'",
"it.ProductName, it.QuantityPerUnit");
public static ObjectQuery<DbDataRecord> DynamicQuery(MyContext context, string root, string selection, string projection)
{
ObjectQuery<object> rootQuery = context.CreateQuery<object>(root);
ObjectQuery<object> filteredQuery = rootQuery.Where(selection);
ObjectQuery<DbDataRecord> result = filteredQuery.Select(projection);
return result;
}
答案 1 :(得分:3)
ESQL也可以生成一些特别恶毒的SQL。我不得不跟踪这样一个使用继承类的查询的问题,我发现我的pidly-little ESQL 4行被翻译成100000个字符的怪物SQL状态。
与Linq和编译代码相同的事情是更加可管理的,让我们说20行SQL。
另外,其他人提到,Linq是强类型的,虽然在没有编辑和继续功能的情况下调试非常烦人。
AD
答案 2 :(得分:2)
Entity-SQL(eSQL)允许您比LINQ to Entities更容易地执行动态查询等操作。但是,如果你没有需要eSQL的场景,我会犹豫是否要依赖LINQ,因为维护起来要困难得多(例如没有更多的编译时检查等)。
我相信LINQ允许您预编译您的查询,这可能会为您提供更好的性能。 Rico Mariani blogged about LINQ performance不久前回来讨论编译的查询。
答案 3 :(得分:2)
显示性能比较的漂亮图表: Entity Framework Performance Explored ESQL和实体之间没有太大区别 但使用实体而非直接查询的总体差异显着
实体框架使用两层对象映射(与LINQ to SQL中的单个层相比),并且附加映射具有性能成本。至少在EF版本1中,应用程序设计人员只有在建模和ORM映射功能可以证明该成本合理时才应选择实体框架。
答案 4 :(得分:1)
对于我来说,编译时检查可以覆盖的代码越多,我就会比性能更高。虽然在这个阶段我可能会倾向于ESQL,不仅仅是因为性能,而且(目前)它还可以做得更灵活。没有什么比使用没有你真正需要的功能的技术堆栈更糟糕了。
实体框架不支持自定义属性,自定义查询(当你需要真正调整性能时),并且功能与linq-to-sql不同(即有些功能根本不起作用)在实体框架中)。
我对实体框架的个人印象是存在很多潜力,但在其当前状态的生产环境中使用它的实现可能有点“僵化”。
答案 5 :(得分:0)
对于直接查询,我使用linq实体,对于动态查询,我使用的是ESQL。也许答案不是/或,而是/也是。