ResultSet(2)
ResultSet - ぐるぐる〜への反応への反応。
あと、ResultSet にはカーソル的な更新の API もかねているのと、その際のエラー情報取得とかあったり。
JDBC と Collection API - odz buffer
あー、カーソルとしてのResultSetを完全に失念してました。ただ、個人的にカーソルという考え方そのものに否定的*1なので、結果を表すクラスと一緒というのはかなり気持ち悪いです。というかResultSetが結果を表していると考えているほうが間違いなのか*2。
なんでもかんでも、On Memory にしようとしたら100万行のテーブルをカーソルで操作、とかなるとえらいことになるし*1。
JDBC と Collection API - odz buffer
確かに、CollectionにしてしまうとOn Memoryになってしまうのは痛いですね。出来る限りSQL側で削るといっても、ありえない状況じゃないですからね。
ってことはCollection的なAPIにするよりも、やっぱりIterableを継承したほうがまだ現実的ですね。
public interface Cursor extends Iterable<Object> { .... }
的な。でもこうすると例外に頭を悩ませないといけない・・・
うーん、八方塞ですね。
直接結果の件数を取得する API がない (last で移動して getRow を 呼ぶという workaround)こと
JDBC と Collection API - odz buffer
これについては、count(*)で数える、という方法もありますが、どっちにしてもいい方法とは言いがたいですね。
あと、まぁ S2DAO なり Hibernate なりの O/R Mapper を使うとか、そこまででもなければ Apache Commons DbUtils の QueryRunner を使うってのがいいんでないかなぁ。
JDBC と Collection API - odz buffer
それはそうなんですが、使いたくても使えない状況というのが・・・
あと、個人的にはDAO、DTOっていうのがそもそも気に入らないんですよねぇ。インピーダンスミスマッチを解決し切れてないというかなんというか。とくにDTOはミスマッチを解決しているんじゃなくて、ObjectモデルをRelationalモデルに合わせているようにしか思えません。なんでRelationalモデルで設計したテーブル1つにつき1つのクラスを用意しなきゃいけないんだよ、と*3 *4。
生のJDBCに関しては、タイプセーフ性の問題もどうにかならんものかと思っていて、.NET Framework 3.5のLINQなんかはこれに対する解決策になるのかな、とか考えて妄想してます。ただ、シーケンシャルなデータ構造までSQL的な手段で操作できてしまえるなんていうのはどうかと思うんだけど*5。
結局、ResultSetについてあーだこーだ言って来たけど、これはもう公布されてしまったインターフェイスだから、どうにもならんのが現実なんだよなぁ。機能を追加するか、ライブラリやフレームワークで隠蔽するしかない。
JDBCはライブラリやフレームワークからしか使わないAPIと思っておいたほうがいいのかな*6。
