[[S2i18n]]
* 元文 [#t8e9b695]
-たまには、まじめにSpringと比較してみましょう。
-Seasar2ではOGNLの導入により、Springのvalueタグ、refタグといったタグを書く量が増えることやPropertyEditorの登録といったことをする必要がありません。
-Seasar2の型によるautoBindingは、interfaceの型だけに絞っているので、誤作用することがありませんが、Springのautowire="byType"は、クラスの型で単純にぶつけているように見えるので、誤作用することが多いと思います。だから、byTypeはお勧めではないのでしょう。型による自動バインディングが実用的に使えるかどうかは、定義ファイルの量を減らすだけでなく、間違いも減らせます。
-Seasar2では、柔軟な定義ファイルのinclude機能により、目的別に定義ファイルを分けることができるので、定義ファイルが肥大化するのを避けることができますが(S2JSFのサンプルのdiconパッケージを見れば分かります。)、Springでは単純な親子関係しか定義できないので、定義ファイルがすぐに肥大化してしまう危険性が高くなります。大規模なプロジェクトには向かないではと思いますが、XDocletを使うと良いらしいです。
-Seasar2では、アスペクトを簡単に利用できますが、Springではアスペクトを直接コンテナが意識はしておらず、Beanとしてがんばって実現しているので、結果的に使いづらくなっています。アスペクトは、DIContainerを使う上での重要なポイントの1つです。ここが使いにくいと生産性が低下します。
-Seasar2では、インスタンス管理をsingleton, prototype, outer, request, sessionと目的に応じて使い分けられますが、Springはsingletonとprototypeだけです。前にThreadLocalはサポートするといっていたので、最新版ではあるのかも。Springではsingletonという属性名なので厳しい気もしますが。
-Seasar2では、method injection(Springのlookup-methodとは違う)により、すべてのJavaのクラスに対して、DIすることができますが、Springは、そのような機能がないので、FactoryBeanを使うことになりますが、そうするとSpringに依存することなります。
-Seasar2では、initMethod,destroyMethodを複数定義できますが、Springは1つだけです。新たなクラスを作るときには、問題になりませんが、既存のクラスを使うときに困るときがあるかも。
-Seasar2では、アスペクトが設定されているメソッドから同一インスタンスの別のアスペクトが設定されているメソッドを呼び出したときに、もちろんアスペクトが適用されますが、Springは最初のメソッドしかアスペクトは適用されません。
-Springはデフォルトのコンストラクタがないとアスペクトを適用できません。Seasar2には、そのような制限事項はありません。
-Springには、lookup-methodがありますが、Seasar2にはありません。以前は、getter injectionとしてサポートするつもりでしたが、テストがやりにくくなるのと、instanceをrequestで管理すればよいので、不要だと思っています。
-Springには、メッセージのリソースを管理する機能がDIContainerにありますが、Seasar2ではDIContainerにそのような機能はありません。そのような機能はコンテナにある必要がないと思っているためです。
-Springには、イベントを管理する機能がありますが、Seasar2にはありません。なぜなら、そんなことするとコンテナに依存してしまうからです。
-SpringはBeanの定義を確か継承できますが、Seasar2はできません。
-SpringはBeanの定義のデフォルト値を定義ファイルごとに設定できますが、Seasar2はできません。
-Seasar2とSpringってどこが違うんですかというのは、意外としられていないようなので、まとめてみました。
-この比較は、あくまでもSeasar2側からの視点です。
* 英文 [#cdc30c89]
-Today, I would like to compare Seasar2 with Spring seriously.
-Implemented OGNL, Seasar2 does not bother you in writing the Spring value tags, refference tags, and registering the PropertyEditor.
-AutoBinding by types in Seasar2 focuses on the type of interfaces, and it takes glitches off. On the other hand, autorite="byType" in Spring seems to simply use matching of the type of Classes, and it can cause glitches. Therefore, byType is unrecommended. The usability of auto-binding by types can reduce not only amounts of configuration file but also mistakes.
-Seasar2 has some flexibilities of file include functions, that allows you to divide and cut down configuration files on purpose. (You can see them in the dicon package of the S2JSF sample). In Spring, you can define only simple parent-child relationship, and it might cause the enlargement of the configuration file. Spring is not useful for a large-size project, but XDoclet solve this problem.
-Seasar2 brings you to ease of implying Aspects, but Spring does not. In Spring, beans imply Aspects, but a container does not imply Aspects directly. Aspects is one of the most important key when we think of DIContainers. The inconvenience of the Aspects directly reduces the productivity.
-Seasar2 have various instance management methods such as singleton, prototype, outer, request, and session. Spring offers only singleton and protptype only. Still, I heard that ThreadLocal will be supported, then the newest version might have it. Even so, it might be hard to be supported well because singleton is a name of attribute value in Spring.
-You can apply DI to every Java Classes by using Seasar2's method injection (it is different from lookup-method in Spring). Spring does not have such functions, then force you to use FactoryBean depending on Spring.
-In Seasar2, you can multi-define initMethod and destroyMethod. You cannot in Spring. Even thought it cannot be a problem when you make a new class, it can be when you use existing classes.
-Seasar2 can apply the Aspect to the method which is called from the another method in the same instance configured different Aspect. However, Spring can apply the Aspect to only the first method.
-Spring cannot use Aspects without a default constructor. Seasar2 does not have such a prerequisite.
-Spring has lookup-method, but Seasar2 does not. A little ago it was planned to be supported as getter injection, but it was canceled for two reason. One is that the lookup-method makes the testing difficult, and the other is that it is thought that instances can be managed using request.
-The Spring's DIContainer has the message resource management function, but Seasar2's does not have. I think that it is no need for DIContainer to have such a function.
-Spring has the event management function, but Seasar2 does not. It occurs dependency on the container.
-Spring can inherit the bean configuration, which Seasar2 cannot.
-Spring can defines the default value of the bean configuration for each configuration file, but Seasar2 cannot.
-The differences between Seasar2 and Spring are not well-known, then I just organize them this time.
-This comparison is on the side of Seasar2.
* コメント [#dda5fd1b]
-ローカルで訳していたのでUPさせて頂きました。下訳として利用して下さい。 -- [[Terada]] &new{2004-12-04 (土) 04:35:08};
#comment
![[PukiWiki]](image/seasar.png "[PukiWiki]")
