いつまでStruts1を使い続けるの？
営業支援で提案中の案件があるのですが、現状CGI＋Perlで作られているコンシューマー向けサイトがあるが、
とのことです。今時多くのコンシューマー系のサイトで、コンテンツの管理を容易にしたいならオープンソースも含めてPHPベースのCMSが星の数ほどあるという事実はおいておくとしても、とにかく、実績重視ということでStrutsということになってしまうのでしょうか？お客様もMVCなど相当技術を勉強されていることは感心なのですが、JavaのMVCフレームワークというとStrutsしか考えないというのは問題ではないのでしょうかね。多くのStrutsベースの既存システムを自社で抱えているなどの理由があるのであれば、それも一つの選択なのかもしれませんが、実績重視とか社内標準などの技術とは関係ない理由でなんとなくStrutsが選択されてしまうのは、技術者としてちょっと残念な気がします。
Spring3ではStruts連携機能が既にDeprecatedとなっていますし、Spring WebFlow2ではStrutsサポートが完全に切り捨てられているという事実を考えても、欧米では既にレガシーフレームワークという扱い方をされているようです。日本において、なかなかStruts依存体質が解消されない理由として
- Spring MVCやSeamに関する日本語の書籍が少ない
- 大手SIerフレームワークに組み込まれている
- 社内標準フレームワークに組み込まれている
- SAStrutsなどSeasar2系のプロジェクトで利用されている*1
- 新人のJava教育でもStrutsしか教えておらず（場合よってはサーブレットしか教えていないところもあるかもしれません）Strutsしか知らないプログラマーが多い
- Strutsベースの設計はActionがPOJOでないということもあり、1機能1クラス*2という手続き指向のプログラミングを続けるための免罪符となっている
- 後継として期待されたStruts2が互換性がなくあまり人気もない
など、さまざまな理由が考えられます。VB6なども.NETの登場後もずっと使われ続けて今頃になってサポート切れであわてて.NETに更改するという案件がありますが、Strutsもサポート切れなどどうしても利用できなくなるような理由がない限り、このままずっと主流として使われ続けるのでしょうか？
Struts1は以下のようにたくさんの問題点があると思うので、技術的観点からは新規プロジェクトで採用するのはいい加減に避けたいというのが私の本音ですね。
- ActionFormがPOJOでないためDTOやエンティティへの詰め替えが必要
- struts-config.xmlでXML地獄に陥る
- セッション状態の管理機能がない（マルチタブブラウザーなどの対応は自分で対応？）
- Post/Redirect/Get*3などの実装が面倒
- flushスコープ*4などの便利機能がない
- 1リクエスト1アクションクラスではAjax対応が困難
- タグライブラリーがEL式などJSP自体の進化に対応していない
- フォーム入力値は基本的にString型から他の型に手動変換することになる
- J2EE1.3、J2SE1.4など既にサポート切れのバージョンをベースに作成されている
- Spring3以降でDeprecatedに
- Seasar2の将来性が？（Seasar3開発中止 - yvsu pron. yas）
- RESTfulなURLの対応が困難
*1:SAStrutsなどは表面上Strutsとはまったく別フレームワークといっていいようなものですが、内部的にStrutsに依存しています。Spring MVCとSpring3の@MVCの関係も発想はまったく同じで、プログラミングモデルや設定ファイルはまったく別物ですが。
*2:Actionという名称自体Commandパターンの別名とされていることもあるが、ステートレスなStrutsのActionクラスはリクエストごとに別々のインスタンスを生成していないという点でGoFのCommandパターンとは本来ぜんぜん別物だと思う。
*3:Postリクエスト送信後にリダイレクトさせることでURLバーと表示内容を一致させ、二重送信の問題などを回避する処理パターン。
*4:一回のリダイレクト中のみ残るデータ領域。Ruby on Railsで有名になったと思う。
