Здравствуйте, alex_public, Вы писали:


_>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта.
Еще 120000 раз. Строка подключения может быть к любому провайдеру (MS SQL, LocalBD,PostgeSql итд).
А вот после первого выполнения запрос кэшируется если это не динамический запрос.
Это тебе не наколенные творения.

https://msdn.microsoft.com/ru-ru/data/hh949853.aspx

3.2. Кэширование плана запросов

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

Кэш плана запросов совместно используется всеми экземплярами ObjectContext внутри одного домена приложения. Нет необходимости хранить экземпляр ObjectContext для получения преимуществ от кэширования плана запросов.

3.2.1. Некоторые замечания о кэшировании плана запросов
Кэш плана запросов совместно используется для всех типов запросов: Entity SQL, LINQ и объектов CompiledQuery.
По умолчанию кэширование плана запросов включено для запросов Entity SQL, выполняемых и через EntityCommand и через ObjectQuery. В EF 5.0 оно также по умолчанию включено для запросов LINQ. Кэширование планов запросов можно отключить, задав для свойства EnablePlanCaching (в EntityCommand или ObjectQuery) значение false.

Изменение значения параметра в параметризированных запросах не помешает извлечению нужных результатов из кэша. Однако изменение аспектов параметра (например, размер, точность и масштаб) приведет к извлечению другой записи из кэша.
При использовании Entity SQL строка запроса является частью ключа. Любое изменение запроса приведет к получение других записей из кэша, даже если запросы функционально эквивалентны. Сюда относится и изменение регистра, и пробелы.
При использовании LINQ из запроса формируется часть ключа. Изменение выражения LINQ приведет к созданию другого ключа.
Могут действовать и другие технические ограничения, дополнительные сведения см. в разделе Автоматические компилируемые запросы.

Вот Обычные, компилированные, и автокомпилированные запросы LINQ в Entity Framework 5

Автокомпилированные запросы LINQ

Используя EF5 уже не надо делать выбор, какой запрос использовать обычный или компилированный. И нет необходимости явно создавать объекты CompiledQuery в коде, чтобы получить преимущество предварительной компиляции запроса.

В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.

Здравствуйте, alex_public, Вы писали:


_>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта.
Еще 120000 раз. Строка подключения может быть к любому провайдеру (MS SQL, LocalBD,PostgeSql итд).
А вот после первого выполнения запрос кэшируется если это не динамический запрос.
Это тебе не наколенные творения.

https://msdn.microsoft.com/ru-ru/data/hh949853.aspx

3.2. Кэширование плана запросов

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

Кэш плана запросов совместно используется всеми экземплярами ObjectContext внутри одного домена приложения. Нет необходимости хранить экземпляр ObjectContext для получения преимуществ от кэширования плана запросов.

3.2.1. Некоторые замечания о кэшировании плана запросов
Кэш плана запросов совместно используется для всех типов запросов: Entity SQL, LINQ и объектов CompiledQuery.
По умолчанию кэширование плана запросов включено для запросов Entity SQL, выполняемых и через EntityCommand и через ObjectQuery. В EF 5.0 оно также по умолчанию включено для запросов LINQ. Кэширование планов запросов можно отключить, задав для свойства EnablePlanCaching (в EntityCommand или ObjectQuery) значение false.

Изменение значения параметра в параметризированных запросах не помешает извлечению нужных результатов из кэша. Однако изменение аспектов параметра (например, размер, точность и масштаб) приведет к извлечению другой записи из кэша.
При использовании Entity SQL строка запроса является частью ключа. Любое изменение запроса приведет к получение других записей из кэша, даже если запросы функционально эквивалентны. Сюда относится и изменение регистра, и пробелы.
При использовании LINQ из запроса формируется часть ключа. Изменение выражения LINQ приведет к созданию другого ключа.
Могут действовать и другие технические ограничения, дополнительные сведения см. в разделе Автоматические компилируемые запросы.

Вот Обычные, компилированные, и автокомпилированные запросы LINQ в Entity Framework 5

Автокомпилированные запросы LINQ

Используя EF5 уже не надо делать выбор, какой запрос использовать обычный или компилированный. И нет необходимости явно создавать объекты CompiledQuery в коде, чтобы получить преимущество предварительной компиляции запроса.

В EF5 появились автокомпилированые запросы, однако они работают, не так как CompiledQuery. Вместо написания кода, который компилирует каждый запрос, и затем вызывает его по мере необходимости, Entity Framework кеширует сгенерированный SQL в фоновом процессе. И когда выполняется LINQ, то EF находит в кеше уже скомпилированный запрос SQL и использует его по назначению.

В Entity Framework 5 было также впервые добавлено автоматическое кэширование запросов LINQ to Entities. В предыдущих выпусках платформы Entity Framework создание CompiledQuery для повышения производительности было обычной практикой, потому это делало запрос LINQ to Entities кэшируемым. Поскольку теперь кэширование осуществляется автоматически без использования CompiledQuery, мы называем эту функцию «автоматически компилируемые запросы». Дополнительные сведения о кэше плана запросов и его механиках см. в разделе Кэширование планов запросов.

Entity Framework замечает момент, когда нужно перекомпилировать запрос и делает это при вызове запроса, даже если он был скомпилирован ранее. Условия, которые приводят к повторной компиляцию запроса:
Изменение параметра MergeOption, связанного с запросом. Кэшированный запрос не будет использоваться, вместо него снова будет запущен компилятор плана, что приведет к кэшированию вновь созданного плана.
Изменение значения ContextOptions.UseCSharpNullComparisonBehavior. Эффект такой же, как и при изменении MergeOption.

Другие условия могут препятствовать запросу использовать кэш. Распространенные примеры:
Использование IEnumerable<T>.Contains<>(T value)
Привязывание запроса к другому запросу, который требует повторной компиляции.