преобразование приложения J2EE из Sql в Oracle - предложения с эффективным подходом - PullRequest
0 голосов
/ 31 октября 2009

У нас есть приложение J2EE, построенное на Struts2 + spring + iBatis; не все DAO используют iBatis ... в некотором коде все еще используется старый подход JDBC для взаимодействия с базой данных. Во всех хранимых процедурах вызова DAO у нас нет встроенного SQL. Поскольку хранимые процедуры Oracle возвращают курсоры, мы должны радикально изменить наш код.

Нам довольно легко преобразовать текущие отображения iBatis (в sql) в oracle (для этого использовался скрипт groovy), а также легко преобразовать код Java, который вызывал старые отображения, которые были в sql.

Наша задача - преобразовать старые DAO, которые все еще используют подход JDBC. Так как нам все равно придется их модифицировать (потому что мы сейчас используем оракул), мы думаем о преобразовании их в отображения iBatis. это хороший подход? Это будет огромное усилие с нашей стороны ...

Как вы думаете, что будет лучшим подходом для решения этой огромной задачи?

  • Должны ли мы просто приступить к работе и начать преобразовывать каждый метод в каждом DAO
  • если мы попытаемся создать какой-нибудь небольшой скрипт, который будет проверять каждый метод, анализировать соответствующую информацию и делать из этого сопоставления iBatis.
  • для целей обслуживания и разделения, если у нас есть 1 отображение iBatis для каждого DAO

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

Ответы [ 2 ]

1 голос
/ 31 октября 2009

Первое, что вы должны сделать, это покрыть свой слой DAO в тестах. Таким образом, вы будете знать, если вы что-то сломали во время конверсии. Если вы перемещаете хранимую процедуру из одной СУБД в Oracle, вам также следует написать тесты для этого, используя такую ​​инфраструктуру, как DbUnit .

У вас должен быть экземпляр TEST DB, заполненный образцами данных, которые не изменяются. Вы должны быть в состоянии обновить эту БД с помощью того же набора образцов данных после того, как завершите свои тесты. Это гарантирует, что ваша TEST DB находится в известном состоянии. Затем ваши входные параметры будут сопоставлены с ожидаемым (правильным) результатом. Ваш тест прочитает эти пары и выполнит их для экземпляра тестовой БД и подтвердит, что ожидаемый результат возвращается. Предполагая, что ваши тесты изменяют БД, вы захотите обновить БД между запусками вашего набора тестов.

Во-вторых, если вы уже заходите и меняете некоторые реализации доступа к данным для Oracle, почему бы не использовать это как возможность перенести часть этой бизнес-логики из БД в Java? Существует много хорошо задокументированных проблем с поддержкой больших баз кода в СУБД.

если мы попытаемся создать какой-нибудь небольшой скрипт, который будет проверять каждый метод, анализировать соответствующую информацию и делать из него сопоставления iBatis.

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

для целей обслуживания и разделения, если у нас есть 1 отображение iBatis для каждого DAO

Это хорошая идея. Затем вы можете объединить их в sqlMapConfig с

<sqlMap resource="sqlMaps/XXX.xml" />

Это сделает ваши сопоставления более управляемыми. Просто убедитесь, что в каждом sqlMap указан атрибут namespace , например:

<sqlMap namespace="User">

Чтобы можно было повторно использовать сопоставления между sqlMaps для создания экземпляров графов объектов (например, при загрузке пользователя и его разрешений sqlMap User.xml вызывает сопоставление Permission.xml).

0 голосов
/ 31 октября 2009

Все хранимые процедуры вызовов нашего DAO

Я не понимаю, что iBatis покупает здесь.

Также не ясно, что такое миграция. Вы говорите, что решили переместить весь код в хранимые процедуры, чтобы больше не было встроенного SQL? Если это так, я бы сказал, не используйте iBatis. Если вы уже используете Spring, позвольте ему вызывать Oracle, используя его StoredProcedure объект и отображать курсоры в объекты.

Рекомендация по созданию JUnit или, что еще лучше, тестов TestNG очень важна. Сделайте это, прежде чем что-то менять.

...