MVPVMパターンへの反応まとめ。
-
- いいね！0
かずき(Kazuki Ota) | Cloud Solution Architect at MS
@okazuki
MVPVMデザインパターンだ…と…!? http://t.co/Frn3twJg
2011-12-01 09:00:42まずは日本におけるMVVMの重鎮@ugaya40さん（国産MVVMライブラリLivetの創始者）のコメント。
尾上 雅則
@ugaya40
これたぶんただのコードビハインド付MVVMだと思いますよ。それを細かく定義しなおしているだけ。Presenterをコードビハインドだと考えるとしっくりきます RT @okazuki: MVPVMデザインパターンだ…と…!? http://t.co/8VK1qOr2
2011-12-01 09:02:38それを起点にXAMLクラスタ内で議論が始まります。
白い高野さん
@masaru_b_cl
図を見る限り、従来のMVVMと何が違うん？という感じ。P、BL、DAL、DMをまとめてMとみなせるから。 QT @okazuki: MVPVMデザインパターンだ…と…!? http://t.co/CArlVmGY
2011-12-01 09:05:01
尾上 雅則
@ugaya40
PなのでVと相互にあれがあるのは問題ないです。PがBL(M)に伸びているところ(ひいてはVMがBL(M)に伸びないところ)が気になる点ですね。
2011-12-01 09:09:40
尾上 雅則
@ugaya40
Vへの変更機会が、ViewModelの状態の変化以外にPからの直接の操作を含むので、XAMLのトリガー的機能(面倒だと思われているところ)を採用せずに、考られたパターンですね。MVVMに対してのメリット・デメリットは
2011-12-01 09:12:07
尾上 雅則
@ugaya40
メリットとしてはXAMLの面倒なところ(トリガーとかメッセンジャ)とかを「すでに用意されているもの以外は」新たに作る以外のアプローチとして、「Pから直接触る」という選択肢が与えられているという点。
2011-12-01 09:14:57
尾上 雅則
@ugaya40
デメリットは、結局バインディングとPrensenterからの操作の場合分けをどうするのか悩まなければならない。VMを更新することでVを変更する？Pから直接触る？元祖MVP(Passiveじゃない方)のPは、Mからの更新から漏れることをPがすればよかったのに。
2011-12-01 09:16:47
尾上 雅則
@ugaya40
そう思います。でもコードビハインドがVMを触らないアプローチも取れて、その場合はコードビハインドはVとみなせるように見えます。MVVMならそうかと。 RT @yfakariya: コードビハインドは MVVM 関係なく Presenter に落ち着くんじゃないかなぁ
2011-12-01 09:18:09
尾上 雅則
@ugaya40
簡単にMVVMのメリットを得てコードビハインドを併用する場合は、コードビハインドが自分と子以外触らない(VM/Mを触らない)ことで出来て、その場合コードビハインドとXAML含めてVとみなせると思います。
2011-12-01 09:20:12
尾上 雅則
@ugaya40
結局PとVMの両方がVへの変更機会になるところがMVVMと比べたこのMVPVMとやらの本質だと思いますよ。それがメリットもデメリットも決定してるし、またこの矢印じゃない成立できなくしてる。
2011-12-01 09:59:27結局のところ国内XAMLクラスタからはあまり好意的には受け取られず、な反応。
チト
@karno
コードビハインドはカスタムコントロール用と割り切ると楽チン。どうしてもウィンドウ内でバインドやテンプレートで解決できないとか、綺麗に書けないといった時はそこを切り出してカスタムコントロール化するヨロシ。そんな発想。
2011-12-01 09:40:42