その理由は、去年までいた職場では自社フレームワークを作っていた関係上、外部のフレームワークを統合することはなるべく割けて、できるだけJDKに含まれているもの...妥協してもJPAのような標準と認識されているものを...というスタンスだったためです。
ちょっと個人的に少し触ったりもしましたが、何かを作ったわけでもないので良くわかってない状態でして。。
で、今の職場でS2Containerを使う事になりまして〜〜 土日で触ってみてました。
まだ全てを把握している訳ではありませんが、一言で言うと"良く出来てるなぁ"
「DIコンテナ作るかー！」と考えて頭の中で仕様を考えただけでは、ここまでの機能を考え着かないと思う。
業務で色々使ってみて足りない部分をドンドン追加して精錬されたのか...それとも超天才が作ったからなのか...オープンソースの威力の表れなのか...
ただやっぱり慣れないのが、DIコンテナってどーしてもリフレクションでインスタンスするからデバッグで辿って行くのが難しい(コツがいる)所。
あと、勝手にやってしまう所。
「勝手にやってしまう所」については、言葉を替えると「便利な所」でもあるんですよね。
でも慣れていないと、サクサク進められなくてちょっとイライラしたりしてww
標準的な動きで無い所は、アノテーションで指示する...とした時もアノテーションの仕様を見る必要があったりとか...
でも、慣れると、コードも見やすくなるんでしょうねー。
命名規約のおかげでコードも見やすくなる部分もあるし、コード量が減るからバグも少なくなるだろうし。
あ、あとS2DaoとS2JDBCも少し見てみました。
私的にはS2JDBCに惹かれましたね...
単純なSQLだったら、テーブル名や列名をソースやTextにリテラルで埋め込む必要がなく、JavaコードでSQLが書けるんですね！
何かテーブルの変更があった時に、コンパイルエラーが出せるってのは大きいと思う。
そうやって見てる内に、S2JDBCに比べS2Daoのメリットってなんだろう？と分からなくなって、ちょっとググッてみたら
(S2JDBCだと)中途半端にJavaのコードで検索ロジックを書かれるときついな、という結論でした。
開発者のスキルによってどこまでがSQLでどこまでがロジックでという判断が変わるのが嫌です。
ってのがありました。
確かに、開発者のスキルによって使う道具って変わると思うし、変えないとおかしいと思います。S2Dao/S2JDBCについて触りしか触ってないから良くわかっていないのですが、そういう観点もあるんですね。
上記のSeasarに関わらずですが...最近感じる事としては、
「どれだけコンパイルエラーとしてコードミスを検知できるか」
ってのがやっぱ大切よなぁーって思います。
「コードの中はどんなんでもいいから、テストケースを書けばいいじゃん！」
って思っていた所もあったんですが、
最近はコンパイルエラーが出せる所は出るようにコード書こう！って。
便利なフレームワーク...となると、コンパイルエラーが出せないパターンってどうしても増えますよね。定義ミスとか。
ここらへんはトレードオフなんだろうなぁー
自分でつくったオレオレフレームワークだったら、バシバシ定義を増やして記述量を少なくしていくと思う。トラブっても原因が分かるし、フレームワーク側を直せるから。
でも他人が作ったフレームワークの場合は...妥協点を何処にするかって所ですよねぇー。