Каковы плюсы и минусы использования Criteria или HQL ? Criteria API - это хороший объектно-ориентированный способ выражения запросов в Hibernate, но иногда Criteria Queries труднее понять / построить, чем HQL.
Когда вы используете критерии и когда HQL? Что вы предпочитаете в каких случаях? Или это просто вопрос вкуса?
Ответы:
Я в основном предпочитаю Criteria Queries для динамических запросов. Например, гораздо проще динамически добавлять порядок или не учитывать некоторые части (например, ограничения) в зависимости от какого-либо параметра.
С другой стороны, я использую HQL для статических и сложных запросов, потому что намного легче понять / прочитать HQL. Кроме того, я думаю, что HQL немного мощнее, например, для разных типов соединений.
источник
Существует разница с точки зрения производительности между HQL и testsQuery, каждый раз, когда вы запускаете запрос с помощью attributeQuery, он создает новый псевдоним для имени таблицы, который не отражается в последнем кеше для любой БД. Это приводит к накладным расходам на компиляцию сгенерированного SQL, что требует больше времени для выполнения.
Относительно стратегий извлечения [http://www.hibernate.org/315.html]
источник
Критерии - это объектно-ориентированный API, а HQL означает конкатенацию строк. Это означает, что применяются все преимущества объектно-ориентированного подхода:
Поскольку HQL очень похож на SQL (который большинство разработчиков уже хорошо знают), эти аргументы «не должны помнить» не имеют большого веса. Если бы HQL был более разным, то это было бы более важным.
источник
Я обычно использую Критерии, когда я не знаю, какие данные будут использоваться для ввода данных. Как и в форме поиска, где пользователь может вводить от 1 до 50 элементов, и я не знаю, что они будут искать. Очень просто добавить больше критериев, когда я проверяю, что ищет пользователь. Я думаю, что было бы немного сложнее поставить HQL-запрос в таких обстоятельствах. HQL - это здорово, когда я точно знаю, чего хочу.
источник
HQL намного легче читать, легче отлаживать с помощью таких инструментов, как плагин Eclipse Hibernate, и легче регистрировать. Критерии запросов лучше подходят для построения динамических запросов, в которых многое определяется во время выполнения. Если вы не знаете SQL, я мог бы понять, используя запросы Criteria, но в целом я предпочитаю HQL, если я знаю, что я хочу заранее.
источник
Критерии - это единственный способ указать поиск по естественному ключу, который использует специальную оптимизацию в кеше запросов второго уровня. HQL не имеет возможности указать необходимую подсказку.
Вы можете найти больше информации здесь:
источник
Критерии Api - одна из хороших концепций Hibernate. по моему мнению, это несколько моментов, с помощью которых мы можем сделать разницу между HQL и Criteria Api
источник
limit offset:rows
в HQL можно избежать с помощью SQL - инъекцииsetParameter
Чтобы использовать лучшее из обоих миров, выразительность и лаконичность HQL, а также динамический характер критериев рассмотрите возможность использования Querydsl .
Querydsl поддерживает JPA / Hibernate, JDO, SQL и коллекции.
Я поддерживаю Querydsl, поэтому этот ответ предвзят.
источник
Для меня Критерии довольно легко понять и делать динамические запросы. Но недостаток, который я до сих пор говорю, заключается в том, что он загружает все отношения многие-один и т. Д., Потому что у нас есть только три типа FetchModes, то есть Select, Proxy и Default, и во всех этих случаях он загружает многие-один (может быть, я ошибаюсь, если это поможет меня нет :))
Вторая проблема с критериями заключается в том, что он загружает полный объект, т. Е. Если я хочу просто загрузить EmpName сотрудника, он не придет с этим, он придет с полным объектом Employee, и я смогу получить из него EmpName, потому что он действительно плохо работает в отчетность . где, поскольку HQL просто загружает (не загружает ассоциации / отношения) то, что вы хотите, так многократно увеличьте производительность.
Одной из особенностей Criteria является то, что он будет защищать вас от SQL-инъекций из-за динамической генерации запросов, где, как и в HQL, поскольку ваши запросы являются либо фиксированными, либо параметризованными, поэтому они не защищены от SQL-инъекции.
Кроме того, если вы пишете HQL в файлах ur aspx.cs, то вы тесно связаны с вашим DAL.
В целом, я пришел к выводу, что есть места, где вы не можете жить без HQL, как отчеты, так что используйте их иначе, Критериями легче управлять.
источник
Критерии API
Criteria API лучше подходит для динамически генерируемых запросов. Таким образом, если вы хотите добавить фильтры предложений WHERE, предложения JOIN или изменить предложение ORDER BY или столбцы проекции, то API Criteria может помочь вам динамически генерировать запрос таким образом, чтобы также предотвратить атаки SQL-инъекций .
С другой стороны, запросы Criteria менее выразительны и могут даже привести к очень сложным и неэффективным запросам SQL, как объясняется в этой статье .
JPQL и HQL
JPQL - это стандартный язык запросов сущностей JPA, в то время как HQL расширяет JPQL и добавляет некоторые специфичные для Hibernate функции.
JPQL и HQL очень выразительны и напоминают SQL. В отличие от Criteria API, JPQL и HQL упрощают прогнозирование базового SQL-запроса, генерируемого поставщиком JPA. Также гораздо проще просматривать свои HQL-запросы, чем критерии.
Стоит отметить, что выбор сущностей с помощью JPQL или Criteria API имеет смысл, если вам нужно изменить их. В противном случае, прогноз DTO является гораздо лучшим выбором.
Вывод
Если вам не нужно изменять структуру запроса сущности, используйте JPQL или HQL. Если вам нужно изменить критерии фильтрации или сортировки или изменить прогноз, используйте Criteria API.
Однако то, что вы используете JPA или Hibernate, не означает, что вам не следует использовать собственный SQL. SQL-запросы очень полезны, и JPQL и Criteria API не являются заменой SQL. Проверьте эту статью для более подробной информации по этой теме.
источник
Для меня самая большая победа в Criteria - это API-интерфейс примеров, где вы можете передать объект, а hibernate создаст запрос на основе этих свойств объекта.
Кроме того, у API критериев есть свои особенности (я считаю, что команда hibernate перерабатывает API), например:
Я склонен использовать HQL, когда мне нужны запросы, похожие на sql (удалить из Users, где status = 'заблокирован'), и я склонен использовать критерии, когда я не хочу использовать добавление строк.
Еще одним преимуществом HQL является то, что вы можете определить все свои запросы заранее и даже экспортировать их в файл или около того.
источник
Критерии API предоставляют одну особенность, которую не предоставляет ни SQL, ни HQL. то есть. это позволяет проверять время компиляции запроса.
источник
Вначале мы использовали главным образом критерии в нашем приложении, но после его замены на HQL из-за проблем с производительностью.
В основном мы используем очень сложные запросы с несколькими объединениями, что приводит к нескольким запросам в критериях, но очень оптимизировано в HQL.
Дело в том, что мы используем только несколько свойств на конкретном объекте, а не на полных объектах. С критериями проблема заключалась также в конкатенации строк.
Допустим, если вам нужно отобразить имя и фамилию пользователя в HQL, это довольно просто,
(name || ' ' || surname)
но в Crteria это невозможно.Чтобы преодолеть это, мы использовали ResultTransormers, где были методы, где такая конкатенация была реализована для достижения необходимого результата.
Сегодня мы в основном используем HQL следующим образом:
поэтому в нашем случае возвращаемые записи являются картами необходимых свойств.
источник
источник
источник
CriteriaUpdate<T>
иCriteriaDelete<T>
для справки.Критерии запроса для динамически мы можем построить запрос на основе наших входных данных. В случае Hql-запроса является статическим запросом, как только мы создаем, мы не можем изменить структуру запроса.
источник
Я не хочу пнуть здесь мертвую лошадь, но важно отметить, что запросы Criteria в настоящее время устарели. Используйте HQL.
источник
Я также предпочитаю Критерии запросов для динамических запросов. Но я предпочитаю hql для запросов на удаление, например, если удаляются все записи из дочерней таблицы для родительского идентификатора 'xyz', это легко достигается с помощью HQL, но для критериев API сначала мы должны запустить n номер запроса на удаление, где n - это номер дочернего элемента. таблица записей.
источник
Большинство ответов здесь вводят в заблуждение и упоминают, что
Criteria Queries
они медленнее, чем этоHQL
, на самом деле это не так.Если вы углубитесь и выполните некоторые тесты, вы увидите, что Criteria Queries работают намного лучше, чем обычный HQL .
А также с Criteria Query вы получаете объектно-ориентированное управление, которого нет в HQL .
Для получения дополнительной информации прочитайте этот ответ здесь .
источник
Есть другой способ. Я закончил с созданием синтаксического анализатора HQL на основе оригинального синтаксиса hibernate, чтобы он сначала анализировал HQL, а затем мог динамически вводить динамические параметры или автоматически добавлять некоторые общие фильтры для запросов HQL. Работает отлично!
источник
Этот пост довольно старый. Большинство ответов говорят о критериях Hibernate, а не о критериях JPA. В JPA 2.1 добавлены CriteriaDelete / CriteriaUpdate и EntityGraph, которые определяют, что именно нужно получить. Критерии API лучше, так как Java - ОО. Вот почему JPA создается. Когда JPQL скомпилирован, он будет преобразован в дерево AST (модель OO) перед переводом в SQL.
источник
HQL может вызвать проблемы безопасности, такие как SQL-инъекция.
источник