開発に向けた準備で、開発標準を準備するフレームワーク(FW)チーム、それらを使って実装を行う業務チームが集まって、「DB操作を行うためのFWは何を使うか？」という協議になった。
FWチームは、FW・JavaEE7の標準であるJPAを推奨した。
FWチームの一員ではあるが業務寄りの立場でもある自分はmybatisを推奨した。業務チームからの強い要望で、mybatisを採用する方向で決定した。
- 分かりやすさ、関心の分離
JPAはオブジェクト指向プログラムベースでDB操作を完結したい（ORマッパーの目標）ので、結果としてプログラム上にSQL文に相当するDB操作の実装がされる。単純なDB操作であれば美しいと思うが…
難易度の高い業務システムでは、多数のテーブル結合や副問い合わせを混在させたような複雑なクエリを実装する必要がある。プログラム/JPQL/SQLが混在したソースコードを作るのも大変だし、それをレビューするのも大変である。やはりSQL文だけに集中したい…
mybatisは外出しのファイルにSQL文を定義できるので、このような問題を軽減できる。
JPAでもネイティブクエリ（とちょっとの改修）を使えば、外出しのファイルに定義できますよ、とのことだが、だったらmybatisの方が機能が充実しているので、mybatisを選んだ方が素直かと… - 学習や開発コスト
JPA(JPQL)は、SQL文ライクな問い合わせ言語であるが、SQL文ではない。SQL文の感覚でJPQLを定義して実行するとエラーになる場合がある。問題が発生した場合、JPQLの問題なのかSQL文の問題なのかの切り分けが必要となり、難易度が上がる。JPQLでSQL文の全てを表現できるわけではないので、その辺の制約を把握していないと、実行時のエラー原因の特定が難しい。
FWチームとしては、プロジェクトに投入されるメンバ(パートナー)はJavaEE6or7を分かっている人が投入されると思うので、そんなに問題ないのでは？と。ん～実態はそうではないと思います…ちょっとJava開発やったら「経験者」として営業提案されて入ってくる人も多いのではないかなぁ、なんて思います…自分もJPQLで苦労したので… - ORマッパーの考えを否定するわけではありませんが、私の経験や視界にある日本の業務システムは、複雑怪奇であり、ORマッパーは適さないのかなぁ、なんて思います。FWチームは優秀な人が多いのかもしれませんが、その案件のために急遽集められた業務チームのメンバには難しいんじゃないかと思います…
- 今のFWにあるJPAの機能を使わず、なぜ追加開発でmybatisを使うのか？というコスト的な指摘もありました。全般的に優秀な人ほど、mybatisの採用に否定的でした…あはは…
直近で考えるならJPAの方が準備が充実しておりコストがかかりません。だがしかし、上記の通り、良くも悪くも寄せ集め業務チーム(20人程)が自分と同じように苦労するよりも、今自分が苦労してmybatisを使えるようにした方が、みんなの負担が削減され、後の品質が良くなるはず！と信じています。 - プログラマの直感とは異なる動作が行われる場合があり、気づきずらい。単純な操作なはずなのに裏側でパフォーマンスが劣化するようなクエリが実行されている場合がある。エンティティに値を設定したがユーザのキャンセル操作があったため処理を中断したはずが、(EntiryManagerによる)暗黙的な更新処理が行われてしまう場合がある。