передача данных из хранимых процедур Oracle в Java

Мы собираемся написать новый веб-интерфейс для большой системы на базе базы данных Oracle. Все бизнес-правила уже закодированы в PL/SQL хранимых процедурах, и мы хотели бы повторно использовать как можно больше кода. Мы напишем несколько новых хранимых процедур, которые объединят существующие бизнес-правила и вернут окончательный набор данных.

Мы хотим сделать это на уровне базы данных, чтобы избежать двусторонних обращений java-db. Уровень интерфейса будет написан на Java (мы хотели бы использовать GWT), поэтому нам нужен способ передачи данных из хранимых процедур Oracle на сторону службы Java. Данные могут быть, например. набор свойств определенного элемента или список элементов, отвечающих определенным критериям. Кто-нибудь порекомендует предпочтительный способ сделать это?

Мы рассматриваем один из двух следующих сценариев:

  • передача объектов и списков объектов (типы объектов БД, определенные на уровне схемы)

  • прохождение sys_refcursor

Мы проверили, что оба подхода «выполнимы», вопрос больше касается дизайнерского решения, передовой практики, возможных проблем с обслуживанием, гибкости и т. д.

Буду признателен за любые подсказки.


java object oracle stored-procedures sys-refcursor
person Alex    schedule 14.09.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

Я бы рекомендовал придерживаться refcursor с четко определенными ключами (согласованными с обеих сторон разработчиками java и разработчиками pl/sql). Это намного проще расширить в будущем, вы можете легко преобразовать refcursor в hashmap, а затем hashmap в POJO, используя утилиты apache bean, если это необходимо. Я работаю над большим телекоммуникационным проектом с множеством подходов к этой проблеме, и refcursor кажется лучшим в конце дня.

person Kris    schedule 14.09.2011
comment
Не могли бы вы дать некоторое представление о том, как преобразовать refcursor в Hashmap, а затем в POJO? Спасибо - person Jacob; 27.06.2012

arrow_upward
1
arrow_downward

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

person Bitmap    schedule 14.09.2011
comment
На какую часть вопроса отвечает это утверждение? ОП уже знает, как это сделать; вместо этого он спрашивает, какой подход лучше. - person Vineet Reynolds; 14.09.2011
comment
@Vineet Reynolds Может ли кто-нибудь порекомендовать предпочтительный способ сделать это? - а также прочитать сценарий перед этим. - person Bitmap; 14.09.2011
comment
учитывая другие опубликованные ответы, какую ценность добавляет рекомендация использования CallableStatement? Возможно, вам следует последовать собственному совету по чтению сценария; использовать типы объектов и курсоры ref непросто, и в долгосрочной перспективе их невозможно поддерживать, и ОП просит совета в этих областях. - person Vineet Reynolds; 14.09.2011
comment
@Vineet Reynolds Какую часть передачи объектов и списков объектов (DB object types defined on the schema level) и передачи sys_refcursor вы не поняли? вы думаете POJO, когда видите термин объект? прочитайте это снова. - person Bitmap; 14.09.2011
comment
В вопросе есть это утверждение - We verified that both approaches are "doable", the question is more about design decision, best practice, possible maintenance problems, flexibility, etc., и я не вижу, как ваш ответ касается любого из них, кроме этой фразы - I have achieved exactly the same with classic JDBC CallableStatement without any perfomance or maintenance issues, что делает ответ неполным. Вы не указали, почему кто-то должен учитывать этот совет. - person Vineet Reynolds; 14.09.2011
comment
Would anyone recommend a preferable way of doing this? Является ли актуальным вопрос - переходите к этому, он ясно дал понять, что будет рад услышать, если конкретный подход к проектированию не рекомендуется с точки зрения его гибкости, обслуживания и производительности. Теперь скажите мне, если вы считаете, что предложенный подход с использованием CallableStatement ненадежен или не является лучшей практикой. Можете ли вы также сказать мне, какую часть without any perfomance or maintenance issues вы не понимаете? - person Bitmap; 14.09.2011

arrow_upward
0
arrow_downward

Прошло некоторое время с тех пор, как я сделал что-то подобное, но насколько я помню, вам нужно определить представление, которое вызывает вашу хранимую процедуру, и затем вы можете легко читать наборы результатов из java с помощью OR-mapper на ваш выбор.

Итак, это кажется близким к вашему сценарию 1, который, по моему опыту, никогда не вызывал никаких проблем.

Единственное, с чем нужно быть осторожным, так это с обработкой транзакций: если ваши хранимые процедуры записывают данные и вы вызываете несколько из них в рамках транзакции Java EE, вы можете столкнуться с несогласованностью данных.

person alvi    schedule 14.09.2011