Является ли iBatis правильным выбором для динамических запросов SQL?

Question

Я сталкиваюсь со следующей проблемой проектирования:

• Будет несколько подготовленных операторов SQL, где предложение WHERE содержит определенные ограничения, в которых значения будут динамическими, основываясь на пользовательском вводе.
• Кроме того, потребуются некоторые операторы SQL, которые могут оказаться довольно сложными, но результирующее предложение SELECT) все равно будет довольно простым.

Что касаетсяЯ понимаю, что iBatis будет соответствовать этим требованиям.

• Что теперь происходит в сценарии, когда пользователь (через пользовательский интерфейс) будет влиять на полную конструкцию запроса, делая запросы на основе ad hoc?

Подготовленный оператор не может этого сделать, поскольку все предложение WHERE является динамическим, у нас могут даже быть предложения агрегирования или даже подвыборы, встроенные в функции SQL.Имея это в виду, вы бы по-прежнему использовали iBatis или занялись какой-то другой нестандартной разработкой в ​​качестве лучшей архитектуры с учетом вышеуказанных требований?

Answer 1

Последняя версия iBatis (MyBatis) позволяет нам использовать мощные выражения на основе OGNL для построения динамических запросов. Одной из самых мощных функций iBATIS всегда были его возможности динамического SQL.

Answer 2

iBatis будет работать в этом случае.Мы сделали точно такой же сценарий, как вы описали, используя iBatis для создания динамических запросов adhoc на основе выбора пользователя из пользовательского интерфейса.Сложность возникла из-за того, что число доступных пользовательских элементов увеличивалось от страницы к странице, но это выполнимо.

Hibernate - это полнофункциональный ORM, который является еще одним очевидным вариантом, но его более сложно использовать.Вот несколько ссылок, чтобы помочь:

Динамические запросы с Hibernate

StackOverflow вопрос о динамических запросах с Hibernate

Итак, явыбрал бы iBatis в качестве первого выбора или Hibernate в качестве решения.Я думаю, что со сложностью индивидуальное решение слишком легко превратится в много запутанного, вложенного кода, если вы сначала действительно не продумываете весь дизайн.Предполагая, конечно, что требования не меняются, как вы идете.

Мне кажется, iBatis позволил бы вам лучше организовать SQL-код в процессе и обеспечить гибкость в дизайне вместо будущих изменений.ПО МОЕМУ МНЕНИЮ.

Answer 3

Я бы проголосовал за iBatis.Я всегда считал, что лучше всего, если у вас есть сложные запросы SQL, которые нужно выполнить (особенно количество JOIN и SUB-выборок), которые приводят к тривиальному набору результатов.использовать iBatis, а также помогает интегрироваться с существующими / унаследованными базами данных.