Struts / リクエスト駆動型のフレームワークを理解する
フレームワークとしてStrutsを利用したJava開発を初めて行うので、自分なりに理解を深めるために備忘録としてまとめてみました。勘違いしている部分があるかもしれませんので、もしあれば指摘していただけると幸いです。
フレームワークとは？
そもそもフレームワークとは、一般的には以下のような捉えられ方をしています。
- アプリケーションの基盤部分を提供
- どのウェブアプリケーションでも必要となる共通機能
- 似たような処理の作成などの無駄をなくす
- フレームワークを使うことで強制力を持たせる
- 枠組みの中での開発になるため実装方針が強制される
またフレームワークを利用することによって得られるメリットとしては以下の事が挙げられます。
- 保守コストの削減
- 同じ処理であれば、誰が実装しても同じになるためコードに一定の品質を見込める
ただし、フレームワークにある程度の自由度があるために実際にはそのままフレームワークを使うことはなくフレームワークを土台としてプロジェクトのルール(コード規約など)を挟むことになります。
フレームワークのタイプ
大きく分けると、以下にイベント駆動型とリクエスト駆動型の2タイプに分類されます。
イベント駆動型のフレームワークには以下のプロダクトが存在します。(主要なプロダクトのみ抜粋)
- JSF(JavaSever Faces)
- Sun Microsystemsが中心となり開発しているWebプレゼンテーション・フレームワーク
- Webページの構成要素をコンポーネント化し，ビジュアル開発ツールによって開発できる
- Tapestry
デザイナとの分業を考えた場合、イベント駆動型のフレームワークを利用する際、デザイナが普段利用しているDreamWeaverなどのオーサリングツールのノウハウがそのまま使えず、新たに開発ツールの使い方を理解する必要があり、非常に敷居が高くなってしまいます。またビジュアル開発ツールに依存してしまうなどというデメリットがあります。
またリクエスト駆動型のフレームワークには以下のプロダクトが存在します。(主要なプロダクトのみ抜粋)
中で最もメジャーなプロダクトでもあるStrutsは，6年前の2000年に登場しており、そのアーキテクチャのベース(Strutsが提供するクラスを継承してフレームワークを拡張することでアプリケーションを作成してゆく)が現状の新しいアーキテクチャをもったプロダクトと組み合わせが容易にできないという問題があります。以下の記事に詳しく書かれてあります。
ただし、他のリクエスト駆動型のフレームワークに比べ、メジャーでかつ豊富なドキュメントが存在するStrutsは、まだ数年は利用されていくと思われます。ただし、Struts自信も上記の問題を解消すべくStruts1.3より大幅にアーキテクチャを変更しています。(Struts 2は、Strutsと名を冠してるが、別モノと捉えた方がよいです)
Struts1.3
ITProの【Jakarta/Apacheウォッチ】第25回 リリース間近！アーキテクチャを一新したStruts 1.3：ITproという記事にて、Struts1.3のアーキテクチャについて書かれていますので、いくつかピックアップしておきます。
- 様々な機能拡張や変化にStrutsが耐えられるように部品化し、様々な他の部品や拡張パッケージ、独自実装機能とを組み合わせやすくする
- Strutsの概念自体は変わっておらず、基本的なクラスもそのまま利用可能
- Struts1.2ベースのアプリケーションをStruts1.3へバージョンアップするのは難しくない
- コントローラ、Struts-Validator、Struts-Tilesなどの各機能が機能別に開発単位を細分化し、それぞれ別のJARファイルとして配布(Struts Action Libraryと呼ばれる)
- リクエストプロセッサを全面的に書き換え(HTTPリクエストの処理に「Chain of Responsibility」パターンを導入)
- ChainOfResponsibility パターンデザインパターン[モデリング] -TECHSCORE-
- HTTPリクエストの処理で独自の処理を自由なタイミングで挿入することが可能になった
- ベースのJ2EEの仕様は、Servlet2.3/JSP1.2になっている
他にも変更点がありますので、以下の記事を参照してください。
参考書籍
STRUTS・イン・アクション
posted with amazlet on 07.01.03
