HibernateとS2DaoとS2JDBCの考え方

HibernateはEntityを中心に考えます。つまり、Javaを中心に考えるということですね。エンティティモデルとERモデルは、一致する必要はなく、それぞれでモデリングして、Hibernateが間をつなぎます。
メリットは、エンティティの設計がデータベースに引きずられることなく、そのドメインを正確に表したものになること。ほとんどのSQLは自動生成するので、SQLを書かなくてもすむこと。
デメリットは、エンティティとデータベースを個別にモデリングする必要があり、二つのモデル間でインピーダンスミスマッチが起きること。また、自動生成されたSQLの効率が悪くなるリスクがあります。継承や遅延ロードによってパフォーマンスが落ちることもあります。
フレームワークががんばっているので、機能が豊富なのですが、その分オーバヘッドがあり、学習コストがかかります。
S2DaoはSQLを中心に考えます。とはいえ、すべてのSQLを開発者が書くのは効率が悪いので、挿入、更新、削除は、S2DaoがSQLを自動生成しますが、検索は、開発者にSQLを書いてもらいます。
メリットは、SQLを自前で制御できるので、トラぶりにくいこと。機能が少ないので、簡単に覚えられること。
デメリットは、SQLを書くのが面倒なことです。また、検索の結果セットごとにDTOを作らなければいけないので、DTOが増える傾向があります。
S2JDBCは、エンティティ(Java)とテーブル(データベース)は、同一のモデルだとみなしています。また、複雑なSQL以外は、すべて自動生成します。Hibernateから継承や遅延ロードなど、有効な場合もあるがトラぶりやすい機能を削除したのがS2JDBCです。
複雑なSQLは、S2Daoと同様に開発者が記述できます。
メリットは、SQLをほとんど書かなくてもいいこと。エンティティとテーブルが同じモデルなので、モデリングが一度ですみ、インピーダンスミスマッチがおきないこと。エンティティとテーブルが同じモデルという前提なので、Hibernateと比べてマッピングの仕様がシンプルで、学習コストが低いこと。トラぶりやすい機能が削除されているので、トラぶりにくいこと。複雑なSQLでも問題なく対応できること。
デメリットは、エンティティの設計が、テーブルに引きずられ、完全にドメインをあらわしたものにならないこと。たとえば、開始と終了の値を範囲というオブジェクトにマッピングしたりすることはできなくなります。
エンティティは、テーブルに引きずられることなく、モデリングしたいということなら、Hibernateがいいでしょう。
エンティティとテーブルは同一構造でいいと考えられるなら、S2JDBCが最も使いやすいでしょう。ちなみに、Railsもエンティティとテーブルは同一だとみなしています。エンティティとテーブルを分けてモデリングする方式は、二度手間だし、苦労の割には、メリットが少ないので、今後はエンティティとテーブルを同一構造とみなす考えが主流になると思っています。納期短縮、工数削減のプレッシャーは今後ますます強くなるでしょうから。
SQLを書くのが好きな人は、S2Daoが向いてますが、実はS2JDBCでも同じことができます。Daoパターンがすきな人はS2Dao、そうでなければ、S2JDBCが良いでしょう。
Webのフレームワークとの組みあわせでいくと、Teeda Extensionは、S2Dao(DTO)と相性が良いように設計されているので、Teedaを使う場合は、S2Daoが良いと思います。