При использовании Entity Framework ESQL работает лучше, чем Linq для Entities?
Я бы предпочел использовать Linq для Entities (главным образом из-за проверки сильного типа), но некоторые из моих других членов команды ссылаются на производительность как на причину использования ESQL. Я хотел бы получить полное представление о том, что pro/con использует любой метод.
Наиболее очевидными отличиями являются:
Linq to Entities - это строго типизированный код, включающий в себя хороший синтаксис понимания запроса. Тот факт, что "от" доходит до "выбора", позволяет IntelliSense помочь вам.
Entity SQL использует традиционные строковые запросы с более знакомым SQL, подобным синтаксису, где инструкция SELECT предшествует FROM. Поскольку eSQL основан на строках, динамические запросы могут быть составлены традиционным способом во время выполнения с использованием строковых манипуляций.
Менее очевидное ключевое различие:
Linq to Entities позволяет вам изменять форму или "проектировать" результаты вашего запроса в любую форму, которая вам нужна, с помощью синтаксиса "select new {...}". Анонимные типы, новые для С# 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;
}
Есть и другие более тонкие отличия, описанные одним из участников команды здесь и .
ESQL также может генерировать некоторые особо злобные sql. Мне пришлось отслеживать проблему с таким запросом, который использовал унаследованные классы, и я узнал, что мой pidly-little ESQL из 4 строк был переведен в 100000 символов монстра SQL statetement.
То же самое с Linq и скомпилированным кодом было гораздо более управляемым, допустим, 20 строк SQL.
Плюс, что другие люди упомянули, Linq сильно тип, хотя очень раздражает отладка без функции редактирования и продолжения.
AD
Entity-SQL (eSQL) позволяет вам делать такие вещи, как динамические запросы, легче, чем LINQ to Entities. Однако, если у вас нет сценария, который требует eSQL, я бы не решался полагаться на него по LINQ, потому что его будет намного сложнее поддерживать (например, больше не проверять время компиляции и т.д.).
Я полагаю, что LINQ позволяет предварительно скомпилировать ваши запросы, что может дать вам лучшую производительность. Rico Mariani в блоге о производительности LINQ некоторое время назад и обсуждает скомпилированные запросы.
хороший график, показывающий сравнение производительности здесь: Изучена производительность платформы Entity между ESQL и объектами не наблюдается различий но общие различия, существенные при использовании сущностей по прямым запросам
Entity Framework использует два слоя сопоставления объектов (по сравнению с одним слоем в LINQ to SQL), а дополнительное сопоставление имеет затраты на производительность. По крайней мере, в версии EF 1 разработчики приложений должны выбрать Entity Framework только в том случае, если возможности сопоставления моделирования и ORM могут оправдать эту стоимость.
Чем больше кода вы можете покрыть с проверкой времени компиляции, тем я бы поставил более высокую премию, чем производительность. Сказав, что на этом этапе я, вероятно, склоняюсь к ESQL не только из-за производительности, но также и (в настоящее время) намного более гибким в том, что он может сделать. Там нет ничего хуже, чем использование стека технологий, у которого нет нужной вам функции.
Структура сущности не поддерживает такие вещи, как пользовательские свойства, пользовательские запросы (когда вам нужно действительно настраивать производительность) и не работает так же, как linq-to-sql (т.е. есть функции, которые просто не работают в структуре сущности).
Мое личное впечатление о платформе Entity Framework заключается в том, что существует большой потенциал, но, вероятно, это немного "жестко" в реализации, которая используется в рабочей среде в текущем состоянии.
Для прямых запросов я использую linq для сущностей, для динамических запросов я использую ESQL. Возможно, ответ не является и/или, но и/.