O/Rマッピングフレームワークについて

Question

O/R マッピングフレームワーク全体に対する質問になるかもしれないですが、基本的にはiBATISを想定しています。
「プロになるためのWeb技術入門」という本に次のような記述があります。
「こちらの方（iBATIS）が（JDBCなどを用いた場合と比べて）とても簡単であることがわかるのではないでしょうか。発行するSQLやテーブルの構成が変更になっても、ソースコードではなく、SQLマップファイルだけを変更すれば良いため、変更箇所が一箇所にまとまっていて変更に強いという利点もあるのです。」

JDBCなどを用いて、開発する場合と比べて格段に簡単であることがコードを見て、理解できたました。
iBATISを用いると、変更箇所が一箇所になるのはわかるのですが、JDBCを用いても、変更箇所はそのコードのみになるのではないでしょうか？
もちろん、例えば、SQLが変更されて、DBから引っ張ってくるデータが変わってしまえば、それに対応して、適切な変数を用意したりしないといけないので、余分なコードを書かなくてはいけなくなるのはわかるのですが、変更箇所自体はJDBCを使っても、一箇所になるのではなないでしょうか？
上の文章からはJDBCで書いた場合では、変更箇所が複数あるように思えたのですが、実際どうなのでしょうか？

回答お願いします。

Answer 1

iBATISにした場合SQLをxmlファイルに書くことになると思います。
xmlの修正があった場合sqlのみの修正とわかりますが、jdbcの場合javaソースの差分を確認しなければsqlを直したのかjavaのロジックを直したのかがわからないため、切り分けがしづらいということが書かれているのではないでしょうか。

Comments

[退会済みユーザー]

回答ありがとうございました。

Answer 2

既にベストアンサーが出ていますが補足で。

現在iBatisは後継のMybatisにプロジェクトが移行しています。

MybatisでもiBatis同様にSQLの定義をXMLに記載でき、かつ動的SQLの生成もXMLのタグで制御できるため、Javaのコードで動的SQLを組み立てていく方法よりも動的SQLの記述とメンテナンス性が高くできます。
JavaのコードだけてSQLを作成する方法は、短いSQLのときであればコード量的に特に気になりませんが、扱うカラム数やテーブル数が多くなった場合や、条件に応じてWHERE句の組み立て方が微妙に異なるSQLなどを対応するためにSQL文とJavaの制御文(ifやfor)を入れ込むことになり、メンテナンス性は下がっていくでしょう。それを解決するために、半分SQLを記載できるMybatis(iBatis)です。