どこかの本の題名のようなタイトルにしてみました。
今回からしばらくJavaフレームワーク等について書いていこうと思ってます。
まずは元祖WebフレームワークであるStruts。
つい先日（EOL=End of Life：寿命)を迎えたそうです。
Strutsは一時期、Java界においてはスタンダートとなり
他フレームワーク（以後、FWと表記）に
多くの影響を与えました。
後継と思われたStruts 2はWebWorksというFWを
元にしていて全然別物だとか。
そもそも日本でStruts 2は全然流行ってないです。
つまりStrutsとしては死んでしまったのです。
では、なぜそんな状況になったか考えていきます。
色々なサイトを見てみると以下の内容をStrutsの悪い点として
上げられています。
1.「POJOでない」（Action等を継承しないといけない）
2.「設定ファイルの記述が膨大」
3.「設定ファイル変更時、Tomcatの再起動かコンテキストの再ロードが必要」
4.「アクションごとにクラスが必要」
5.「カスタムタグを覚えないといけない」
他に上げているとこもありましたが、おおむねこんなとこでしょうか。
一つずつ深く考えていきます。
1.「POJOでない」
他クラスを継承する事で他クラスのコンストラクタやイニシャライザ
などで余計な動作してしまい、ユニットテストが困難です。
他FWでは、固定的な強制ではなく、DIという機能により
実行時に継承を変更することで固定的な継承を
しなくて済むようにしています。
2.「設定ファイルの記述が膨大」
主にstruts-config.xmlとvalidation.xmlですが内容が多くなりがちです。
xml地獄という言葉すら生まれました。
DynaActionFormとか使うとstruts-configの中に項目一つ一つ書くことに
なりますし、さらに大変です。
他FWではアノテーションによる記述内容の分割で
対処されています。
また、Seaser2ではデフォルト的な動作は記述を
省略することができます。
コメント分から設定ファイルを自動生成するXDocletという
JavaDocみたいなツールを使えばStrutsでも楽になりますが
今度はコメントが膨大に・・・
3.「設定ファイル変更時、Tomcatの再起動かコンテキストの再ロードが必要」
JSPやJavaファイル、Propertiesファイルは問題無いのですが
設定ファイルを変更した時はWebサーバの再起動かコンテキスト
の再ロードが必要です。
他FWではホットデプロイと呼ばれる機能で自動的に
再ロードされます。
4.「アクションごとにクラスが必要」
これはStrutsではMappingDispatchActionを使えば
excute以外の指定メソッドを呼出せるので、
そう問題ではないと思いました。
ただ、POSTとGETが同一メソッドだったりはRESTfulな
システムを作るのには使いづらいとこ。
5.「カスタムタグを覚えないといけない」
他FWでもカスタムタグはあるのでStrutsだけの
問題ではないです。
カスタムタグが嫌ならばVelocityとかテンプレートエンジンを
使えば良いかと。
今後、各FWでソースがどう異なるのか
まとめる予定です。
対象FWはSeaser2, Spring, JavaEE（JAX-RS）, Struts。
選定理由は使った事があったり興味があったり。