ゆーたんのつぶやき

株式会社ノークリサーチにてIT関連のシニアアナリストとして活動しています。

Strutsの今後とJSF



StrutsJavaベースのWEBアプリケーション開発では最もメジャーなフレームワーク
ですが、JSFの登場によってその将来についていろいろと言われているようです。


Struts自体は1.2の段階で本来のコンセプトはほぼ完遂しているように思います。
コミュニティの中では「フレームワークはシンプルであるべきで、さらなる機能
追加を行うのであれば、それはStruts本体とは切り離すべきだ」という意見も見
受けられます。コミュニティの方針によって下位互換性は重視してきましたから
少なくとも1.x世代については互換性を保ちつつ、便利な機能を少しずつ追加して
いくというロードマップになると思われます。その反面、2.X世代については
ドラスティックな基本設計の転換が起るかも知れません。


一方のJSFですが、Java標準ということもあり多くのベンダーが既に対応製品を
出荷しています。ボク自身もJSFには当初から注目しており、ベータの段階から
あれこれと試しています。


Strutsの資産を抱えている開発者にとっては今は難しい選択の時期かと思います。
このままStrutsを使いつづけるか、JSFへと移行していくかという選択です。


結論から言いますと、ケースバイケースではないかと思います。両者は同じ性格
フレームワークだと言われますが、本質は異なっているとボクは理解しています。
StrutsMVCのCにフォーカスしたフレームワークでURLに記述されたアクションが
トリガーとなってビジネスロジックが起動されていきます。一方のJSFはSwingの
イベントモデルのアナロジーになっていて、UIコンポーネントをユーザーが操作
したことによるイベントがビジネスロジックを起動します。


ですので、旧来のWEBアプリケーションのように画面遷移とユーザーの操作単位
(ユースケースの単位)が一対一に近い形で対応しており、高度なUI部品を扱う
必要もない場合にはStrutsが適しているでしょう。一方で画面遷移とユーザー
の操作が必ずしも一致しない(一つの画面で複数の異なるサブミット処理をさせる等)
場合で、高度なUI部品を扱う場合、つまりリッチクライアント的なUIを実現させたい
場合にはJSFの方が適しています。特にある程度粒度の大きいUI部品をカスタムタグ
として作成し、それを複数箇所で利用したい場合にはJSFは大きな助けになります。
JSFでは画面上のUI部品をコンポーネントツリーとして管理していますが、仮に同じ
IDを持つコンポーネントがあったとしても、それらが異なるサブビューに属していれば
きちんと名前修飾を行って名前衝突を回避してくれます。これは開発ツールなどに
よってUI部品をD&Dで配置したいような場合にはとても重宝します。


JSFのUIコンポーネントの仕組みは強力ですから、Strutsを使い続けるにしても
それらの恩恵は授かりたいものです。ここ最近で紹介されることが多くなった
Struts-Facesがまさにそれです。StrutsJSF双方の生みの親とも言える
Craig McClanahan氏も「少なくとも表示部分についてはJSFなどの代替手段が
出てきているので、StrutsのHTMLタグを使いつづける開発者はいないだろう」
とコメントしています。(以前に同氏と直接お話させていただく機会がありましたが
温厚な感じのおじさんといった感じでした。休暇中のホテルでStrutsの基本部分を
一気にコーディングしてしまった方なのでパワフルなオーラを出しまくっている印象
を想像していたのでちょっと意外でした^_^) ですので、Strutsの継続利用であれば
Struts-Facesを活用し、将来的にリッチなUIを要求される可能性が高いのであれば
早々にJSFに移行するのが無難ということになるかと思います。


もし、ボクがStrutsからJSFへ移行するとしたら以下のようなことを気をつけると思います。


※長くなりすぎてしまったので、続きはまた明日....