Struts2におけるリクエストパラメータの扱い（中・上級）～複数DTOとDTO利用のメリット

ActionからDTOへ格納する機能

リクエストパラメータをActionのDTO(DataTransferObject)へ格納する方法として、Struts2は以下のことを自動実行します。

• リクエストパラメータ(String)からフィールドの型へ自動型変換を試みる
• クラスの構造をたどって値を格納する

Actionが持つDTOの個数に制限はありません。

ただしModelDrivenやScopeModelDrivenを使う場合は1個のみであり、フィールド名はmodelに固定されます。

複数のDTOを持つ場面

複数のDTOを持つ場面、つまり画面からのリクエストを複数のクラスに分類している状態と言えます。次の例は UserとJob、2つのDTOを受け取る例です。

SamplaAction.java

public class SampleAction extends ActionSupport  {

	/**
	 * デフォルトアクション。
	 */
	@Action("")
	public String start() throws Exception {
		return SUCCESS;
	}
	@Getter @Setter
	private User user;

	@Getter @Setter
	private Job job;
}

このActionクラスに対するリクエストパラメータ名は、user.フィールド名、ないしは、job.フィールド名となります。

このようにリクエストパラメータ名もActionクラスのデータ構造をそのまま反映できます。

DTO利用のメリットは何か

ActionにDTOを置くことにより、Actionクラスの実装が軽くなる意外にもメリットがあります。

• 入力値検証(Validation)もDTOに定義できる。
• 自動型変換(TypeConvertion)もDTOに定義できる。

入力値検証や自動型変換は本来Actionクラスに対して定義するものですが、この定義をDTOへ委譲できます。特に入力値検証の委譲は、VisitorFieldValidator クラスが用意されており、これを使うだけです。
（自動型変換は特に宣言なく利用できます）

VisitorFieldValidatorの利用例

先ほどのSampleActionに対し、入力値検証(Validation)の設定をしたActionクラスは次のようになります。

CheckAction.java

@Validations(
	visitorFields = {
		@VisitorFieldValidator(appendPrefix=true , fieldName="user") ,
		@VisitorFieldValidator(appendPrefix=true , fieldName="job") ,
	}
)
public class CheckAction extends ActionSupport {

	/**
	 * デフォルトアクション。
	 */
	@Action("check")
	public String check() throws Exception {
		return SUCCESS;
	}

	@Getter @Setter
	private User user;

	@Getter @Setter
	private Job job;
}

@VisitorFieldValidatorの属性にて定義している内容は以下の通りです。

属性名	内容
appendPrefix	入力値検証エラーを検出したときに、エラー項目名へActionクラスのフィールド名を接頭辞につけるか否か。
fieldName	入力値検証を実施するActionクラスのフィールド名

appendPrefix=true としたとき、入力値検証エラーの項目名にActionクラスのフィールド名がつきます。例えば、Userクラスにusernameのフィールドがあった場合は、UserクラスはActionクラスでは user の名前で利用しているので、エラー項目名は user.username となります。

1つのActionで複数のDTOを扱う場合は、appendPrefixをtrueにしますし、単一のDTO、特にScopedModelDrivenを使う場合は appendPrefixはfalseにします。