Linq to Entities与ESQL的性能

entity-framework entity-sql linq-to-entities

使用实体框架时,ESQL的性能是否优于Linq to Entities?

我更喜欢使用Linq to Entities(主要是因为强类型检查),但我的其他一些团队成员都将性能作为使用ESQL的理由。我想充分了解使用这两种方法的专家/骗子。

一般承认的答案

最明显的区别是:

Linq to Entities是强类型代码,包括很好的查询理解语法。事实上,“from”来自“选择”,允许IntelliSense帮助您。

实体SQL使用传统的基于字符串的查询,使用更熟悉的SQL语法,其中SELECT语句位于FROM之前。因为eSQL是基于字符串的,所以动态查询可以在运行时使用字符串操作以传统方式组合。

不太明显的关键区别是:

Linq to Entities允许您使用“选择新{...}”语法更改形状或将查询结果“投影”为您需要的任何形状。匿名类型,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;
}

这里这里 ,其中一个团队成员详细描述了其他更微妙的差异。


热门答案

ESQL还可以生成一些特别恶毒的sql。我不得不跟踪这样一个使用继承类的查询的问题,我发现我的pidly-little ESQL 4行被翻译成100000个字符的怪物SQL状态。

与Linq和编译代码相同的事情是更加可管理的,让我们说20行SQL。

另外,其他人提到的,Linq是强类型的,虽然在没有编辑和继续功能的情况下调试非常烦人。

广告



许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因
许可下: CC-BY-SA with attribution
不隶属于 Stack Overflow
这个KB合法吗? 是的,了解原因