![[PukiWiki]](image/seasar.png "[PukiWiki]")
たまには、まじめにSpringと比較してみましょう。 1.Seasar2ではOGNLの導入により、Springのvalueタグ、refタグといったタグを書く量が増えることやPropertyEditorの登録といったことをする必要がありません。 2.Seasar2の型によるautoBindingは、interfaceの型だけに絞っているので、誤作用することがありませんが、Springのautowire="byType"は、クラスの型で単純にぶつけているように見えるので、誤作用することが多いと思います。だから、byTypeはお勧めではないのでしょう。型による自動バインディングが実用的に使えるかどうかは、定義ファイルの量を減らすだけでなく、間違いも減らせます。 3.Seasar2では、柔軟な定義ファイルのinclude機能により、目的別に定義ファイルを分けることができるので、定義ファイルが肥大化するのを避けることができますが(S2JSFのサンプルのdiconパッケージを見れば分かります。)、Springでは単純な親子関係しか定義できないので、定義ファイルがすぐに肥大化してしまう危険性が高くなります。大規模なプロジェクトには向かないではと思いますが、XDocletを使うと良いらしいです。 4.Seasar2では、アスペクトを簡単に利用できますが、Springではアスペクトを直接コンテナが意識はしておらず、Beanとしてがんばって実現しているので、結果的に使いづらくなっています。アスペクトは、DIContainerを使う上での重要なポイントの1つです。ここが使いにくいと生産性が低下します。 5.Seasar2では、インスタンス管理をsingleton, prototype, outer, request, sessionと目的に応じて使い分けられますが、Springはsingletonとprototypeだけです。前にThreadLocalはサポートするといっていたので、最新版ではあるのかも。Springではsingletonという属性名なので厳しい気もしますが。 6.Seasar2では、method injection(Springのlookup-methodとは違う)により、すべてのJavaのクラスに対して、DIすることができますが、Springは、そのような機能がないので、FactoryBeanを使うことになりますが、そうするとSpringに依存することなります。 7.Seasar2では、initMethod,destroyMethodを複数定義できますが、Springは1つだけです。新たなクラスを作るときには、問題になりませんが、既存のクラスを使うときに困るときがあるかも。 8.Seasar2では、アスペクトが設定されているメソッドから同一インスタンスの別のアスペクトが設定されているメソッドを呼び出したときに、もちろんアスペクトが適用されますが、Springは最初のメソッドしかアスペクトは適用されません。 9.Springはデフォルトのコンストラクタがないとアスペクトを適用できません。Seasar2には、そのような制限事項はありません。 10.Springには、lookup-methodがありますが、Seasar2にはありません。以前は、getter injectionとしてサポートするつもりでしたが、テストがやりにくくなるのと、instanceをrequestで管理すればよいので、不要だと思っています。 11.Springには、メッセージのリソースを管理する機能がDIContainerにありますが、Seasar2ではDIContainerにそのような機能はありません。そのような機能はコンテナにある必要がないと思っているためです。 12.Springには、イベントを管理する機能がありますが、Seasar2にはありません。なぜなら、そんなことするとコンテナに依存してしまうからです。 13.SpringはBeanの定義を確か継承できますが、Seasar2はできません。 14.SpringはBeanの定義のデフォルト値を定義ファイルごとに設定できますが、Seasar2はできません。 Seasar2とSpringってどこが違うんですかというのは、意外としられていないようなので、まとめてみました。 この比較は、あくまでもSeasar2側からの視点です。
