Spring2.5は生産性もかなり良い
http://d.hatena.ne.jp/higayasuo/20080613/1213326209
ひがさんもブログの中で書かれていますが、Spring2.5は生産性を上げる為の取り組みをかなり行っているので、以前のようにXMLヘルになることはありません。設定ファイルだけで見ればSeasar2よりも記述量は少ないくらいです。
例えばコンポーネントの自動登録。現在のSpringには、検索元となるパッケージ名とクラスの検索パターンを指定すれば、コンポーネントを自動登録してくれる機能があります。
http://static.springframework.org/spring/docs/2.5.x/reference/beans.html#beans-scanning-filters
<beans ...> <context:component-scan base-package="org.example"> <context:include-filter type="regex" expression=".*Stub.*Repository"/> <context:exclude-filter type="annotation" expression="org.springframework.stereotype.Repository"/> </context:component-scan> </beans>
Springのドキュメントの例では正規表現を使っていますが、他にもアノテーション、AspectJ表記法など、かなり柔軟な検索パターンを定義することができます。自動登録するコンポーネントの命名定義やコンポーネントのライフサイクルスコープも個別に定義可能です。Seasar2.4のように最初から自動登録のパターンを規約定義しているわけではありませんが、一人のアーキテクトが仕組みを理解しパターンを構築すれば、開発プロジェクトではSpringに対するコンポーネント登録をほぼ意識しなくて済むようになります。
続いてAOP機能。正直言ってこの機能に関しては、Springは他のDIコンテナの追随を許していません。V1.Xの頃はSeasar2に比べて色々と制限事項が多すぎたSpringのAOPですが、V2になって立場は逆転しています。例えば、Springはコンストラクタで作成するSpring管理外のオブジェクトに対してAspectをかけることが出来ます。この機能を使えば、Springとの連携機能を持たないフレームワークに対して、簡単にDI×AOPを提供可能です。このブログでも、Spring未対応のJAX-RS Jerseyで、DI×AOPを定義したResourceクラスを動かす実験をしてみましたが、何の問題も無く動作しました。
ここまで書くとめちゃくちゃ機能アップしたように感じますが・・・からくりは単純で、SpringAOPではなくAspectJにAspect定義を委譲する機能があるからです。SpringはAspectJを簡単に定義・実行出来るための環境を提供しています。LoadTimeWeavingを初期化時に実行し、APサーバのClassLoaderに動的コンパイルされたクラスを登録してくれます。Tomcatでこの環境を構築できるので、開発時はTomcatでLoadTimeWeavingを行い、AspectJ未対応のAPサーバにデプロイするときにはAspectJの事前コンパイルに切り替える・・・という手法を取ることができます。このAspectJに対応するJUnitテストクラスも用意されています。
AspectJのAspectを書くのがめんどくさいじゃないかと思う人もいるかと思いますが・・・そもそもSpring2ではAspectJ形式のAspect記述方法が標準となっています。SpringAOPを使う場合も、AspectJの表記法を使ってAspectを書くのです。これは良い発想の転換ですね。おそらく、まずは表記法をAspectJ形式で統一してしまって、将来のバージョンでAspectJによるAOPを標準にしてしまう計画なんでしょうね。AspectJのAOP定義は前述のコンポーネント自動登録以上に柔軟で、対象クラス・メソッドパターンを色々と指定することが出来ます。アーキテクトがこの手法を理解してAspectを定義すれば、開発者はAOPの定義を意識することはありません。
その他、Seasar2にあってSpringに無い機能としては、コネクションプール・JTA実装が用意されていないこと、SAStruts並にStrutsを改良するラッパープロジェクトが無いこと、SMART deploy機能が無いことが挙げられます。最初の件に対しては対応は簡単で、Seasar2のコネクションプール・JTA実装をSpringから呼べば解決です(笑)。Struts拡張については・・・Springの基本方針として、ラッパープロジェクトは提供せずに他フレームワークとの連携機能に徹する主義ですので(Hibernateにだけはやけに介入してくるけど)、そこは割り切って考えた方がいいと思います。WebフレームワークはStrutsだけではないし、Springと連携できるWebフレームワークは他にいくらでもあります。前述のAspectJを使えば、未対応のフレームワークとだって連携できます。SAStrutsとの連携だって、AspectJを使えばやれないことはないでしょう。個人的には、Springを使うのならSpringMVCとかを先に検討した方がいい気がしますが。
SMART deployだけは、現在のSpringでは対応は難しいかと思います。でも逆に言えば、SMART deploy以外の生産性向上に関する取り組みはSpringでも十分に実行可能です。AOPに関してはSeasar2以上の機能も提供しています。
結局のところ、「Springで生産性が上がらない」のではなく「Springを使いこなせていない」のだと思います。