Производительность Linq для объектов по сравнению с ESQL

StackOverflow https://stackoverflow.com/questions/38647

Вопрос

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

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

Это было полезно?

Решение

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

Linq to Entities - это строго типизированный код с хорошим синтаксисом понимания запросов. Дело в том, что & # 8220; из & # 8221; предшествует & # 8220; выберите & # 8221; позволяет IntelliSense помочь вам.

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

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

Linq to Entities позволяет изменить форму или " project " результаты вашего запроса в любой нужной форме с помощью & # 8220; выберите новый {...} & # 8221; синтаксис. Анонимные типы, впервые в C # 3.0, позволили это.

Проецирование невозможно с использованием Entity SQL, так как вы всегда должны возвращать ObjectQuery < T > ;. В некоторых сценариях возможно использовать ObjectQuery & Lt; object & Gt; однако вы должны обойти тот факт, что .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-запросы.Мне пришлось отследить проблему с таким запросом, который использовал унаследованные классы, и я обнаружил, что мой крошечный ESQL из 4 строк был переведен в чудовищный SQL statetement объемом 100000 символов.

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

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

РЕКЛАМА

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top