Q&A
質問者さんは「form」と「DTO」をどういう解釈でいるのでしょうか。
他人のアドバイス100％頼るのではなく自身が調べて理解した内容もご提示ください。
現場現場で解釈が違ってくる可能性もあるし前の質問
https://teratail.com/questions/207750
で「デザインパターンで調べて」とアドバイスしたけど、調べた感がほとんどないので。
わからないこと
- formとDTOをどう使い分けるかのルール(あるべき論)について、特にViewとController周りがわかりません。
- View⇒Controller(検索)：form
- View⇒Controller(登録・更新)：form？(検索とは別のフォーム？)
- View⇐Controller(検索結果)：？？？
例
- 1画面内に検索条件と、検索結果を表示する画面があり、検索結果を更新することができるとします。
- 検索条件(V)→検索処理(C)→検索結果表示(V)→更新(C)という処理フローの場合、
案1 - 検索条件(V)→検索処理(C)：Form① - 検索処理(C)→検索結果表示(V)：Form② - 検索結果表示(V)→更新(C)：Form②
案2 - 検索条件(V)→検索処理(C)：Form① - 検索処理(C)→検索結果表示(V)：DTO - 検索結果表示(V)→更新(C)：Form②
案3 - 検索条件(V)→検索処理(C)：Form① - 検索処理(C)→検索結果表示(V)：DTO - 検索結果表示(V)→更新(C)：DTO
案4 - 検索条件(V)→検索処理(C)：Form① - 検索処理(C)→検索結果表示(V)：Form① - 検索結果表示(V)→更新(C)：Form①
案5 - 検索条件(V)→検索処理(C)：Form① - 検索処理(C)→検索結果表示(V)：DTO - 検索結果表示(V)→更新(C)：Form①
どのような形が正しいのでしょうか？
よろしくお願いします。
formはViewとController間のやり取りで使用、DTOはControllerとServiceで使用するものと考えています。が、現場のソースを見ていると、検索結果をFormで返していたり、DTOで返していたり、バラバラでしたので、あるべき姿としてはどちらなのかと思った次第です。
前質問に関しては、順々に調べているところです。デザインパターンに関しては、パターンが多いため後回しにしています。
画面から入力を受け取ってFormにつめる
↓
必要な情報をDTOに格納してDB処理をする
↓
DAOなどでDB接続して処理完了、DTOに値をつめる
↓
DTOからFORMに値をつめる
↓
画面にどーん（雑）
現場のソースがあるなら現場が正です。
正しいからと言って現場のソースと全く違う感じでコーディングすると一貫性がなくなって逆にやりにくくなります。
どうやってるんですか？って上司にたずねてみては？
（現場の中でもバラバラな場合もよくあるからどれに合わせればいいんですかねぇっていうのも上司に尋ねてみて知らんわって言われたら正しいようにコーディングしたらよいかと）
>デザインパターンに関しては、パターンが多いため後回しにしています。
デザインパターンを後回しにしてできる質問ではありません。
それに多いということはそれだけ”基本的な”考え方があるということ。自由に組むことができる以上、完全なベストプラクティスを求めるのは土台無理な話。
「現場で採用しているやり方に合わせる」以上の答えはできません。
例えベストプラクティスがあったとして、
現場でのやり方があるにも関わらず「俺が決めたさいきょうのルールを押し通すような人」にしかならないので。
azuapricotさん、ご回答ありがとうございます。
基本は、V⇔Cのやり取りにはForm、C⇔Mのやり取りにはDTOなのですね。
ここで質問する前に上司には相談したのですが、どっちでも良いと言われたので、あるべき形で実装しようとしました。
ちなみに、FormにDTO自体をプロパティとして持つのはどうなんでしょう？
スルーされてそうですけど
大抵の現場はいずれか、または複数のデザインパターンを組み合わせたものから派生した亜種と思っていいので、デザインパターンを後回しにするということは基本を疎かにするということとイコールになります。
基本を疎かにする人は現場では使えません。
m.ts10806 さん
おっしゃることはわかります、が、一朝一夕ですべて理解できるものではないのも事実だと思っています。
ので、せめてどのパターンを参照すべきか、だけでもご教示いただけないでしょうか？
FormにDTOを持つ必要があるなら持っておいてもいいんじゃないかなーとは思います。
場合によりけり。
azuapricot さん
なるほど、間違いではないのですね。
ありがとうございます！
まぁ先程も言いましたが「現場による」ので、作ってみて上司にこんな感じで問題ないですか？と聞いて「OK」と言われればその現場では問題ないでしょう。
>せめてどのパターンを参照すべきか、だけでもご教示いただけないでしょうか？
ベストプラクティスは、ない。ですね。
私も現場で育った人間で、何百とこなしてきたわけではないから「現場現場に合うパターンがある」くらいしか言えません。「間違いはない」けど「正解はない」世界です。（要件を満たすことが第一なので）
だからそんなに急ぐのでしたら現場で使われているデザインパターンを聞いてください、としか。
書籍もたくさん出ているのでどれかには当てはまるでしょう。
（ただ本当に正しいやり方を貫き通したい！というのであれば、m.ts10806さんのおっしゃるようにデザインパターンをマスターするのがよいですね。）
m.ts10806 さん
なるほど、私の最初の認識が誤っていました。
サービスクラスでformを使用しないように、この質問には単一の絶対正解があると思っていましたが、まずその前提がおかしかったのだと気づきました。
その正解を自分で考えるための武器=デザインパターンなのですね。
デザインパターン学ぼうと思います。
ご回答ありがとうございました。
azuapricot さん
承知しました。
デザインパターンを学びます！
ご回答ありがとうございました。
(べ、ベストアンサーをお付けしたく・・・)
回答がないけど追記でかいけつした場合は自己解決（最終解決方法明記のうえ）＆参考になった人へのお礼の言葉で締めて良いと思いますよ～
承知しました！
ここはコメントのやり取りを通して自身が感じたこと学んだことを自身でまとめて書かれたほうが
自身のためにもなりますし、同じような疑問を持った人のためになると思います（下手に回答者側の視点が入らないほうがいい）
回答1件
0
自己解決
azuapricotさんの追記と、現場のソースの実装から、
「V⇔Cのやり取りにはForm、C⇔Mのやり取りにはDTO」をベースとし、
FormにDTOのプロパティを持つパターンも考慮しつつ実装します。
一旦、上記を持って解決とし、デザインパターンを学習することで、
その現場なりの正解を考えられるようにします。
azuapricotさん、m.ts10806さん、ご回答ありがとうございました。
投稿2019/08/27 06:50
総合スコア32
あなたの回答
tips
プレビュー
