今更ですが、O/Rマッピングについて、背景にある考え方や必要な機能、問題点を簡単にまとめました。
ちなみに、私も性能問題の対応案件でO/Rマッパーを少し使ったことがあります。その時の体験も元にしてまとめます。
【O/Rマッピングが生まれた背景】
O/Rマッピングは、RDBを用いたシステムにおいて、オブジェクト指向を実現するために用いられる手段の一つです。
RDBは、データ中心アプローチを実現するのに向いています。
「データ中心アプローチ」とは、「データやそれに付随する手続きは変化しにくい」という前提の元、テーブル定義やクエリ、ストアドプロシージャ等に機能を集中させることで、変化に強いシステムを作るアプローチです。
オブジェクト指向はデータ中心アプローチの後に広まった概念です。
システムを責務（クラス）に分解し、その責務同士の関係性をプログラミングで表現することで、変化に強いシステムを作るアプローチです。
仮にデータの持たせ方が変わるようなシステム更改を行う場合、データ中心アプローチよりも変更が容易になります。
先に述べた通り、RBDはデータ中心アプローチを実現するのに向いており、オブジェクト指向を実現するには向いていません。
そこで、java等のオブジェクト指向言語でRDBを扱いやすくする手段の一つとして、O/Rマッピングが使われることになります。
【O/Rマッピングの実現に必要な機能】
ざっくり言うと、RDBの存在を意識することなくオブジェクト指向言語でデータを扱えるようにする機能が必要です。
イメージとしては以下です。
・Dtoクラスを参照する時に裏側でRDBのテーブルの読み込みが行われる
・Dtoクラスを更新する時に裏側でRDBのテーブルの更新が行われる
この時にRDBに発行されるSQLは、事前に定義したり、自動生成されたりします。
【O/Rマッピングを実現するツール（O/Rマッパー）】
代表的なO/Rマッパーとしては以下のようなものがあります。
・MyBatis(2010年にiBatisから改名)
・Hibernate(JPAを実装したツール)
【O/Rマッパーの問題点】
O/Rマッパーの問題点としては、「どのようなSQL文がどのタイミングで発行されているか分かりにくい」という点に尽きると思います。
具体的には、性能面の調査・改善が難しくなるという問題点があります。
O/Rマッパー導入により、以下のような問題点が引き起こされがちです。
・ループ内でのSQL発行（N+1問題）
・インデックスが使用されないSQLの生成
・遅いSQLの特定困難(ソースコードをSQL文で調べても出てこない)
O/Rマッパーの機能を使いこなせばこれらの問題点を解決できるようなのですが、導入初期の段階で意識する必要がある他、開発者に対する教育コストが必要になります。
（ちなみに、O/Rマッパーを用いた性能問題の解決法については、こちらのスライド（O/Rマッパーによるトラブルを未然に防ぐ）が詳しいです）
あくまでもSIerの場合ですが、SQLの知識・スキルは基本情報処理技術者試験で最低限のレベルは身に付けているはずですし、開発作業や運用作業にてRDBをSQLで操作する機会も多いので、O/RマッパーよりもSQL直書きの方が馴染みやすいという開発者は多いと思います。
SQLを自由に書けるなら性能問題を解決できるのに、O/Rマッパーを使用すると思い通りにSQLを発行・検索できずに性能問題を解決できない、と感じてしまう点が、開発者の不満点になってしまっていると思います。
