MVVMについて語ろう

[1 デフォルトの名無しさん 2012/06/06(水) 11:03:33.21]

WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！

[2 デフォルトの名無しさん 2012/06/06(水) 11:09:54.07]

関連記事

Model View ViewModel
http://ja.wikipedia.org/wiki/Model_View_ViewModel

Model-View-ViewModel デザイン パターンによる WPF アプリケーション
http://msdn.microsoft.com/ja-jp/magazine/dd419663.aspx

MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？
http://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_02/greatblogentry_02_01.html

MVVMパターンとイベント駆動開発、そしてMVC/MVP/PMパターンとの関係 ? 何故MVVMなのか
http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html

「MVVMパターンが必要な理由」啓蒙用資料公開
http://ugaya40.net/mvvm/mvvm_document.html

[3 デフォルトの名無しさん 2012/06/06(水) 12:06:49.93]

語れるほどニーズあんのか？

[4 デフォルトの名無しさん 2012/06/06(水) 12:30:27.30]

MVCよりはまし。
でも、MVCすら理解できないのが大半だからなー

[5 デフォルトの名無しさん 2012/06/06(水) 12:40:59.59]

MVPとMVC混同してる人けっこういるよね

[6 デフォルトの名無しさん 2012/06/06(水) 12:50:21.81]

UIパターン知らんでMVVM知ろうとしても無理ゲー

[7 デフォルトの名無しさん 2012/06/06(水) 13:04:32.71]

>>5
実装上の違いだけで本質的には同じもの
そこにこだわるってことは、たぶん本質が分かってないんだろうな

[8 デフォルトの名無しさん 2012/06/06(水) 14:22:00.43]

語ることあるのか知らんが期待しとく

[9 デフォルトの名無しさん 2012/06/06(水) 14:34:22.26]

要するにXAMLで開発してれば自動的にMVVMなんでしょ？

開発環境を作ってるのでも無ければ、あんまり純粋主義主義者になる意味は無いと思う。

[10 デフォルトの名無しさん 2012/06/06(水) 14:36:36.66]

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

[11 デフォルトの名無しさん 2012/06/06(水) 15:10:32.26]

MVVMツールがVSに標準装備されてないことか推測するに、MVVMがXAMLUIに必須でないことが判る

[12 デフォルトの名無しさん 2012/06/06(水) 15:41:03.54]

>>9　自動的にMVVMではない。
>>11　必須ではないが有用。

[13 デフォルトの名無しさん 2012/06/06(水) 16:24:21.12]

デザインパターンと同じで、フレームワークの名称じゃないからね
自分でフルスクラッチしてもいいんじゃよ？　別にむずかしくないし

でも「mstest？　なにそれおいしいの？」って子は
本来のメリットの半分もえられないからこれまで通りにかけばいいんじゃないの

[14 デフォルトの名無しさん 2012/06/06(水) 19:44:35.03]

MVVMで実際のDBに繋いでCRUDのサンプルってないね。
DBのあたりはEntity Frameworkでいいの？

[15 デフォルトの名無しさん 2012/06/06(水) 19:53:11.38]

つか語呂悪い。なんで最後だけ二文字なんだよ。

[16 デフォルトの名無しさん 2012/06/06(水) 19:56:31.71]

>14
プレゼンテーション層以外はすべてModelなのでどうでもいい話

>15
回文

[17 デフォルトの名無しさん 2012/06/06(水) 19:59:28.53]

>>15
じゃあ何て略したらいいんだよｗ

[18 デフォルトの名無しさん 2012/06/06(水) 20:01:18.77]

Mのぶぶんは別になんでもいいお。
そもそもMの部分はVMとのセパレーションさえできていればいわゆるModel的なものですらなくていいと思う。
なんというかViewに関連しないものでありさえするなら、ステートを持つ実体的なものでもサービスとのやり取りをするProxi的なものでもなんでも。
実際のアプリではVMとMが一体化してるようなものもあると思われ。

[19 デフォルトの名無しさん 2012/06/06(水) 20:13:26.93]

アプリケーションや実装固有の話だからといって、MVVMにおけるMやMVCにおけるMのパターンを語る気が無いなら
「V-VM-VとVM以外パターン」とか「V-C-VとC以外パターン」とか言っておくべきだな。

[20 デフォルトの名無しさん 2012/06/06(水) 20:42:38.20]

Mはドメインロジックなのでモデルといって問題ない

[21 デフォルトの名無しさん 2012/06/06(水) 20:47:41.09]

つうか、むしろ話としては、VVMな部分の話よりも、MVVMにおけるMの話の方が語ることは多いと思うが。
VMとして責務を分離する話に、スレを立てるほどの広がりがあるのかなあ？

[22 デフォルトの名無しさん 2012/06/06(水) 20:48:35.99]

ドメインロジックという言葉が何に対してでも都合良く使われる問題。

[23 デフォルトの名無しさん 2012/06/06(水) 20:48:37.04]

実装の話とか？

[24 デフォルトの名無しさん 2012/06/06(水) 20:51:59.61]

>>22
それはすげー思うｗ

[25 デフォルトの名無しさん 2012/06/06(水) 20:54:32.74]

Mについてはそれなりに構築できるけど、
そこにVを被せるときに毎回苦労するんだなー

[26 デフォルトの名無しさん 2012/06/06(水) 20:58:39.14]

対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。

MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、
ひいては状態を持っているるからドメインモデルです(｀・ω・´)ｷﾘｯ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。

[27 デフォルトの名無しさん 2012/06/06(水) 22:10:29.54]

いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな

[28 デフォルトの名無しさん 2012/06/06(水) 23:41:43.34]

だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある？、っていう。

まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。
DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、
サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。

[29 デフォルトの名無しさん 2012/06/07(木) 00:03:55.68]

それはアプリケーション（Model）の役目だろうよ
V＆VMはむしろ生成される側だと思われ

[30 デフォルトの名無しさん 2012/06/07(木) 00:13:47.89]

簡単に言えば
V　見た目
M　本処理
VM　接着剤
だろ
MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで
UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな
Modelって名前なんだから何々であるべきなんだ！！１なんて話はナンセンス

[31 デフォルトの名無しさん 2012/06/07(木) 00:14:54.65]

その「アプリケーション（Model）」っていう言い方も微妙だが…。
生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。
でも、その話すらしないのだとしたら、本当に何の話をするんだ？

[32 デフォルトの名無しさん 2012/06/07(木) 00:15:55.19]

ザックリ分けると
・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
・MVVMとしての各画面の作り方の部分
・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分
って感じかね。

[33 デフォルトの名無しさん 2012/06/07(木) 00:16:50.09]

>>30で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの？

[34 デフォルトの名無しさん 2012/06/07(木) 00:23:50.25]

>>33
>>30の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの？

[35 デフォルトの名無しさん 2012/06/07(木) 00:36:57.38]

MVVMの実装に関する話ならいくらでもできるんじゃね

[36 デフォルトの名無しさん 2012/06/07(木) 01:12:27.18]

むしろそちらの方を知りたいという人間多いんじゃね？
MVVM的に考えるとコマンドはVMに置くべきか否か
コードビハインドとイベントハンドラとVMの関係
コードビハインドはいわゆるプレゼンターか否か
バインディングとMVVMは切り離して考えるべきか否か
MVVMとしてふさわしいVMの実装は
もっと高速にVMを実装する方法はないかとかね

[37 デフォルトの名無しさん 2012/06/07(木) 01:13:45.85]

あとMVVMツールの良し悪しや使用方法についてとか

[38 デフォルトの名無しさん 2012/06/07(木) 01:19:01.75]

ビヘイビアってよく聞くけどVMに入るの？

[39 デフォルトの名無しさん 2012/06/07(木) 06:11:20.38]

>>32みたいな、アプリケーション構造の話をするのはこのスレではあり？、なし？
MVVMフレームワークの実装比較の話は俺も聞きたいな。

[40 デフォルトの名無しさん 2012/06/07(木) 06:16:05.12]

定義論にまた脱線しない限りまあいいんじゃね

[41 デフォルトの名無しさん 2012/06/07(木) 08:14:29.03]

>>39
むしろそのためのスレだろ

[42 デフォルトの名無しさん 2012/06/07(木) 09:30:27.00]

Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。
その境界がどこかの確認。

[43 デフォルトの名無しさん 2012/06/07(木) 09:57:41.92]

>>42
新参者だが、荒れるん？
むしろMVVM作る上で重要なファクターだと思うんだが。

[44 デフォルトの名無しさん 2012/06/07(木) 10:11:41.27]

Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです！、な発言が出てくるから。
その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。

[45 デフォルトの名無しさん 2012/06/07(木) 10:16:56.33]

何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか
MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ

[46 デフォルトの名無しさん 2012/06/07(木) 10:28:50.09]

本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。
そこでV〜M間に仲介者を設け、V(XAML)、VM（C#）の二層構造とし、VMにViewの状態とModelのデータを保持させて
V〜VM間をバインディングで通信するのがMVVM。

[47 デフォルトの名無しさん 2012/06/07(木) 10:30:41.00]

ほらｗ

>>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途
WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。

[48 デフォルトの名無しさん 2012/06/07(木) 10:35:21.73]

>>45
それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには１も３も必要だろ。

[49 デフォルトの名無しさん 2012/06/07(木) 10:58:40.42]

＞DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。

ってMVVMとどう関係あるの？
洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがｗ

[50 デフォルトの名無しさん 2012/06/07(木) 11:00:01.66]

>>48
VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ

[51 デフォルトの名無しさん 2012/06/07(木) 11:04:12.67]

>>49,50
M内の構造はMVVMとは関係ないよ。
でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ？
MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。

[52 デフォルトの名無しさん 2012/06/07(木) 11:07:44.33]

>>51
ああ、ごめん。IDが出ないから流れがわかりにくいなこのスレ
>>49は>>47への反論です
>>50も俺だけど>>51と全く同意

[53 デフォルトの名無しさん 2012/06/07(木) 11:16:28.31]

>>46
そもそもVMはV層でしっかりVとMの分離になってるんじゃないか
Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし

[54 デフォルトの名無しさん 2012/06/07(木) 11:18:42.66]

やっぱり、VVM内に閉じた話だけを扱うスレなのか？、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか？、っていう最初に戻るじゃん。
VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。

[55 デフォルトの名無しさん 2012/06/07(木) 11:26:13.73]

定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる
定義知りたきゃMVVMでぐぐってろ

[56 デフォルトの名無しさん 2012/06/07(木) 11:27:07.00]

そもそもMVVMってなに？

[57 デフォルトの名無しさん 2012/06/07(木) 11:27:49.63]

>>56
>>2

[58 wikiから抜粋 2012/06/07(木) 11:33:08.35]

Model
アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、
サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。
MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる
一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。
たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。
アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。
Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。

[59 デフォルトの名無しさん 2012/06/07(木) 11:34:10.24]

MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。
それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね？

[60 デフォルトの名無しさん 2012/06/07(木) 11:36:30.09]

>>58
それってU氏の記述だろ？

[61 デフォルトの名無しさん 2012/06/07(木) 11:40:56.25]

わかりにくいからMVVMをガンダムでたとえて

[62 デフォルトの名無しさん 2012/06/07(木) 11:47:53.91]

>>54
そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・｀)

[63 デフォルトの名無しさん 2012/06/07(木) 11:49:55.46]

>>61
M=ララァ
VM=サイコミュ
V=ビット