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

尾上 雅則 @ugaya40

MVVM LightのインターフェースがTask<T>に代わってよいとは思えないな。Messegerは責務境界で主に使うもんだし。

neuecc @neuecc

@ugaya40 んー、コールバックしてる以上、手元に値を戻してしまっていません？別にvoidだから境界超えないってわけじゃないですもの。そしてそれならawaitのほうがよほど綺麗になる。

尾上 雅則 @ugaya40

@neuecc いや値を返す返さない、続ける続けないの責任が責務境界超えるのが駄目だと思っているんです。そういうきれいとかいう価値観の前に。

尾上 雅則 @ugaya40

値を返す/返さない・処理を続ける/続けないが責務境界を超えてコントロールされる事が責務を破壊する事以外になんの役に立つのか教えてください。Task<T>とか生IO<T>とか責務境界でのインターフェースにするのまじ無いと思っていますよ。自身の責務の内側でやりなよ。

尾上 雅則 @ugaya40

Task<T>とかIO<T>はModelの中で大活躍してくれてると平和。

neuecc @neuecc

@ugaya40 まず、コールバックである以上、原理的には容易に超えられる（実際非同期処理はネストで超えていってますしね）。「書くのが手間で汚いから境界ができている」ってのはマヤカシだと思っています。

尾上 雅則 @ugaya40

@neuecc 越えられるのはどんな書き方でも当たり前で、そうではなくて、Task<T>や生IO<T>を境界間インターフェースにすることはフロー制御を境界間を超えてするのが圧倒的にしやすくなるというかそういう前提でとらえられやすいってところを問題にしてるんですよ。

尾上 雅則 @ugaya40

@neuecc で、また誤解を受けたくないんだけど、インフラ(ReactivePropertyやMessenger)の内部で使用するのはむしろ素敵なことだと思っています。Task<T>や生IO<T>から開発者がフロー制御する余地を消して使用することができるから。

neuecc @neuecc

@ugaya40 書きやすくなる以上は、それは当然回ってくるでしょうね、そこを問題にしているというのは分かります。その上で私の意見は先のとおりです。

尾上 雅則 @ugaya40

@neuecc 個人的にはDispatcher.Invokeはずっとあってほしい(&SL/WP7にもほしい)と思ってて、それがあればコールバックじゃなくても大丈夫だし、コレクションのロックとかで悩まなくても済みますからね。そしたらコールバックが書きにくいとかいう理由もなくなり。

neuecc @neuecc

@ugaya40 WinRTでは CoreDispatcher.Invoke/InvokeAsync という形になっているので、もしかするとSL/WP7にも戻ってきて乗っかる可能性はなくはないのかもですねえ。

尾上 雅則 @ugaya40

@neuecc ほう。それは欲しかった情報です、ありがとうございます！。WinRT入れる空きマシンやっぱりほしいですね、、XAML系技術の未来を見据えて開発するなら。。。

尾上 雅則 @ugaya40

@okazuki Disp.Invokeがない環境ではコールバックが必須ですし、そうなるとコールバックがフラットに書けるところがメリットとして出てくるのはわかります。ただフロー制御できる部分を少し掣肘しないと、変なところに開発者を誘導するリスクが高いと思っています。また

尾上 雅則 @ugaya40

@okazuki 現時点ではVM⇔Vのコールバックが連鎖するようなケースは、カスタムコントロールにしちゃう方が現実解でしょうと思っているわけです。コールバックを一段にするようにするってことです。

尾上 雅則 @ugaya40

@okazuki うぃ

尾上 雅則 @ugaya40

どういうケースをカスタムコントロールにして、どういうケースを生コントロールとVMの連携で行うのか、きちんと指針を示す必要はありそうだな。

尾上 雅則 @ugaya40

ユースケースだと違う単位になってしまうので、UI要素への1アクションについて何か良い言葉はないだろうか。

FUJIWARA, Yusuke @yfakariya

Futureと責務の境界の話ではなくて、そもそもの境界線の引き方の違いにもみえるな。

FUJIWARA, Yusuke @yfakariya

タイミングをすべてObserverに担当させるということを言っているのかもしれない。けど、すべてをObserverにすることで責務が分かれたけれども直感的でなくなったのがクラシックMVCの限界だったのではとか。

FUJIWARA, Yusuke @yfakariya

非同期としてモデリングするということを自然なものとしてとらえるか、高度なものとしてとらえるか。

尾上 雅則 @ugaya40

@yfakariya 非同期でのモデリング自体に違和感はなく、最近WP7 + Rx開発で非同期を前提にいろいろやっていますがすごく相性がよく、非同期が責務境界でのインターフェースに現れるのではなく、voidのメソッド呼び出しとステートの変化で現れるくらいですね。戻りはいらない。

FUJIWARA, Yusuke @yfakariya

@ugaya40 なるほど、そういう世界観はありですね。その場合、そのステーフルファサード（仮）とVMはどの切り口で分けますか？

尾上 雅則 @ugaya40

@yfakariya ユーザーに選択を求める、あるいはUIに通知をしたい場面がそのままMからイベントが来る場合です。基本的にはVMからMへは戻り値なしメソッド呼び出ししかしないで、使い捨て画面(検索結果画面)みたいなののみ、Mが戻り値を持つ場合がある感じです。もしかしたらここも

尾上 雅則 @ugaya40

@yfakariya ちなみに今GetEnumeratorの排他と名前の変更しています。

尾上 雅則 @ugaya40

@yfakariya あとremove時とClear時の処理も。