Может ли IQueryable <> содержать только инструкции (в форме дерева выражений) о том, как получить начальную последовательность, но не может

Question

1)

public class Query<T> : IQueryable<T> ... 
{
              ... 
   public IEnumerator<T> GetEnumerator() 
   {
      return((IEnumerable<T>)this.provider.Execute(this.expression)).GetEnumerator();
   }
}

Query<string> someQuery = new Query<string>();

someQuery.Expression содержит дерево выражений, связанное с этим конкретным экземпляром IQueryable, и, таким образом, описывает, как получить начальную последовательность элементов. В следующем примере переменная initialSet фактически содержит последовательность строк:

    string[] initialSet = { };
    var results1 = from x in initialSet
                   where ...
                   select ...;

a) Может ли someQuery также содержать последовательность строк или она может содержать только инструкции (в форме дерева выражений) о том, как получить эту начальную последовательность строк из некоторой БД?

b) Я предполагаю, что даже если someQuery на самом деле содержит начальную последовательность строк, она бесполезна для операторов Where и Select, поскольку они никогда не будут работать с этой последовательностью строк, но вместо этого их работа состоит только в том, чтобы создавать запросы или запрашивать запросы к выполнению (вызывая IQueryProvider.Execute)? И по этой причине someQuery всегда должен содержать дерево выражений, описывающее, как получить начальную последовательность строк, даже если someQuery уже содержит эту начальную последовательность?

Спасибо

EDIT:

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

d) Несмотря на это, я полагаю, даже если поставщик запросов поддерживает фактические элементы, он может поддерживать их только для первоначального запроса? Таким образом, если мы применяем операторы Linq-to-entity или Linq-to-Sql к этому начальному запросу, я предполагаю, что провайдеру придется запросить базу данных. Таким образом, если мое предположение верно, то ответ на b) будет даже если запрос содержит действительные элементы, когда мы вызываем Where для someQuery (someQuery.Where), поставщик запросов должен будет извлекать результаты из БД, даже если этот поставщик запросов уже содержит все элементы someQuery?

e) Я только начал изучать Linq-to-entity, поэтому мой вопрос может быть слишком общим, но как EF справляется со всем этим? Другими словами, когда ObjectSet<T>, возвращаемый некоторым EF API (например, ObjectContext), содержит фактические элементы и когда он (если когда-либо) содержит только логику для извлечения элементов из некоторого источника данных (например, БД)?

f) Кроме того, даже если ObjectSet<T> (возвращаемое, скажем, ObjectSet) действительно содержит фактические элементы, я предполагаю, что если мы применим к нему оператор Where (ObjectSet<T>.Where), поставщик запросов всегда должен будет получать результаты из DB

Answer 1

а) Обычно вы не создадите Query<T> самостоятельно - провайдер запросов.Он может включить любую информацию, которую хочет.Скорее всего, он просто содержит информацию о том, с какой таблицей он связан.

b) Это полностью зависит от поставщика запросов.Как вы видели в другом вопросе, поставщик запросов может в конечном итоге распознать, когда он достиг Query<T>, поэтому он может знать, чтобы запросить Query<T> для его строк, если это было уместно.

c) Поставщик запросов не может обычно содержать сами данные - но это может сделать. Это зависит от поставщика.

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

e, f) Понятия не имею, я никогда не использовал Entity Framework в гневе.

Ответ на почти все ваши вопросы по этой теме: "это зависит от поставщика запросов ".Для получения подробной информации о конкретном поставщике запросов вы должны прочитать документацию для этого поставщика.Это должно объяснять, когда он будет делать запросы и т. Д. Неясно, что вы действительно пытаетесь получить от этих вопросов - но если вы после полной реализации изучаете, есть много поставщиков LINQ с открытым исходным кодом.Возможно, вы захотите взглянуть на NHibernate, например.