Livetの@ugaya40さんにMVVMの責務分割きいてみた

FUJIWARA, Yusuke @yfakariya

@ugaya40 いや、そこは何となくわかります。

尾上 雅則 @ugaya40

@yfakariya VMの存在理由は仮想化なりコントロールの実装の自由化という別の理由があって存在するものだととらえていますから。プレゼン層がMに感知しないところで勝手にVとVMに分かれているだけだと認識しています。そしたらステートを持たないVにバインドしても意味ないです。

尾上 雅則 @ugaya40

@yfakariya どっちにしろMはプレゼン層と対話しているだけです。プレゼンステートを持つのがVMだからVMがMとの窓口になっているだけだと思っています。

FUJIWARA, Yusuke @yfakariya

@ugaya40 「ステートを持たないVにバインド」とはどういう意味です？

尾上 雅則 @ugaya40

@yfakariya プレゼン層で、ステートを管理しているのはVMですし。本来Vに存在するステートはMVVMでは関知していないはず、つまりないと考えています。

尾上 雅則 @ugaya40

@yfakariya なぜ同じ意味のステートを２重に持つのか？。プレゼンステートとドメインステートは違うものだし、違うものじゃないとプレゼンとドメイン分けられないからです。もちろんVMのステートとMのステートは同じではなく、多くの場合多いですが。

尾上 雅則 @ugaya40

@yfakariya 多くの場合VMの方がステートが多い(表示専用ステート・入力しがかり状態など)　のまちがいです

FUJIWARA, Yusuke @yfakariya

@ugaya40 入力の仕掛状態をViewに置く理由はなんですか？ 表示用のステートの保持や合成はわかりやすいと思いますが、仕掛状態は見た目でしょうか、リッチインタラクティブなAPの問題領域とはいえないのでしょうか？

尾上 雅則 @ugaya40

@yfakariya 言えるとは思いますが、それを言うならさきほどViewの出来と先輩がおっしゃったようにすべてリックインタラクティブなAPの問題領域ですよね。MVVMの責務は結局VのコントロールやXAMLの性能がもたらした責務わけだと思っています。

尾上 雅則 @ugaya40

@yfakariya サーバから見れば、リッチクライアント全部Vですし。Mから見ても本来Vだけでいいはずですし。しかしそうはいかないのでこの形で分担しているという認識です。しがかりを現実にMで持つと、入力状態に合わせてVとVMに通知を飛ばす必要が生まれてあれです。

尾上 雅則 @ugaya40

@yfakariya XAMLとその状態で構成されるVとVMでリッチクライアントの問題領域を吸収できる範囲があって、それ以外のところがMである。って感じです。

尾上 雅則 @ugaya40

@yfakariya コントロールの状態と分離されたMには、開発上大変なメリットがあると感じています。リッチなMはその分純粋な設計能力の差がでやすいですが。

FUJIWARA, Yusuke @yfakariya

@ugaya40 んーとすると、「コントロールの内部状態と入力仕掛は密結合することが多いので、VMに置くのが有用」って言い方ができます？ それなら（個人的な感覚としては）分かりやすいです。

尾上 雅則 @ugaya40

@yfakariya 先輩がさきほどおっしゃってたViewModel貧血症っておっしゃる通りで、だからこそ定期的にVMの自動生成なんて話が出るはずです。しかしそれがいいｗ

尾上 雅則 @ugaya40

@yfakariya 入力しがかり状態に対する反応をVがVMを見て表示する機構がすでにあるので、それをいかそうとするとおっしゃるとおりに。

FUJIWARA, Yusuke @yfakariya

@ugaya40 なるほど。