約1年前、小さなプロジェクトで、使用するフレームワークの検証選定などして、組み合わせを決定する立場になって、いろいろ考えたことがあります。

そのときは、struts + velecity + spring(JDBC抽象化フレームワーク含む)という構成に決めました。

あまり複雑でないほうがいいという頭ではいたんですが、自分が決める立場だとついつい、やりすぎちゃうんですよね。O/Rマッピングも検討したけど止めといた。

そのプロジェクトは結局結構(相当？)苦労しました；；フレームワーク構成についての資料と結構な規模のサンプルまで渡したのに、協力会社からは、「最近のjavaは難しいですねｗ」と皮肉めいたことを言われたし。

振り返ると、struts + velecity + DBUtils にしとけばよかったなと。

javaやったことある人なら、struts経験はあるだろうし、DBアクセスは、昔ながらのJDBCのやり方(PreparedStatement 用意して、…最後にclose()というやつ)は、知ってるから、DBUtilsは自然に使えるだろうし。

社内メンバや協力会社の経験値も踏まえた上で、みんなが無駄な苦労をしない方が良いし、新しいこともバランスよく業務に取り入れた方がいろいろな意味(モチベーションとか)でいいだろうし。

結論：フレームワーク構成を決める(立場に立つ)のは、大変なこった。