SpringとSeasar2

http://www.arclamp.jp/blog/archives/spring_architecture_framework.html
　Springはフレームワークを統合するためのプラットフォームとして作られています。Springの冗長と言われる構造は組み合わせの汎用性を向上させるために必要な犠牲です。銀の弾丸となるフレームワークは存在しません。だから、調整が効くことが重要だと考えています。Spring（と、その周辺）は調整を重視していると思っています。

Springが絡んだプロダクトは、その犠牲や冗長性が、開発者の多くを占める業務ロジックや画面の開発者に、恩恵を与えていないこと。

Seasar2が嬉しいのは、開発者の多くを占める業務ロジックや画面の開発者に、恩恵を与えてくれること。*1

Springが、他のプロダクトといろいろ連携できているのは、Springの良さで使われているというよりは、コンポーネントの結合の方式として、DIが受け入れられた中で、たまたまSpringがあったから使っただけ。というようにしか見えない。

あと、上とは関係ないけど、SpringのXMLより、Seasarのdiconの方が個人的には使いやすい。diconのタグがシンプルってのが大きいのかもしれないけど、こういうことやりたいと思ったときに、diconの方がすぐにかける。

SpringのXMLは、xbean使って、シンプルできるというけど。正直あれでシンプルになったとは思えない。XML名前空間を使う時点で開発者の80%が引くんじゃないかと。致命的なのは、xbeanて結局はオレオレXMLだから、結局は覚えることを増やしてしまうこと。あとは、XMLの要素や属性がどのクラスのどのフィールドに対応するのかが隠蔽されるから、いざ解析しようとしたときに手間が増える。

Seasar2は、xbeanのようなよりシンプルにdiconを定義できる仕組みが必要だと感じたことがない。そもそも、そんなにdiconをいじくり回さなくていいようになっているからだけど。

最後に、感覚的だけど、おもてなしの精神がSeasar2には感じるけど、Springからはそれを感じない、むしろ何か冷たさを感じる。

*1:というか、そうなることを念頭において開発しているところ。