SpringMVCの@ModelAttributeで毎回初期化されるのが無駄に感じます。

Question

環境

<parent>
	<groupId>org.springframework.boot</groupId>
	<artifactId>spring-boot-starter-parent</artifactId>
	<version>2.0.1.RELEASE</version>
	<relativePath /> <!-- lookup parent from repository -->
</parent>

以下のページを見ました

https://sites.google.com/site/soracane/home/springnitsuite/spring-mvc/04-ji-ben-gai-nian-controllerno-chu-lifuro

サンプルとして載っているコード

@ModelAttribute("user")  //②モデルの前処理
public User newRequest(@RequestParam(required=false, value="id") String id) {
  if(id== null) return null;
  return this.accountService.get(id);
}

以下が無駄だと思う理由です

（１）．@ModelAttributeの呼び出し　　：　事前準備として、DBからPOJOを取得して、Model に登録します。

（ModelAttributeメソッドでDBからPOJOを取得し、RequestMappingメソッドを呼び出すときにSpringが自動的に画面の値で必要なPOJOフィールドを更新する）

• 調べてみたら確かに@RequestMappingの前に必ず@ModelAttributeが呼ばれて初期化する事を確認しました。
• また、説明通り@RequestMappingで受け取るformは画面の値で上書きされていました。

画面の値で上書きするのであれば毎回初期化するのは無駄に感じます。
※特にDBにアクセスする場合は毎回SQL発行する事になる為

また、if(id== null) return null; に関して、初期化が必要ない場合はidが入ってこないからnullを返しているのかと考えましたが、'@ModelAttribute'でreturn null;してしまうと@RequestMappingの引数で受け取るformがnullになってしまうためvalidate処理や画面表示が正しく行われない為目的は違うんだろうと判断しました。

みなさん気にならずにそのまま実装しているのでしょうか、または別の方法で実装されているのでしょうか。

以下ならまだわからないでもないです

@ModelAttribute("user")  //②モデルの前処理
public User newRequest( @RequestParam(required=false, value="id") String id, User form) {
  if(id== null) return form;
  User user = this.accountService.get(id);
  BeanUtils.copyProperties(user, form);
  return form;
}

Comments

[退会済みユーザー]

つまり　１を変更した後に　存在しない２を変更しようとして１が更新された方がいいと?

Answer 1

画面の値で上書きするのであれば毎回初期化するのは無駄

ここに認識の誤りがあるでしょう。参照されたサイトの「掲載されているコード」全部を見ると、

リクエストパラメータ(id, nameの2つ)を受け取り、

• idが未指定なら検索しない→Controllerの本体へ
• idに何らかの値があった場合はUserを取得→Controllerの本体へ

  @ModelAttribute("user")
  public User newRequest(
      @RequestParam(required=false, value="id") String id,
  ) {
      if(id== null) return null;
      return this.accountService.get(id);
  }

Userにはid,name以外のフィールドがあるが(feeId)、画面から受け取るのはid, nameだけである。

	@InitBinder("user")
	public void initBinder(WebDataBinder binder) {
		binder.setAllowedFields("id", "name");
	}

Controller本体の処理は以下

  @RequestMapping(value="/accountEdit", method=RequestMethod.POST)
  public String form(@Valid @ModelAttribute("user") User user, BindingResult result) {
     if(result.hasErrors()){
       return "account-edit-input";
     }
     this.accountService.updateUser(user);
     return "account-edit-complete";
  }

なので、流れとしては以下ですね。AccountServiceの作りを変えない前提ならば、特に無駄はありません。

1. リクエストパラメータにidが指定されていれば、idを元にUserを検索
2. Controllerの本体へ処理が移動したときは、1で取得したUserのnameにリクエストパラメータの内容が入る( idは検索時と同じ ) このとき、該当するUserが取得できていなければUserはnullになる。
3. accountServiceのupdateUser(user) で更新する

ところで、

以下ならまだわからないでもないです

のコードを拝見しましたが、

this.accountService.updateUser(user) が抜けていませんか？

Comments

[msss]

回答ありがとうございます。
わかりやすい解説をしていただいたことで頭の中が整理できました。

・idが入っていない＝エラーのため"account-edit-input";に遷移させる。
・idが入っている場合画面入力値以外の項目（feeId）も更新に必要なので取得してリクエストパラメータで上書きして更新

確かに、SampleControllerクラスに@RequestMappingのメソッドが1つしかないので無駄に感じませんでした。

例えば
@RequestMappingが複数あった場合、@ModelAttributeが呼び出される度にDBアクセスが必要ない場合、@RequestMappingにDBアクセス処理を書くというイメージを持っていますが、間違っているでしょうか。

※
以下の内容から、@ModelAttributeでは画面に必要なデータをDBから取得するというイメージを持ってしまいましたが、時と場合（画面設計）によるということでよいでしょうか。
>【通常のControllerの処理の流れ】
>（１）．@ModelAttributeの呼び出し　　：　事前準備として、DBからPOJOを取得して、Model に登録します。

[退会済みユーザー]

はっｗ　entityを直接 form として利用するソースなのか

[msss]

ご指摘ありがとうございます。
entity=formついては確かに疑問を感じる点はありましたが今回は気にしませんでした。

[A-pZ]

無駄になるかどうかは、Controller～Serviceの設計次第ではありますね。
実際、 ModelAttributeにて実際に検索するのはトリッキーなコードにも思えます。