Производительность Linq для сущностей против ESQL

Question

При использовании Entity Framework ESQL работает лучше, чем Linq to Entities?

Я бы предпочел использовать Linq to Entities (в основном из-за строгой проверки типов), но некоторые другие члены моей команды называют производительность в качестве причины для использования ESQL. Я хотел бы получить полное представление о преимуществах / недостатках использования любого из этих методов.

Answer 1

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

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

Entity SQL использует традиционные строковые запросы с более знакомым SQL-подобным синтаксисом, где оператор SELECT предшествует FROM. Поскольку eSQL основан на строках, динамические запросы могут быть составлены традиционным способом во время выполнения, используя манипуляции со строками.

Менее очевидное ключевое отличие:

Linq to Entities позволяет вам изменить форму или «спроецировать» результаты вашего запроса на любую нужную вам форму с помощью синтаксиса «select new {...}». Анонимные типы, впервые появившиеся в C # 3.0, позволили это.

Проецирование невозможно с использованием Entity SQL, поскольку вы всегда должны возвращать ObjectQuery . В некоторых сценариях возможно использовать ObjectQuery , однако вы должны обойти тот факт, что .Select всегда возвращает ObjectQuery . Смотрите код ниже ...

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

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

Answer 2

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

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

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

AD

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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