ServiceにFormを直接渡してはいけない理由

Question

Controller から Service を呼び出すときに、FormをなぜそのままServiceに渡してはダメなのでしょうか？
Controller から Serviceに直接Formを渡した時に、起こる問題点を教えて下さい。

☆背景
業務アプリケーションを作りたく、Controller/Serviceが1対1になる構成にしようと思っています。
Controller と Service が1対1になると、どうしてもFormからDTOの詰替えが無駄に思えてしょうがないです。
→ Controller と Serviceが多 対 1になるならば、絶対にbeanの詰替えが必要だと思いますが....

Form から DTOへ詰め替えなかった場合、こんな感じのソースになるのをイメージしています。
このコード、どこか問題点はありますか？

@Controller
public class TestController {

	@Autowired
	private TestService testService;

	@RequestMapping("/registor")
	public String registor(TestForm form) {
		this.testForm = form; // ServiceはRequestScope
		this.testService.validate();
		
		return "index";
	}
}

@Service 
public class TestService {
	
	public TestForm testForm;
	
	public boolean validate() {
		return true;
	}
}

Answer 1

→ Controller と Serviceが多 対 1になるならば、絶対にbeanの詰替えが必要だと思いますが....

まさにこれが理由だと思います。

今、コントローラとサービスを1対1に構成したとしても、
アプリケーションを拡張していくと、いつか多対1にしたいシチュエーションが発生するかもしれません。

また、NARH様の回答のように、画面とテーブルのデータ構造が不一致になった際にも不都合が生じます。

そのような場合に備えるためのアーキテクチャなのだと思います。

もっとも、ここからは私見ですが、あまり教科書どおりのアーキテクチャにこだわる必要はなく、
redhat98様が
「コントローラとサービスの1対1構成が崩れる可能性はきわめて少ない」
と判断されるなら、フォームを直接サービスに渡してしまってもよいと思います。

このようなことは、実装のコストと問題が起きる可能性を天秤にかけた上で判断すべきだと思いますので。

※フォームオブジェクトの役割などを判りやすくまとめている記事を見つけました。
参考までにご紹介します。
http://yyyank.blogspot.jp/2013/07/javabeansbeandtoentityvoformwhat-is.html

Comments

[redhat98]

回答ありがとうございます。

こんな作りってありでしょうか？
共通で使うService ----> FormからDTOに詰め替える
共通化出来ないService(未来永劫に共通化できない前提)
----> FormをServiceに直接渡す

-----------------------------------------------------------------------
どんな時もFormからDTOに詰め替えるというのがベストだと思います。
けれども、
1. DTOが大量に出来てしまう
2. そもそも詰替えのロジックを書くのが面倒(ライブラリ使っても面倒)

って所が問題だなと思います。
DTOが大量にできてしまうってところが、すごい痛いなと思いました。

[KiyoshiMotoki]

> 未来永劫に共通化できない前提
であれば、私はありだと思います。

こういうことは保険と同じだと思っており、
例えば自動車に乗らない人が自動車保険に入って保険料（コスト）を支払うのは、
無意味ですよねw?

後になって
「やっぱり自動車に乗りたい」
となったときに、大きなコストを支払わなければならないかもしれないところは
保険と異なりますがw

Answer 2

コントローラとサービスが1対1としたから、そうなったのでは？

コントローラはサービスに対して右から左に流しているだけのようですが、サービスが無駄に思えない理由は何故ですか？

また、そのアーキテクチャでは、拡張時に困りませんか？例えば、データベースのテーブルに項目追加になったとき、関連するフォームとサービス全て修正することになります。

さらに、その追加になった項目が、画面では必要ないものだった場合は、フォームの役割が、画面によるものなのか、データベースによるものなのか、曖昧になります。

それは設計するときに意識しなければならない事が、画面とデータベースの2つになり、ややこしくなり、後に他の人が担当したときに、仕様が伝わりにくくなりますから、結果として関心事の分離ができていなく、変更に弱いアーキテクチャになってしまいます。