我们有一个基于 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 映射？
如果问题含糊，我深表歉意，但我只是在寻找以前经历过此类事情并有一些指导或“经验教训”的人。
We have a J2EE app built on Struts2+spring+iBatis; not all DAO's use iBatis...some code still uses the old JDBC approach of interacting with Database. All our DAO's call Stored Procedures, we do not have any inline SQL. Since Oracle Stored Procedures return cursors, we have to drastically change our code.
It is fairly easy for us to convert current iBatis mappings (in sql) to oracle (used a groovy script to do this) also it is easy to convert Java code that was calling old mappings that were in sql.
Our problem is to convert the old DAO's that still use JDBC approach. Since we will have to modify them anyways (because we are now using oracle) we are thinking about converting them to iBatis mappings. is this a good approach? This will be a huge effort from our side...
what do you think will be the best approach to tackle this huge effort?
- should we just get to work and start converting each method in every DAO
- should we try to make some small script that looks at each method, parses out relevant information and makes iBatis mappings from that.
- for maintenance and seperation purpose should we have 1 iBatis mapping for each DAO
I appologize if the question is vague but am just looking for someone who has gone through this type of thing before and has some pointers or 'lessons learned'.
发布评论
评论（2）
您应该做的第一件事是在测试中覆盖您的 DAO 层。这样您就会知道在转换过程中是否损坏了某些东西。如果您要将存储过程从一个 DBMS 迁移到 Oracle，您还应该使用 DbUnit。
您应该有一个 TEST 数据库实例，其中填充了不会更改的示例数据。运行完测试后，您应该能够使用同一组示例数据刷新此数据库。这将确保您的测试数据库处于已知状态。然后，您的输入参数将与一些预期（正确）的结果配对。您的测试将读取这些对并针对测试数据库实例执行它们，并确认返回预期结果。假设您的测试改变了数据库，您将需要在测试套件运行之间刷新数据库。
其次，如果您已经着手更改 Oracle 的一些数据访问实现，为什么不以此为契机将部分业务逻辑从 DB 移出并移至 Java 中呢？在 DBMS 中维护大型代码库存在许多有据可查的问题。
我不推荐这个。您花在针对每个特殊情况调整脚本以及寻找它可能引入的所有错误上的时间最好花在由有思想的人进行转换上。
这是一个好主意。然后，您可以将它们组合到您的 sqlMapConfig 中，
这将使您的映射更易于管理。只需确保在每个 sqlMap 中指定 namespace 属性，如下所示：
以便您可以重用 sqlMap 之间的映射来实例化对象图（例如：加载用户及其权限时，User.xml sqlMap 调用Permission.xml 映射）。
The first thing you should do is cover your DAO layer in tests. This way you'll know if you broke something during the conversion. If you are moving a stored procedure from one DBMS to Oracle, you should also write tests for that using a framework like DbUnit.
You should have a TEST DB instance populated with sample data that doesn't change. You should be able to refresh this DB with the same set of sample data after your are done running your tests. This will ensure your TEST DB is in a known state. You will then have your input parameters paired with some expected (correct) result. Your test will read in these pairs and execute them against the test DB instance and confirm the expected result is returned. Assuming your tests mutate the DB, you'll want to refresh the DB between runs of your test suite.
Second, if you're already going in and changing some data access implementations for Oracle, why not use this as an opportunity to move some of that business logic out of the DB and into Java? There are many well-documented problems with maintaining large codebases in a DBMS.
I don't recommend this. The time you'd spend tweaking the script for each special case, plus hunting down all the bugs it would introduce would be better spent doing the conversion by a thinking human.
That's a fine idea. You can then combine them in your sqlMapConfig with
This will keep your mappings more manageable. Just make sure to specify the namespace attribute in each sqlMap like:
So that you can reuse mappings between the sqlMaps for instantiating object graphs (example: when loading a User and his Permissions, the User.xml sqlMap calls the Permission.xml mapping).
我不明白 iBatis 在这里给你买了什么。
目前还不清楚迁移是什么。您是说您已决定将所有代码移至存储过程中，这样就不再有内联 SQL 了？如果是这样的话，我建议不要使用 iBatis。如果您已经在使用 Spring，请让它使用其 StoredProcedure 对象并将光标映射到对象中。
创建 JUnit 或者更好的是 TestNG 测试的建议是正确的。在更改任何内容之前执行此操作。
I don't see what iBatis is buying you here.
It's also not clear what the migration is. Are you saying that you've decided to move all the code into stored procedures, so there's no more in-line SQL? If that's the case, I'd say don't use iBatis. If you're already using Spring, let it call into Oracle using its StoredProcedure object and map the cursors into objects.
The recommendation to create JUnit or, better yet, TestNG tests is spot on. Do that before changing anything.