✅ 本記事のねらい
Struts2におけるアクションクラスの設計は、単なるリクエストの受け口にとどまらず、
「アプリ全体の保守性・拡張性・わかりやすさ」を左右する重要な設計ポイントです。
本記事では、以下の3つのアクションクラス設計スタイルを比較しながら、
それぞれの特徴・メリット・デメリット・適用判断基準について整理します。
- はじめに：アクションクラス設計がUXと保守性を左右する
- スタイル①：1クラス1ユースケース型（単機能Action）
- スタイル②：1クラス多メソッド型（機能集約Action）
- スタイル③：共通BaseAction型（抽象化による責務分離）
- 【比較表】3スタイルの特徴と選定基準まとめ
- おわりに：設計スタイルに「正解」はない。文脈で選ぼう
1. はじめに：アクションクラス設計がUXと保守性を左右する
Struts2のアクションクラスは、ユーザーからの入力（リクエスト）を受けて処理を分岐し、
結果をビューに返すという重要な役割を担います。
ユーザー操作 → アクション層 → サービス層 → DB → 結果を返却（JSP等）
このアクションクラスの設計方針を誤ると…
- ファイル構成が散らかる
- 機能の責任が曖昧になる
- 画面遷移がわかりにくくなる
- コードの読みやすさ・変更しやすさが損なわれる
といった問題を引き起こします。
逆に、適切な設計スタイルを選べば、UX（ユーザー体験）と開発効率が大きく向上します。
2. スタイル①：1クラス1ユースケース型（単機能Action）
🔸 特徴
- 1画面、1ユースケースに対して1つのActionクラス
- それぞれが独立した単機能を担う
✅ メリット
- コードが短く、読みやすい
- 処理の責務が明確で、テストもしやすい
- ユースケース単位でファイルが完結
⚠ デメリット
- Actionクラス数が多くなりやすい
- 処理の共通化が難しくなる（重複コードの温床に）
🧩 向いているケース
- CRUD処理が中心の業務システム
- 開発メンバーのスキルに差があるチーム
3. スタイル②：1クラス多メソッド型（機能集約Action）
🔸 特徴
- 1つのActionクラスに複数のメソッドを持たせ、複数機能を担当
-
method属性などで切り替え
<action name="user" class="UserAction" method="register">
<action name="user" class="UserAction" method="delete">
✅ メリット
-
ファイル数を抑えられる
-
関連機能を1ファイルに集約できて見通しがよい
⚠ デメリット
-
クラスが肥大化しやすく、責任が曖昧になりやすい
-
テスト時にMockが複雑になることも
🧩 向いているケース
-
1画面に複数機能がある複合画面（一覧・検索・削除など）
-
担当者が熟練しており責務分担を意識して書けるチーム
4. スタイル③：共通BaseAction型（抽象化による責務分離）
🔸 特徴
-
各ActionクラスはBaseActionを継承
-
セッション・リクエスト・共通メッセージ処理などを集約
public class BaseAction extends ActionSupport implements SessionAware {
protected Map<String, Object> session;
public void setSession(Map<String, Object> session) {
this.session = session;
}
}
✅ メリット
-
重複処理（例：ログインユーザー取得）が一元化
-
共通機能の変更が1箇所で済む
⚠ デメリット
-
継承構造が複雑化しやすい
-
過剰に共通化すると副作用が起きる
🧩 向いているケース
-
ログイン/権限/画面フローが複雑な中〜大規模アプリ
-
チーム開発で共通ルールが統一されている環境
5. 【比較表】3スタイルの特徴と選定基準まとめ
| スタイル | 保守性 | 可読性 | 拡張性 | 向いているケース |
|---|---|---|---|---|
| 単機能型 | ◎ | ◎ | △ | CRUD中心、シンプルな業務画面 |
| 多機能集約型 | △ | ◯ | ◯ | 関連処理が密接な複数機能の統合画面 |
| BaseAction継承型 | ◯ | △ | ◎ | 中～大規模、権限/セッション処理が必要なシステム |
6. おわりに：設計スタイルに「正解」はない。文脈で選ぼう
アクションクラスの設計スタイルには「これが正解！」というものは存在しません。
選定時に大事なのは、「何を重視したいか（読みやすさ／共通化／今後の拡張）」と
「チーム体制やアプリの成長段階」に応じて適切なバランスを取ることです。
✅ 迷ったときは…
- まずは単機能で作る → 後でBaseActionなどで共通化
- 機能単位で整理してから、共通処理や粒度を揃える
- 拡張を意識した「設計コメント」や「Javadoc」も後の保守に効きます！
🔜 次回予告：Vol.11.2.3「戻り先制御と画面遷移の設計パターン」
-
input / success / error / cancel をどう設計に活かすか？
-
複数遷移先を持つActionの設計テクニックとは？
-
ユーザーの操作意図に沿った自然な画面遷移設計へ！
ご感想・ご質問・実プロジェクトでの工夫など、ぜひコメントでお寄せください🙏
次回もよろしくお願いいたします！
✨ シリーズまとめ（Vol.11.2.xx アクション層設計）
-
✅ Vol.11.2 UX改善に効く！アクション層設計と入力制御の極意（プロローグ） ― アクション層からはじめるStruts2の“わかりやすい画面遷移”と“操作性向上” ―
-
✅ Vol.11.2.1 アクション層の役割と設計パターン ―「ただのリクエスト受け口」から「ユースケースの橋渡し役」へ―
🧭 関連記事（Vol.11.xxxシリーズ）
| 連番 | タイトル | 内容分類 |
|---|---|---|
| Vol.11.0 | Struts2が提供してくれる便利機能まとめ9選 | 導入＆概要 |
| Vol.11.1 | 自動注入とステートレスActionの仕組み | フレームワーク内部理解 |
| Vol.11.2 | UX改善に効く！アクション層設計と入力制御の極意（プロローグ） | UX設計・アクション層総論 |
| Vol.11.2.1 | 【実践編】Struts2アクション層の役割と設計パターン（Command型 / UIアクション分離など） | アクション設計パターン |
| Vol.11.2.3 | 【設計ノウハウ】多画面遷移時のパラメータ受け渡し・保持戦略（セッション vs hidden vs URL） | パラメータ多重管理 |
| Vol.11.2.4 | 【実践ガイド】ユーザー操作を考慮したアクション遷移設計（リダイレクト vs フォワードの使い分け） | UX遷移設計／Result制御 |
| Vol.11.2.5 | 【トラブル防止】アクション層の共通処理とメンテナブルなBaseAction設計 | アクション共通化／保守性 |
| Vol.11.3 | Struts2の defaultStack とは？Interceptorの中身を詳しく追ってみる | Interceptor |
| Vol.11.3.2 | 🔧 Vol.11.3.2 独自Interceptorの作り方と使い所 Struts2のカスタマイズを“実践で使えるレベル”に一歩進めよう | Interceptor |
| Vol.11.4 | 入門者のための「パラメータ自動バインディング」完全理解ガイド | 自動バインディング |
| Vol.Vol.11.4.1 | 入門者のための自動バインディング実践パターン集 | 自動バインディング |
| Vol.11.5 | Struts2の構成理解が“実務レベル”へと進化する決定版 | 設定ファイル構造 |
| Vol.11.5.1 | Struts2の“画面遷移の全体像”を理解するためのマイルストーン記事 | 設定ファイル構造 |
| Vol.11.6 | ActionSupport の便利メソッドと国際化対応 | ユーティリティ / i18n |
| Vol.11.7 | validate() / input 戦略とUX設計 | 開発スタイルの違い |
| Vol.11.8 | アノテーションベースの設定 vs XML定義の比較 | 開発スタイルの違い |
| Vol.11.9 | バリデーション完全解説（XML / アノテーション） | バリデーション（※Vol.8補完） |
| Vol.11.10 | Struts2の「OGNL」ってなに？しくみと使い方をやさしく解説 | 式言語OGNL解説 |
| Vol.11.11 | ModelDriven インターフェースの使いどころと注意点 | Model駆動開発 |
| Vol.11.12 | SessionAware と RequestAware でセッション/リクエスト管理 | セッション管理 |
| Vol.11.13 | Resultタイプ完全解説（dispatcher / redirect / stream など） | 遷移パターン理解 |
| Vol.11.14 | Vol.11.14 ValueStackの中身を理解する – 画面とActionの橋渡し役 | Action |
| Vol.11.15 | Interceptorチェーンを自作してみよう（ログ / 認証フィルタ） | Interceptor |
| Vol.11.16 | エラー処理と例外ハンドリングの実践パターン | ハンドリング設計 |
| Vol.11.17 | Struts2でファイルアップロード機能を実装する方法 | 実装系Tips |
| Vol.11.18 | 非同期通信（AJAX）とStruts2の連携方法 | フロント連携編 |
| Vol.11.19 | セキュリティ対策（CSRF, XSS, パラメータ偽装） | セキュリティ対策 |
| Vol.11.20 | 複数フォームを安全に扱う！セッション管理と動的フォームの考え方 | セッション管理 |
| Vol.11.21 | Struts2でJSONを返す！REST API連携と非同期通信の基本設計 | セッション管理 |
| Vol.11.22 | 本番環境構成とセキュリティ設計（Apache+Tomcat+Struts2連携） | 外部公開 |