OSCA

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

投稿日:2012年8月5日

このエントリーをはてなブックマークに追加

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

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

HTTPセッション

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

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

例外処理

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

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

Actionクラス層の責務範囲

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

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

まとめ

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

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

著者 : OSCA

OSCA

個人として何か一つでも世の中の多くの人に使ってもらえるサービスを作ろうと日々奮闘中のエンジニア。 夜景好きのアマチュア写真家でもあります。
Twitter : @oscaphoto
Facebook : OSCA