В зависимости от значения параметров поиска linq может создавать различные SQL-запросы, если в предложении where есть условная логика.
Как насчет того, чтобы воспользоваться преимуществом прекомпиляции запроса в этом случае и учесть условие?Похоже, нужно создать более одного предварительно скомпилированного запроса.И затем корректный предварительно скомпилированный запрос должен быть запущен в зависимости от входных параметров.
Большинство записей / статей блога весьма ограничены и имеют дело с прекомпиляцией запроса linq, только когда в запросе нет условной логики.И затем они просто отмечают мелким шрифтом, что прекомпиляция запроса не всегда полезна, и вам может быть лучше не использовать его.
Например, если в запросе linq есть один условный параметр, тогда 2 разных запроса SQL могутбыть построеннымТак почему бы не скомпилировать эти два запроса linq и повторно использовать их соответственно?Я уверен, что если вы повторно используете разные предварительно скомпилированные запросы несколько раз, это сэкономит некоторую вычислительную мощность в самом конце.
Причина, по которой я поднимаю этот вопрос, заключается в том, что я сейчас работаю над веб-приложением с довольносложные формы поиска.Типичная форма поиска может иметь около 20 полей (строки, целые числа, выпадающие списки и т. Д.).95% поисковых запросов используют параметры по умолчанию.Но другие поиски используют несколько параметров поиска.Базовый запрос linq учитывает все параметры, синтаксис довольно приятный, особенно с целыми числами, допускаемыми обнуляемым, например: .Where (row =>! Model.id.HasValue || row.id == model.id).Таким образом, два разных запроса SQL могут быть произведены в зависимости от того, Int?Идентификатор имеет значение или нет.И мое предложение where гораздо сложнее - оно требует около 20 условных параметров.
Итак, вопрос в том, будет ли это выгодно с точки зрения производительности, если я предварительно скомпилирую запрос linq в зависимости от условных параметров?Это приведет к предварительно скомпилированному запросу для каждой комбинации параметров.Таким образом, параметры должны быть проанализированы, чтобы определить, существует ли уже предварительно скомпилированный запрос, и его можно использовать, или если необходимо создать новый предварительно скомпилированный запрос.
Это решение может быть предпринято на один шаг позже.Таким образом, при запуске веб-приложения все запросы linq будут предварительно предварительно скомпилированы для всех возможных комбинаций условных параметров.Или, чтобы уменьшить количество предварительно скомпилированных запросов, я мог бы использовать прекомпиляцию для нескольких наиболее часто используемых комбинационных параметров и принудительно использовать не скомпилированные запросы для более сложных сценариев.