Производительность Linq to Entities против ESQL

Чем больше кода вы можете покрыть проверкой времени компиляции, для меня я бы поставил более высокую оценку, чем производительность. Сказав, что на этом этапе я бы, вероятно, склонился к ESQL не только из-за производительности, но также (в настоящее время) он гораздо более гибок в том, что он может делать. Нет ничего хуже, чем использовать стек технологий, в котором нет функции, которая вам действительно нужна.

Структура сущности не поддерживает такие вещи, как настраиваемые свойства, настраиваемые запросы (когда вам нужно действительно настроить производительность) и не работает так же, как linq-to-sql (т.е. есть функции, которые просто не работают в сущности рамки).

Мое личное впечатление от Entity Framework состоит в том, что у нее большой потенциал, но она, вероятно, немного «жесткая» в реализации для использования в производственной среде в ее текущем состоянии.

Entity-SQL (eSQL) позволяет выполнять такие вещи, как динамические запросы, более легко, чем LINQ to Entities. Однако, если у вас нет сценария, который требует eSQL, я бы не решился полагаться на него вместо LINQ, потому что его будет намного сложнее поддерживать (например, больше не будет проверок во время компиляции и т. д.).

Я считаю, что LINQ также позволяет предварительно компилировать запросы, что может повысить производительность. Рико Мариани писал в блоге о производительности LINQ некоторое время назад обсуждает скомпилированные запросы.

ESQL также может генерировать некоторые особенно опасные файлы sql. Мне пришлось отследить проблему с таким запросом, который использовал унаследованные классы, и я обнаружил, что мой непонятный ESQL из 4 строк был переведен в 100000-символьную монструозную SQL-формулировку.

То же самое и с Linq, и скомпилированный код стал намного более управляемым, скажем, 20 строк SQL.

Кроме того, как упоминали другие люди, Linq сильно типизирован, хотя отлаживать без функции редактирования и продолжения очень неприятно.

ОБЪЯВЛЕНИЕ

Наиболее очевидные отличия:

Linq to Entities - это строго типизированный код, включающий удобный синтаксис понимания запросов. Тот факт, что «от» стоит перед «выбрать», позволяет IntelliSense помочь вам.

Entity 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;
}

Есть и другие, более тонкие различия, подробно описанные одним из членов команды здесь и здесь.

красивый график, показывающий сравнение производительности здесь: Анализ производительности Entity Framework не большая разница между ESQL и Entities но общие различия значительны в использовании сущностей вместо прямых запросов

Entity Framework использует два уровня сопоставления объектов (по сравнению с одним уровнем в LINQ to SQL), а дополнительное сопоставление снижает производительность. По крайней мере, в EF версии 1 разработчики приложений должны выбирать Entity Framework только в том случае, если возможности моделирования и сопоставления ORM могут оправдать эту стоимость.

Для прямых запросов я использую linq to entity, для динамических запросов я использую ESQL. Может быть, ответ не «либо / или», но «и / также».