Производительность Linq для сущностей против ESQL
При использовании Entity Framework ESQL работает лучше, чем Linq to Entities?
Я бы предпочел использовать Linq to Entities (в основном из-за строгой проверки типов), но некоторые другие члены моей команды ссылаются на производительность в качестве причины для использования ESQL. Я хотел бы получить полное представление о плюсах / минусах использования любого метода.
6 ответов
Наиболее очевидные различия:
Linq to Entities - это строго типизированный код с хорошим синтаксисом понимания запросов. Тот факт, что "от" предшествует "выбору", позволяет IntelliSense вам помочь.
Entity SQL использует традиционные строковые запросы с более знакомым SQL-подобным синтаксисом, где оператор SELECT предшествует FROM. Поскольку eSQL основан на строках, динамические запросы могут быть составлены традиционным способом во время выполнения, используя манипуляции со строками.
Менее очевидное ключевое отличие:
Linq to Entities позволяет вам изменить форму или "спроецировать" результаты вашего запроса на любую нужную вам форму с помощью синтаксиса "select new{... }". Анонимные типы, впервые появившиеся в C# 3.0, позволили это.
Проекция невозможна при использовании Entity SQL, так как вы всегда должны возвращать 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;
}
Есть и другие, более тонкие различия, подробно описанные одним из членов команды здесь и здесь.
ESQL также может генерировать некоторые особенно порочные sql. Мне пришлось отследить проблему с таким запросом, в котором использовались унаследованные классы, и я обнаружил, что мой маленький ESQL из 4 строк был переведен в формулировку SQL монстра из 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. Может быть, ответ не / или, но и / также.