Является ли HibernateCallback лучшим для выполнения SQL / процедур?

Question

Я работаю над веб-приложением, принадлежащим производителю автомобилей, разработанным в Spring-Hibernate с базой данных MS SQL Server 2005.

Существует три вида использования:

1) Через это приложение конечные пользователи могут запросить создание автомобиля, автобуса, грузовика и т. Д. Через веб-интерфейсы. Когда пользователь входит в систему, отображается форма HTML для получения технических характеристик автомобиля, например, если кто-то хочет запросить автомобиль, он может указать данные о марке / модели двигателя, шинах, деталях шасси и т. Д. И отправить форму. Я использую Hibernate для сохранения, то есть у меня есть Car Car Entity, который сохраняется в БД для каждого такого запроса.

2) В этой части приложения рассматривается создание отчетов. Эти отчеты в основном делятся с количеством запросов, полученных за день, и сводкой. В некоторых отчетах рассчитывается время выполнения отдельных запросов на создание транспортных средств.

Я использую простые вызовы JDBC с Preparedstatement (если отчет может быть сгенерирован с помощью SQL), Callablestatement (если отчет достаточно сложный и требует процедуры / функции БД для получения всех деталей) и HibernateCallback для выполнения SQL / процедур и вывод информации на экран.

3) Поиск: эта часть приложения позволяет пользователям ensd искать данные различных запросов, например, сколько транспортных средств было запрошено за год и т. Д. Я использую процедуру DB с CallableStatement .. Как только снова выполняю эти процедуры в HibernateCallback , заполнение и возврат результатов поиска по GUI в POJO.

Я использую собственный SQL в (2) и (3) выше, потому что для целей отчетности / поиска структура данных отчета, отображаемая на экране, не соответствует ни одной из моих сущностей. Например, сущность Car имеет более 100 атрибутов сама по себе, но для целей отчетности мне не нужно более 10 из них ... так что я просто загружаю все 100 атрибутов, что не имеет никакого смысла, так почему бы не использовать простой SQL и получить только данные, необходимые для отображения на экране.

Точно так же для поиска мне пришлось писать процедуры / функции, потому что алгоритм поиска не прост, и Hibernate не имеет возможности написать что-то вроде хранимой процедуры.

Это нормально работает для прото-типа, однако я хотел бы знать,

а. Если мой подход к использованию собственных SQL-процедур и процедур БД подходит для случаев 2 и 3, основан на моем мнении. б. Также является ли правильное выполнение SQL-запросов в HibernateCallback?

Нужна помощь специалиста.

Answer 1

Вы должны стремиться использовать как можно больше HQL, если у вас нет веских аргументов (например, производительности, но сначала сделайте тест).Если использование собственных запросов становится чрезмерным, вам следует подумать о том, был ли Hibernate хорошим выбором.

Обратите внимание на несколько вещей:

• вы можете иметь собственные запросы ихранимые процедуры, которые приводят к Hibernate сущности.Вам просто нужно сопоставить запрос / storproc вызов с классом и вызвать его с помощью session.createSQLQuery(queryName)

• Если вам действительно нужно создатьСобственные запросы во время выполнения, новейшая версия hibernate имеет метод doWork(..), с помощью которого можно выполнять работу JDBC.

Answer 2

Я хотел бы знать (...) подходит ли мой подход к использованию собственных SQL-процедур и процедур БД для случаев 2 и 3, основываясь на моем мнении

Ничто не заставляет вас использовать хранимую процедуру для случая 2, вы можете использовать HQL и проекции, как уже указывалось:

select f.id, f.firstName from Foo f where ...

Который вернул бы Object[] или List<Object[]> в зависимости от условия где.

А если вы хотите получить результаты с безопасным типом, вы можете использовать выражение SELECT NEW (при условии, что вы предоставляете соответствующий конструктор):

select new Foo(f.id, f.firstName) from Foo f

И вы даже можете вернуть не сущности

select new com.acme.LigthFoo(f.id, f.firstName) from Foo f

В случае 3 ситуация выглядит иначе. На всякий случай обратите внимание, что Criteria API более подходит, чем HQL, для построения динамических запросов . Но, похоже, здесь это не поможет.

Я хотел бы знать (...), является ли выполнение SQL в HibernateCallback правильным подходом?

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

В случае 3, поскольку вы вообще не возвращаете сущности, я бы подумал не об использовании Hibernate API, а о поддержке JDBC от Spring, которая предлагает IMHO более чистый API, чем Session#connection() и HibernateCallback.

Более интересные чтения:

Ссылки

• Справочное руководство по Hibernate Core
  • 14,6. Предложение select (о select new)
  • 16.1.5. Возвращение неуправляемых объектов (около ResultTransformer)
  • 16.2.2. Использование хранимых процедур для запроса

Ресурсы

• Hibernate 3.2: Трансформаторы для HQL и SQL

Похожие вопросы

• Переменная извлечения SQLquery
• Язык запросов Hibernate или с использованием критериев

Answer 3

Вы говорите

Например: сущность Car имеет более 100 атрибутов сама по себе, но для целей отчетности мне не нужно более 10 из них ... так что, хотя загрузка всех 100 атрибутов не имеет никакого смысла

но HQL в hibernate позволяет делать проекцию (выбрать только подмножество столбцов назад). Вам не нужно тянуть всю сущность, если вы не хотите.

Тогда вы получаете все преимущества HQL (ввод результатов, синтаксис HQL-соединений), но вы можете написать SQLish-код.

См. здесь для документов HQL и здесь для синтаксиса выбора. Если вы привыкли к SQL, это довольно просто.

Итак, чтобы ответить вам напрямую

a - Нет, я думаю, что вы должны использовать HQL б - становится неактуальным, если вы идете с моим предложением для.