Добрый день!

я заметил что в одном проекте коллеги поместили sql код прямо в java классы.
Внедрять что-либо типо Mybatis в этом проекте уже поздно, но хотелось бы исправить ситуацию.
Есть ли какой-нибудь способ перенести в Spring context (используем Spring) sql код и мапперы?

Хотелось бы перенести в спринг xml контекст:

sql оператор: select some_field from some_table where id = :id
и маппер some_field на поле бина

У меня есть идеи как это сделать, но не хочу спойлить, может кто предложить что попроще
Посоветуйте какие-нибудь простые варианты как это сделать.
Спасибо!

ИДЕЯ!!!
Почему бы не держать sql в...*.sql файлах ?
а спринг вообще не причем

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

A>Добрый день!

A>я заметил что в одном проекте коллеги поместили sql код прямо в java классы.
A>Внедрять что-либо типо Mybatis в этом проекте уже поздно, но хотелось бы исправить ситуацию.
A>Есть ли какой-нибудь способ перенести в Spring context (используем Spring) sql код и мапперы?

A>Хотелось бы перенести в спринг xml контекст:
A>

sql оператор: select some_field from some_table where id = :id
A>и маппер some_field на поле бина

A>У меня есть идеи как это сделать, но не хочу спойлить, может кто предложить что попроще
A>Посоветуйте какие-нибудь простые варианты как это сделать.
A>Спасибо!

Добрый день.
Какие по вашему мнению это даст преимущества перед использованием голого sql прямо в джава коде?
Я например вижу недостаток — если кардинально меняется запрос то надо лазить в 2 файлах — в спринговом контексте и в джава коде (который будет этот запрос доставать, передавать параметры, вызывать и мапить результат на объекты).

Второй еще больший недостаток это то, что запросы прописанные в файлах априори статические, а в коде можно добавлять условия поиска динамически.
Т.е. например у юзера есть фильтр по 3 полям, он их может заполнять или нет. Если заполнил — накладываем условие поиска. Получается если фигачить в коде, то это делается 1 запросом с 3 if-ами. Если же отдельно запросы, то надо предусмотреть все возможные кобинации заполнения фильтров и под каждый написать свой запрос. Для 3 полей это 2^3 = 8 запросов.


Насчет интеграции спринга и sql советую посмотреть документацию

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

A>У меня есть идеи как это сделать, но не хочу спойлить, может кто предложить что попроще
A>Посоветуйте какие-нибудь простые варианты как это сделать.
A>Спасибо!

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

<?xml version="1.0" encoding="UTF-8"?>
<statements>
   <version>$Id: control.xml,v 1.6 2011/09/12 15:38:28 fischer Exp $</version>
    <statement>
        <description></description>
        <key>GET_XXX</key>
        <value>{? = call PACKET.getXxx(?,?)}</value>
    </statement>
    <statement>
        <description></description>
        <key>GET_YYY</key>
        <value>
select * from ( select..
        </value>
    ....
</statements>

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

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

A>>У меня есть идеи как это сделать, но не хочу спойлить, может кто предложить что попроще
A>>Посоветуйте какие-нибудь простые варианты как это сделать.
A>>Спасибо!

sef>я храню запросы любой сложности в xml-структуре собсвенного сочинения в одном или нескольких файлах и с помощью вспомогательного класса забираю запросы в Map. мне этого достаточно, в конторе идею поддержали. может придется по душе и Вам. структура xml проста:

sef>

sef>    <statement>
sef>        <description></description>
sef>        <key>GET_XXX</key>
sef>        <value>{? = call PACKET.getXxx(?,?)}</value>
sef>    </statement>
sef>

Мне вот интересно — а почему тупо хранимые процедуры не написать в таком случае? По-моему минусов в обоих случаях одинаковое количество, но у хранимых процедур есть один большой плюс — это не велосипед.

Сорри, уточняю:
1. В процитированном коде разглядел как раз вызов процедуры. Вопрос — а почему её имя прямо в код не захардкодить?
2. Второй пример, который я тут не процитировал — почему сырой sql не оформить в виде процедуры, если уж ему нужно какое-то имя дать?

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

A>Внедрять что-либо типо Mybatis в этом проекте уже поздно, но хотелось бы исправить ситуацию.

Если MyBatis подходит, то можно его внедрять постепенно. Правда, в случае многочисленных запросов по многим таблицам это будет сделать непросто. Можно его внедрять постепенно, никто же на заставляет переписать все сразу.

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

A> Хотелось бы перенести в спринг xml контекст:
A>

sql оператор: select some_field from some_table where id = :id
A> и маппер some_field на поле бина

Шило на мыло. В чём преимущества-то?
Давай сразу на querydsl переходи.

Кстати, intellij вполне хорошо определяет и подсвечивает sql внутри java-файлов. Будет ли оно со спринговым контекстом — хз. А ещё там проблемы с квотированием, например <> будешь экранировать как xml.

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

.>А ещё там проблемы с квотированием, например <> будешь экранировать как xml.
CDATA

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

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

.>>А ещё там проблемы с квотированием, например <> будешь экранировать как xml.
B>CDATA
До чего техника дошла, IDEA (не знаю с какой версии, у меня последняя EAP) может интерпретировать блок в CDATA как sql и даже сразу выполнять в sql консоли. Правда, похоже, она обучается на имя тега, т.е. все спринговые конфиги будут полукрасные, если помимо sql в тех же тегах ещё что-нибудь размещено.