0

我们有一个基于 Struts2+spring+iBatis 构建的 J2EE 应用；并非所有 DAO 都使用 iBatis...有些代码仍然使用旧的 JDBC 方法与数据库交互。我们所有 DAO 的调用存储过程，我们没有任何内联 SQL。由于 Oracle 存储过程返回游标，我们必须彻底改变我们的代码。

我们很容易将当前的 iBatis 映射（在 sql 中）转换为 oracle（使用 groovy 脚本来执行此操作），也很容易转换调用 sql 中旧映射的 Java 代码。

我们的问题是转换仍然使用 JDBC 方法的旧 DAO。由于无论如何我们都必须修改它们（因为我们现在使用的是 oracle），我们正在考虑将它们转换为 iBatis 映射。这是一个好方法吗？这将是我们方面的巨大努力......

您认为应对这一巨大努力的最佳方法是什么？

  • 我们是否应该开始工作并开始转换每个 DAO 中的每个方法
  • 我们是否应该尝试制作一些小脚本来查看每个方法，解析出相关信息并从中进行 iBatis 映射。
  • 出于维护和分离目的，我们是否应该为每个 DAO 拥有 1 个 iBatis 映射

如果问题含糊不清，我深表歉意，但我只是在寻找以前经历过此类事情并有一些指示或“经验教训”的人。

4

2 回答 2

1

您应该做的第一件事是在测试中覆盖您的 DAO 层。这样您就可以知道在转换过程中是否损坏了某些东西。如果您要将存储过程从一个 DBMS 移动到 Oracle，您还应该使用像DbUnit这样的框架为此编写测试。

您应该有一个 TEST 数据库实例，其中填充了不变的示例数据。完成运行测试后，您应该能够使用相同的示例数据集刷新此数据库。这将确保您的 TEST DB 处于已知状态。然后，您将输入参数与一些预期（正确）结果配对。您的测试将读取这些对并针对测试数据库实例执行它们并确认返回预期结果。假设您的测试改变了数据库，您需要在测试套件的运行之间刷新数据库。

其次，如果您已经着手更改 Oracle 的一些数据访问实现，为什么不利用这个机会将一些业务逻辑从 DB 中移到 Java 中呢？在 DBMS 中维护大型代码库存在许多有据可查的问题。

我们是否应该尝试制作一些小脚本来查看每个方法，解析出相关信息并从中进行 iBatis 映射。

我不推荐这个。您花时间为每个特殊情况调整脚本，加上寻找它会引入的所有错误，最好花在有思想的人进行转换上。

出于维护和分离目的，我们是否应该为每个 DAO 拥有 1 个 iBatis 映射

这是个好主意。然后，您可以在sqlMapConfig 中将它们与

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

这将使您的映射更易于管理。只需确保在每个 sqlMap中指定命名空间属性，例如：

<sqlMap namespace="User">

这样您就可以重用 sqlMaps 之间的映射来实例化对象图（例如：加载用户及其权限时，User.xml sqlMap 调用 Permission.xml 映射）。

于 2009-10-31T15:02:35.310 回答
0

我们所有 DAO 的调用存储过程

我看不到 iBatis 在这里给你买了什么。

目前还不清楚迁移是什么。您是说您决定将所有代码移动到存储过程中，因此不再有内联 SQL？如果是这样的话，我会说不要使用 iBatis。如果您已经在使用 Spring，让它使用其StoredProcedure对象调用 Oracle 并将游标映射到对象中。

The recommendation to create JUnit or, better yet, TestNG tests is spot on. Do that before changing anything.

于 2009-10-31T15:14:09.307 回答