O/Rマッパー
以前仕事でDBFluteというO/Rマッパーを使ったことがあった。
他にもHibernateやら何やらO/Rマッパーというツールがあるようだが・・・
そんなに便利かねぇ?
売りにしてるらしい機能はこういうもの。
他にも私が知らない機能があるのかも知れないが・・・
- 接続/切断の自動化。
旧来のデスクトップアプリケーションならどうだか知らないが、最近のシステム開発はほとんどがWEBアプリケーションになっている。
javaの場合サーバーはtomcatやらweblogicやらになるが、接続はサーバーの設定ファイルにurlなどを書いておけば簡単にできるようになっている。
切断も、まあ実際にはプーリングすることにはなるが、filterやらフレームワークで使用しているservletクラスの後始末処理あたりに書いておけば、個々の画面や業務ごとに書く必要がないのは同じこと。
多少メソッドが変わるだけでO/Rマッパーを使おうが使うまいが手間は変わらない気がする。
- DBの癖や方言を隠蔽する。
- SQLを知らなくても使える。
DBFluteのソースを見て、非常に良く作られていると感心した覚えがある。
これはこれで便利ではあるが、利用できる範囲が限られているのが惜しい。
DBFluteを使っていてもSQLを書かなければいけないケースはかなり多い。
そういう時にはこの機能はまったく無意味であることを思うと、中途半端な機能だと感じてしまう。
- SQLを外部化して修正を簡単にする。
今時分SQLを直接ソースコードに書いてるプロジェクトの方が珍しいような気もするが・・・
ごく簡単なものならともかく、ほとんどのSQLは何らかの形でソースコードとは別に管理しているのではないか?
それだけであれば売りでもなんでもないが、DBFluteの優れている点は記述したSQLがそのまま実行できることだ。
プログラムが必要とするSQLにはパラメータの「?」がたくさん埋め込まれていて、人間がテストのためにその「?」を適当な値に一つ一つ書き換えて実行するなんてのは良くあることだ。
今まで私が経験してきたほとんどのプロジェクトでそういうことをしていただろう(笑)
それがDBFluteの場合は実際にプログラムが読み込むSQLにテスト値を埋め込めるようになっている。
詳細は省くが、これにはとても助けられた。
まあ便利な点もあるのは確かだが、使いこなすためにはかなりの学習が必要だと感じた。
習得するための手間や負荷と受ける恩恵を天秤にかけると、そこまでして使いたいものではないと思う。
#特にConditionBean関係のクラス・メソッド。
#複雑にも程があるでしょ(笑)
もう少し書きたいこともあるがそれはまた今度・・・