Повторное использование LINQ-SQL - CompiledQuery.Compile

Ответ 1

Резюме Exec:

Expression.Compile генерирует CLR-метод, если CompiledQuery.Compile создает делегат, который является заполнителем для SQL.

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

О фактах:

Expression<Func<TaskFile, double>> TimeSpent = (t =>
    t.TimeEntries.Sum(te => (te.DateEnded - te.DateStarted).TotalHours));

Затем мы можем использовать приведенное выше в запросе LINQ, как показано ниже:

TaskFiles.Select(t => new {
    t.TaskId,
    TimeSpent = TimeSpent(t),
})

(Примечание. Возможно, вы использовали тип Func<> для TimeSpent. Это дает ту же ситуацию, что и в вашем сценарии, как описано в параграфе ниже. Обязательно прочитайте и поймите это).

Нет, это не скомпилируется. Выражения не могут быть вызваны (TimeSpent - это выражение). Сначала их необходимо скомпилировать в делегат. То, что происходит под капотом при вызове Expression.Compile(), заключается в том, что Дерево выражений скомпилировано до IL, которое вводится в DynamicMethod, для которого вы затем получаете делегат.

Следующие действия будут работать:

var q = TaskFiles.Select(t => new {
    t.TaskId,
    TimeSpent = TimeSpent.Compile().DynamicInvoke()
});  

Это приводит к ожидаемому результату, за исключением того, что запрос на строку сгенерированный для подключенного выражения. Это видно в LINQPad. Нехорошо.

Почему это происходит? Ну, Linq To Sql нужно будет извлечь все TaskFiles, обезводить TaskFile экземпляры, а затем запустить селектор против него в памяти. Вероятно, вы получаете запрос на TaskFile, потому что они содержат одно или несколько сопоставлений 1: m.

В то время как LTS позволяет проецировать в памяти для выбора, он не делает этого для Wheres (цитата, это, насколько мне известно). Когда вы об этом думаете, это имеет смысл: вероятно, вы будете передавать намного больше данных, фильтруя всю базу данных в памяти, а затем преобразовывая подмножество в памяти. (Хотя он создает проблемы с производительностью запросов, как вы видите, что нужно знать при использовании ORM).

CompiledQuery.Compile() делает что-то другое. Он компилирует запрос в SQL, а возвращаемый делегат - это только заполнитель Linq to SQL, который будет использоваться внутренне. Вы не можете "вызывать" этот метод в среде CLR, его можно использовать только как node в другом дереве выражений.

Итак, почему LTS генерирует эффективный запрос с выражением CompiledQuery.Compile 'd then? Потому что он знает, что делает это выражение node, потому что он знает SQL за ним. В случае Expression.Compile это просто a InvokeExpression, который вызывает DynamicMethod, как я объяснял ранее.

Зачем нужен параметр DataContext? Да, это более удобно для создания полных запросов, но это также связано с тем, что компилятору дерева выражений нужно знать Mapping для использования для генерации SQL. Без этого параметра было бы больно найти это отображение, поэтому это очень разумное требование.

Ответ 2

Я удивлен, почему у вас пока нет ответов. CompiledQuery.Compile компилирует и кэширует запрос. Вот почему вы видите только один создаваемый запрос.

Не только это НЕ взломать, это рекомендуемый способ!

Ознакомьтесь с этими статьями MSDN для получения подробной информации и примера:

Скомпилированные запросы (LINQ to Entities)
Практическое руководство. Сохранение и повторное использование запросов (LINQ to SQL)

Обновление: (превышение лимита комментариев)
Я сделал рытье в отражателе, и я вижу, что используется DataContext. В вашем примере вы просто не используете его.

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

Если ваш запрос не изменяется, но только DataContext и Parameters, и если вы планируете его использовать повторно, CompiledQuery.Compile поможет. Это дорого для компиляции, поэтому для одного запроса нет никакой выгоды.

Ответ 3

TaskFiles.Select(t => new {
  t.TaskId,
  TimeSpent = TimeSpent(t),
})

Это не запрос LinqToSql, поскольку нет экземпляра DataContext. Скорее всего, вы запрашиваете некоторый EntitySet, который не реализует IQueryable.

Пожалуйста, опубликуйте полные заявления, а не фрагменты инструкции. (Я вижу недопустимую запятую, точку с запятой, отсутствие назначения).

Кроме того, попробуйте следующее:

var query = myDataContext.TaskFiles
  .Where(tf => tf.Parent.Key == myParent.Key)
  .Select(t => new {
    t.TaskId,
    TimeSpent = TimeSpent(t)
  });
// where myParent is the source of the EntitySet and Parent is a relational property.
//  and Key is the primary key property of Parent.