最近、再びStrutsをいじるようになったことで、あらためてStrutsのアーキテクチャが古くなったことを感じた。Strutsは2001年ごろに開発されたものであり、1.X系は、現在もそのアーキテクチャを引き継いでいる。そのため、去年あたりから注目されているPOJOやDIという概念に対応していないのだ。
POJOへの未対応でわかりやすいのは、ActionFormの存在だ。ActionFormの責務は、reset、validate、そしてマルチパートのハンドリングだ。つまり、入力情報に関わることは自分で処理するというオブジェクト指向らしい考え方である。しかし、現在であれば、ActionFormをPOJOにしてしまい、validateやresetは、Actionにおいて実施すればよいと考えるだろう。すぐに思いつくメリットとしては、Strutsから先のビジネスロジックに引数として渡しやすいこと。ていうか逆で、ビジネスロジック用のトランスファーオブジェクトをそもままActionFormとして使うことができる。さらに、Validatorに加えて、Actionで追加処理が出来るようになる。これまでは、Validatorでエラーになると、Actionまで処理がこなかったため、Vlidatorで正常終了した後でないと、作りこみのバリデーションチェック処理が行えなかった。Actionまで処理がくれば、こんな問題はなくなる。
次にDIだ。struts-config.xmlが、DIコンテナの設定となるわけだ。Actionに対してビジネスロジックの実体をinjectできればの実装設計もテストも楽になるだろう。さらに、ServletAPIへの依存をなくすという選択肢も可能なはずで、テストがぐっと楽になるはずだ。
ま、McClanahan氏も、だいぶ前から同じことを思っているので、彼自身がスペックリードを務めたJSFでは、POJO対応やServlet APIの切り離しが行われている。さらに、Struts2.0として企画されている「Struts Shale」は、DIコンテナの組み込みが予定されている。JDK5.0対応も予定されているので、アノテーションも使えることだろう。まだ、詳細は見えないが、現在、考えられるWebアプリケーション用コントローラとしての完成形といえる気がする。
（が、既存の1.Xとは、まったく異なるアーキテクチャになってしまうので、Strutsを名乗るのもどうかとは思う）
というわけで、枯れてしまった1.Xではあるが、枯れているなりにメリットもある。Strutsを経験しているプログラマが多く、商用製品でもサポートされている。なにより、4年にもわたって、人気のフレームワークであり続けたというのは、十分に採用にいたる理由になることだろう。
