基本的に興味なし
"O/Rマッパーを使うべきかどうか"
自分は、このテーマについて全く興味がありません。
しかし、自分の立場上、このテーマについての議論を振られることが多く、その度にお茶を濁しているのですが "キリがない" ということ。
あと、
"DBFluteユーザがこれで悩んでる姿を見たくない"
という気持ちから、ちょっと今回だけ書くことにしました。ちょっとしたアドバイスという感じで、ポイントを解説します。
A. 言葉の曖昧さを確認
このテーマの議論でよく聞く言葉が：
"O/Rマッパーなんか使わずにSQLを書けばいい"
曖昧なポイントが幾つかあります。
曖昧ポイント1: O/Rマッパー
"O/Rマッパー" という言葉がとても曖昧です。結構、会話上都度都度色々なスコープを定義する言葉になることが多いです。(しかも状況によって定義が変わったり)
1. JDBCをラップしたDBアクセスツール全てがO/Rマッパー
2. オブジェクトグラフにマッピングするのがO/Rマッパー
3. RDBっぽいのを隠蔽してODB風にアクセスするのがO/Rマッパー
4. SQLを自動生成するのがO/Rマッパー
5. というかJDBCもO/Rマッパー
6. 自作ツールはO/Rマッパーに含めない
7. その他色々
"1" が、何気に多く利用されるパターンじゃないかと。それが本来の意味として正しいかどうかは別にして、そういう意味合いで会話上で使ってる人を多く見掛けます。
"2" の場合、DBFluteのConditionBeanはO/Rマッパーですが、外だしSQLはO/Rマッパーじゃないですね...(じゃあ何だ!?)
"3" は、まさしく "Hibernate" でしょうか。これだったら、DBFluteはもはやO/Rマッパーではないですね。RDBをすごく意識するから。
"4" は、議論中にこういう定義になっちゃうこと多いのですよ。SQLを基調にしたO/Rマッパーいくらでもあります。
"5" は、ちょっと新鮮ですが、大事なことです。言葉の定義自体はどうでもよく、それよりもJDBCも十分過ぎるほど "ラップフレームワーク" であるということが大事(しかも、あまりDBごとの方言が隠蔽されてない...)。ResultSetというオブジェクトにRDBのデータを反映させています。Sunが仕様を考えて、各DBMSが実装したO/Rマッパとも言えます。
"6" も、時々聞くのですが、自作か公開されたものかどうかの違いを重要視するというのであれば、それは別のテーマですね。
...
とにもかくにも議論してる最中で、結構ごっちゃになってることがありますのでこの点に注意です。
そして、そもそもこの定義自体に自分は興味ありません。
"DBFluteは本当の意味でO/Rマッパーと言えるのか？"
と言われたことありますが、(多分、"3" の意味合いで捉えてのことだと思われますが)
"あ、言えなくていいです、単にDBアクセスツールでもいいです"
と一蹴させて頂いたことがあります。別に悪気があった訳じゃなく、本当に興味がないのです。(開発現場で役立つのであれば何だっていいですよ)
※この後のポイント説明において、"1" の意味合いで利用します。
「JDBCをラップしたDBアクセスツール全てがO/Rマッパー」
という前提でお話をします。
曖昧ポイント2: SQLを書けばいい
この言葉自体は、"SQLを基調としたやり方をすること" というのは明確に伝わって来ます。しかし、"O/Rマッパーを使う使わない" という要素との関連性はあまりないかと考えられます。
SQLを基調としたO/Rマッパーはたくさんあるからです。なので、"O/Rマッパーを使わずに" という言葉はあまり似合わず...
どのO/Rマッパーを使うか(JDBCも含めて)
という風に置き換えた方が議論がしやすいでしょう。
また、O/Rマッパーも "SQLの自動生成しかしない" とか "SQLベタ書きしかしない" とかそういう単純な時代ではありません。
例えば、DBFluteではConditionBeanも提供していますが、SQLをベタっと書くことを大事にしている外だしSQLもあります。実際に、CBなしでオール外だしSQLで利用されたケースもあります。なので、さらに発展させて、
どのO/Rマッパーをどのように使うか(JDBCも含めて)
という風に置き換えた方がさらに議論がしやすいでしょう。もし、"O/Rマッパを使わないこと" を "JDBCドライバを直接使うこと" と定義するならば、
O/Rマッパーを使わない方が遥かにSQLをないがしろにしている
と言えるでしょう。
SQLを、Javaプログラムの中で読みづらい破片文字列として取り扱うのがSQLを大切にしているとはとても言えません。
"DBに詳しいこと" と "DBを使ったアプリに詳しいこと" は別。"アプリに組み込むSQLのジレンマ" をよく知っていれば、"SQLを書けばいい" と "O/Rマッパー" が排他的ではないことに気付くでしょう。
...
ちなみに "SQLを基調としたやり方をするか否か" というのは別のテーマ。ただ、これに関しても曖昧な点をしっかり明確にするべきでしょう。
o 全てのSQLを書く？
o 検索のSQLを書く？ (insert/update/deleteは自動生成)
o 文字列として埋め込んで書く or 外だしSQLで書く？
o その他亜種
o などなど…
jfluteは、"アプリに組み込む非定形な複雑なSQL" を書くのであれば、絶対に 2Way-SQL で書きたいなって思います。
=> 2Way-SQL | DBFlute
B. 好き嫌いの排除
"O/Rマッパー嫌いなんだけど" と、主張される場合が時折あります。
そもそもこの主張は曖昧で、"A" におけるポイントを整理する必要がありますし、また、"嫌い" っていうところの意味するところが、"その人が個人的にO/Rマッパーが嫌い"、なのか、"O/Rマッパーを利用するメリットがない" なのか、とても曖昧です。前者は論外で、個人の嗜好に興味はありません。後者なら、"嫌い" という表現でまとめずしっかりと理由を明確にする必要があります。
趣味のレベルで話をするときは、特に問題ないですが、"好き" とか "嫌い" という表現は本質追究の議論においてはあまり適切ではありません。(まあ、使ってしまう気持ちもわかりますが)
"好き" は、"良い、なぜなら..."
"嫌い" は、"悪い、なぜなら..."
に置き換えられます。違いは一つ：
"好き"・"嫌い" を使うと、理由をぼかす効果があるのです。それでも遠慮なく突っ込まれることもありますが、人間の会話では、"好き" とか "嫌い" とか言われるそれ以上突っ込めないムードになります。でも、その状況は既に本質追求の議論ではありません。
自分で言わないことも大事ですし(まあ言ってもその後ちゃんと話をつなげるとかすればOKかと)、言われたときにしっかりその真意を分析するのも大事です。
C. ターゲットを明確に
"システム業界の全ての開発においてO/Rマッパが必要か？" という議論をしてるとしたら不毛です。
そんなにシステム業界の開発現場って画一的ではありません。開発規模、メンバーのスキルセット、工期、複雑度など様々です。O/Rマッパーが必要なところもあれば、本当になくっても(JDBCベタベタで)大丈夫ってところもあるでしょう。(ちなみに "SQLを基調とするか否か" でも同じ話です)
DBFluteも、全ての開発で必要とは思っていません。でも、活躍する開発は少なからずあると考えています。まだSandBox、標準準拠(JPA)じゃない、作者が無名プログラマ、それでも "便利だ" と言って使ってくれている現場がある。その(DBFluteを求める)開発現場のためにDBFluteが存在している。ただ、それだけです。(でもSandBoxは早くどうにかしないとね...)
なので、置き換えると "システム業界の全ての開発においてDBFluteが必要か？" なんて議論は無駄です。
一応、Seasarカンファなどでターゲットを挙げさせて頂いたことはありました。
要約すると：
o 複数人でやるプロジェクト
o お金・時間に余裕がない
o スキルがバラバラ(外注もいたり)なプロジェクト
o DB変更が開発中も頻繁の発生するプロジェクト
逆に捉えると以下では特にお奨めしません：
(利用したらしたで便利だけど、強く奨めはしない)
o 一人実装プロジェクト
o お金も時間もたっぷりのプロジェクト
o ハイスキラばっかりプロジェクト
o DB変更が絶対にないプロジェクト
そういうことを考えると、例えば...
"自分のところでは使わなくても問題ないから他でも不要だ"
という論理はあまり意味を成さないということがわかります。
"自分は使わなくても問題ないから他の人も不要だ"
も同様です。
"システム業界のあるべき姿" を議論してる場合も注意です。現状に合わせた最適な方法を議論しているのか、理想に合わせた最適な方法を議論しているのか、答えは正反対になりがちです。議論メンバーがこの意識が食い違っていると話が平行線です。で、理想の話をするのであれば、そもそも理想に近づけるためのシステム業界の改革を議論すべきでしょう。(別テーマですね)
DBFluteは、"現状に合わせた最適な方法" のつもりで作られていますので、"本当に最適かどうか" という議論は良いと思いますが、"存在しない理想(or 将来)の世界での方法として最適かどうか" という議論は無意味です。
まとめ
この件に関しては、これで最初で最後の記事です。個人的には(とても)触れたくないテーマで興味がありません。これらのポイントが議論の前提として明確になっていない状態で話し合いをしても先が見えないでしょう。コメントも内容次第では返答を控えさせて頂きます。ですが、DBFluteユーザの方にとって、少しでも考え方の参考になればと。
【追記】
また一方で、どんなツール(O/Rマッパー)を使うかよりも「テストデータをどう管理するのか」の方がより重要な検討事項だとも考えています。
「テストデータ | DBFlute」
※それ以前に考えるべきことはたくさんあるのです
【追記】
補足的な記事書いちゃいました…
=> O/Rマッパーの議論に巻き込まれないで
【追記】(2016/06/28)
O/Rマッパーはいったん置いておいたとしても、プログラムとSQLをつなげるためのフレームワークは必要で、排他制御、共通カラム、トランザクション制御、SQLログ、SQL例外ハンドリングなどなど、要はJDBCドライバじゃ全然足りないところ。たぶん、それがO/Rマッパーに一緒にくっ付いてて役割を二つ持っているので話がややこしいってのもあるかなと。
