Linq to Entities与ESQL的性能

最明显的区别是:

LINQtoEntities是强类型代码,包括良好的查询理解语法。事实上,从早于选择允许IntelliSense帮助您。

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

不太明显的关键区别是:

Linq to Entities允许您使用Select New将形状或“投影”查询结果更改为所需的任何形状…}语法。匿名类型(C 3.0的新类型)允许这样做。

不能使用实体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;
}

其中一个团队成员详细描述了其他更细微的差异 here 和 here .

ESQL还可以生成一些特别恶毒的SQL。我必须跟踪这样一个使用继承类的查询的问题,我发现我的4行小小的ESQL被翻译成了100000个字符的Monster SQL语句。

对linq做了同样的事情,编译后的代码更易于管理,比如20行SQL。

另外,正如其他人提到的,Linq是强类型的,尽管没有“编辑并继续”功能调试非常烦人。

广告

实体SQL(ESQL)允许您比LINQ to Entities更轻松地执行动态查询等操作。但是,如果您没有一个场景需要ESQL,那么我会犹豫是否依赖它而不是LINQ,因为它将很难维护(例如,不再进行编译时检查等)。

我相信Linq也允许您预编译查询,这可能会给您带来更好的性能。里科马里亚尼 blogged about LINQ performance 不久前,我们讨论了编译后的查询。

此处显示性能比较的漂亮图表: Entity Framework Performance Explored ESQL和实体之间没有太大的区别 但是,在使用实体而不是直接查询方面的总体差异是显著的

实体框架使用两层对象映射(与linq-to-sql中的单个层相比),并且额外的映射会带来性能成本。至少在EF版本1中,只有建模和ORM映射功能能够证明这一成本,应用程序设计者才应该选择实体框架。

对于我来说,编译时检查可以覆盖的代码越多,我就越重视性能。我说过,在这个阶段,我可能会倾向于ESQL,不仅仅是因为它的性能,而且它(目前)在它所能做的事情上也更加灵活。没有什么比使用一个没有你真正需要的特性的技术栈更糟糕的了。

实体框架不支持诸如自定义属性、自定义查询(当您需要真正调整性能时)之类的功能,并且与LINQ to SQL的功能不同(即,实体框架中有一些功能根本不起作用)。

我个人对实体框架的印象是,它有很多潜力,但在当前状态的生产环境中使用它的实现可能有点“僵化”。

对于直接查询,我使用的是LINQtoEntities,对于动态查询,我使用的是ESQL。也许答案不是/或,而是/也是。