StrutsでWEBアプリを作成する際の基本クラス設計

私はエンタープライズ向けシステムのアプリケーションの構築を本職としていますが、エンタープライズ向けのWEBシステム構築の世界ではStruts 1.2系をベースにアプリケーションを構築することが今だに多いです。 Strutsをベースにしたフレームワークが存在していることやプログラマを集めやすいこと、業界にStrutsのノウハウが蓄積されていることなどが理由としてあると思います。 そんなStrutsをベースにプロジェクトを始める際に毎度行われるのが、業務における基本クラス(親クラス、共通クラス)の設計で、WEBアプリケーション構築のノウハウを如何にそこに蓄積させるのかに頭を悩ませるわけです。

ここでは今までの経験を基に、どのような考え/考慮に基づいてStrutsベースのWEBアプリの共通クラスを作成すればいいのかを備忘録も兼ねて記述します。

HTTPセッション

WEBアプリケーションの考えから絶対に切り離せないのがHTTPセッションです。 HTTPセッションを扱う処理をどのように共通化するかは、誰でも悩むところではないかと思います。 HTTPセッションに関して考慮しないといけないことは以下のような観点です。

• HTTPセッションの開始・破棄・再生成のタイミングと方法の問題
• ログイン者の情報を引き回す必要があるような管理サイトなどで、どのようにログイン者のID(ページに共通して必要な値)をどのようにHTTPセッションで管理するのか
• HTTPセッションよりも更に狭い画面遷移スコープでの値保持。 例えば、管理サイトの中にある「◯◯登録機能」「◯◯実行機能」などの単位での値保持。
• HTTPセッションのキーの重複を回避する方法 (HTTPセッションのキーの管理)

よくありがちな問題は、例えば作成するWEBアプリケーションの中で「○○登録画面」と「××登録画面」があって、それぞれに「メールアドレス」の登録項目があった場合、それぞれの画面を違うプログラマが作成した際にHTTPセッションのキーが「email」などという名前で重複してしまい、HTTPセッションに保存されている値をお互いに変更しあってしまうことです。 この初歩的な恥ずかしい問題は、キーの命名規則や管理方法の検討が不十分な事から起こります。 このような問題を共通クラスの構造である程度解決しておくこともできると思います。

例外処理

例外の処理方法も考慮すべき点です。

• Actionクラスまで上がってきた例外を、「どこで」「どのように」処理するのか
• Actionクラスの中で発生した例外を、「どこで」「どのように」処理するのか

Actionクラスの中で共通的に例外を処理する場合もありますし、SAStrutsなどを利用している場合は Interceptor で例外を共通的に処理する場合もあるかと思います。

Actionクラス層の責務範囲

Actionクラス層が責務とする範囲を明確にする必要があります。

• Actionクラス層で責任をもって扱わなくてはならないデータは何か？
• 下位クラス (SAStrutsであればServiceクラス)への値の引渡し方法の明確化。 DTOを利用して値を渡すのか、下位クラスに直接個別に渡すのか等。

よくある責務範囲の設定としては「HTTPセッションへのアクセスはActionクラス層で行う」というルールです。 下位のクラス(Serviceクラスなど)でHTTPセッションの値にアクセスすることを禁止し、下位クラスでHTTPセッションの中の値を参照したい場合は、Actionクラス層でデータを取得してDTO経由で渡すなどのルールを決めます。

まとめ

以上、Actionクラスを中心に考慮すべき点を列挙しました。 Actionクラスよりも下のレイヤーについては、それぞれの企業やプロジェクトによって自由にやっていると思いますので、ここで一概に言うことができません。 SAStrutsであればServiceクラスが用意されているので、それをベースに考える場合もあるでしょう。

とりあえず、StrutsベースのWEBアプリケーション開発では Action クラス関連のルール決めがWEBアプリケーションの設計のかなりのウェイトを占めると感じています。 設計漏れがないように慎重に決定が必要だと考えています。