使用Entity Framework时，ESQL的性能是否比Linq to Entities更好？

我更喜欢对实体使用Linq(主要是由于强类型检查)，但是我的其他一些团队成员则将性能作为使用ESQL的理由。我想全面了解使用这两种方法的优点/缺点。

解决方案

回答

我们可以用更多的代码来检查编译时间，这对我来说比性能要高得多。话虽这么说，在这个阶段我可能倾向于ESQL不仅是因为性能，而且(目前)它在功能上也更加灵活。没有比使用没有真正需要的功能的技术堆栈更糟糕的了。

实体框架不支持自定义属性，自定义查询(当我们需要真正调整性能时)之类的功能，并且与linq-to-sql的功能不同(即，有些功能根本无法在实体中使用)框架)。

我对Entity Framework的个人印象是，它具有很大的潜力，但是在其当前状态下的生产环境中使用它的实现可能有点"僵化"。

回答

与LINQ to Entities相比，Entity-SQL(eSQL)使我们可以更轻松地执行动态查询等操作。但是，如果我们没有需要eSQL的场景，那么我将不愿在LINQ上依赖它，因为它将很难维护(例如，不再进行编译时检查等)。

我相信LINQ也可以让我们预编译查询，这可能会提高性能。 Rico Mariani不久前在博客中发表了有关LINQ性能的文章，并讨论了编译后的查询。

回答

ESQL还可以生成一些特别有害的sql。我不得不跟踪这样一个使用继承类的查询的问题，我发现我的4行小巧的ESQL被翻译成100000个字符的怪兽SQL语句。

用Linq做同样的事情，并且编译后的代码更易于管理，比方说20行SQL。

另外，正如其他人所提到的，Linq是强类型的，尽管在没有编辑并继续功能的情况下进行调试非常烦人。

广告

回答

最明显的区别是：

Linq to Entities是强类型代码，包括不错的查询理解语法。 from出现在选择之前的事实使IntelliSense可以为我们提供帮助。

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

不太明显的主要区别是：

Linq to Entities允许我们使用select new {...}语法更改形状或者将查询结果"投影"为所需的任何形状。 C3.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;
}

团队成员之一在此处和此处详细描述了其他更细微的差异。

回答

在这里显示性能比较的漂亮图形：
实体框架性能探索
ESQL和实体之间没有太大区别
但是在使用实体而不是直接查询时，总体差异很大

实体框架使用两层对象映射(与LINQ to SQL中的单层相比)，并且添加映射会降低性能。至少在EF版本1中，仅当建模和ORM映射功能可以证明该成本合理时，应用程序设计人员才应选择实体框架。

回答

对于直接查询，我使用linq到实体，对于动态查询，我使用ESQL。也许答案不是"或者/或者"，而是" //也"。