O/Rマッパーその２

java

ツールの中で重要なものがエンティティクラス。
大体はテーブルごとに作成し、カラムの値をそれぞれプロパティとして保持する。

私はどうもこれが好きではない。
自分でも理由は良くわからないのだが・・・

  • クラスの数が膨大になる。

　　DBFluteはDBのスキーマから自動生成する機能があるので作る手間はないのだが、確かテーブル1つ当たり5つのクラスができたような気がする。
　　エンティティだけではなく、SELECTやUPDATEなどのSQLを組み立てるためのクラスも含まれている。
　　eclipseの中で必要なクラスを探すのが大変だ(笑)

  • カラムごとのアクセッサメソッド。

　　使いやすいかどうかは場合によるのだが・・・
　　javaの命名規則に馴染むカラム名であればいいが、時々とんでもない名前になることがある。
　　javaらしくない名前ややたら長い名前は非常にみにくい。

こんなところか・・・


エンティティのメリットとしてこんなことがよく挙げられる。

  • スキーマの変更に強い。
  • キャストが不要。

旧来のプログラムではSQLの中や、ResultSetのメソッドに対してカラム名はすべて文字列として入力していた。
こうなると、途中でスキーマが変わると修正が必要な場所を探すのが大変だったり修正漏れが起きたりする。
エンティティを使っていれば、ツールで生成しなおせば変更のあった部分はコンパイルエラーとなるだろうから、修正漏れはおきにくいだろう。
だが、そうしたコンパイルエラーを一つずつつぶすのと、ソースをカラム名で全文検索して検索結果を元に修正するのとそんなに手間が変わるものだろうか？
エンティティを使ったとしても、外部化しているSQLは結局カラム名を人間がチェック・修正しなくてはいけないのに・・・


キャストについては異論はないが・・・
そんなに手間かな？
最近のeclipseは賢くて自動的に追加してくれたりするし、面倒だと感じたことはないけどなぁ・・・


単純なSELECTやUPDATEの時にSQLを書く手間を省くという意味ではエンティティクラスは必要だと思う。
だが、テーブルごとにクラスを作ったり、カラムごとのアクセッサまではやりすぎ。
Mapでカラム名と値を保持して、スキーマを元にSQLを組み立てればそれで済む。
スキーマはDatabaseMetaDataで取得してもいいし、事前にxmlなり何なりに用意しといてもいい。
SQLの動的生成はパフォーマンスが悪いという話も聞くが、O/Rマッパーだってホントに単純なSQL以外は動的生成せざるを得ないだろう。


O/RマッパーはSQLを知らなくても開発作業ができるとか、DBの接続切断を意識しないで済むとか、確かに便利な面はある。
だが、私としてはSQLを知らなかったり、JDBCの基本を知らなかったりする開発要員には関わりたくもないが・・・


eclipseがメジャーになった時も同じようなことを感じた。
開発が便利になるのはありがたい。
今となっては必須のツールだ。
だが初心者に使わせるべきではない。
案の定、
『eclipseでは動くのに実環境では動かない。掲示板で質問してみるとクラスパスがどうとか言われた。よくわからないけど設定したら動いた。』
なんていう人が出てくる。
こんな相手でも、いたら仕事を割り振らなきゃいけないんだよね(笑)


DBFluteを使ったプロジェクトでは、他のメンバーはO/Rマッパーを使わない開発の経験がなかったので、どれだけ手間が違うのかは知りようもない。
双方の開発を経験した人と直接話してみたいものだ。
ブログを読んだりコメントをつけたりというのはまどろっこしい。