質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.44%
Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

Q&A

解決済

2回答

18153閲覧

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

redhat98

総合スコア236

Java

Javaは、1995年にサン・マイクロシステムズが開発したプログラミング言語です。表記法はC言語に似ていますが、既存のプログラミング言語の短所を踏まえていちから設計されており、最初からオブジェクト指向性を備えてデザインされています。セキュリティ面が強力であることや、ネットワーク環境での利用に向いていることが特徴です。Javaで作られたソフトウェアは基本的にいかなるプラットフォームでも作動します。

0グッド

0クリップ

投稿2015/10/29 10:41

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; } }

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答2

0

ベストアンサー

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

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

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

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

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

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

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

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

投稿2015/10/29 13:23

編集2015/10/29 15:32
KiyoshiMotoki

総合スコア4791

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

redhat98

2015/10/30 03:21

回答ありがとうございます。 こんな作りってありでしょうか? 共通で使うService ----> FormからDTOに詰め替える 共通化出来ないService(未来永劫に共通化できない前提) ----> FormをServiceに直接渡す ----------------------------------------------------------------------- どんな時もFormからDTOに詰め替えるというのがベストだと思います。 けれども、 1. DTOが大量に出来てしまう 2. そもそも詰替えのロジックを書くのが面倒(ライブラリ使っても面倒) って所が問題だなと思います。 DTOが大量にできてしまうってところが、すごい痛いなと思いました。
KiyoshiMotoki

2015/10/30 03:39 編集

> 未来永劫に共通化できない前提 であれば、私はありだと思います。 こういうことは保険と同じだと思っており、 例えば自動車に乗らない人が自動車保険に入って保険料(コスト)を支払うのは、 無意味ですよねw? 後になって 「やっぱり自動車に乗りたい」 となったときに、大きなコストを支払わなければならないかもしれないところは 保険と異なりますがw
guest

0

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

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

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

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

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

投稿2015/10/29 11:22

NARH

総合スコア209

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.44%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問