MVVMについて語ろう

■ このスレッドは過去ログ倉庫に格納されています
2012/06/06(水) 11:03:33.21
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
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
2012/06/06(水) 12:06:49.93
語れるほどニーズあんのか？
2012/06/06(水) 12:30:27.30
MVCよりはまし。
でも、MVCすら理解できないのが大半だからなー
2012/06/06(水) 12:40:59.59
MVPとMVC混同してる人けっこういるよね
2012/06/06(水) 12:50:21.81
UIパターン知らんでMVVM知ろうとしても無理ゲー
2012/06/06(水) 13:04:32.71
>>5
実装上の違いだけで本質的には同じもの
そこにこだわるってことは、たぶん本質が分かってないんだろうな
2012/06/06(水) 14:22:00.43
語ることあるのか知らんが期待しとく
2012/06/06(水) 14:34:22.26
要するにXAMLで開発してれば自動的にMVVMなんでしょ？

開発環境を作ってるのでも無ければ、あんまり純粋主義主義者になる意味は無いと思う。
2012/06/06(水) 14:36:36.66
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

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

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
2012/06/06(水) 15:10:32.26
MVVMツールがVSに標準装備されてないことか推測するに、MVVMがXAMLUIに必須でないことが判る
2012/06/06(水) 15:41:03.54
>>9　自動的にMVVMではない。
>>11　必須ではないが有用。
2012/06/06(水) 16:24:21.12
デザインパターンと同じで、フレームワークの名称じゃないからね
自分でフルスクラッチしてもいいんじゃよ？　別にむずかしくないし

でも「mstest？　なにそれおいしいの？」って子は
本来のメリットの半分もえられないからこれまで通りにかけばいいんじゃないの
2012/06/06(水) 19:44:35.03
MVVMで実際のDBに繋いでCRUDのサンプルってないね。
DBのあたりはEntity Frameworkでいいの？
2012/06/06(水) 19:53:11.38
つか語呂悪い。なんで最後だけ二文字なんだよ。
16デフォルトの名無しさん
垢版 |
2012/06/06(水) 19:56:31.71
>14
プレゼンテーション層以外はすべてModelなのでどうでもいい話

>15
回文
2012/06/06(水) 19:59:28.53
>>15
じゃあ何て略したらいいんだよｗ
2012/06/06(水) 20:01:18.77
Mのぶぶんは別になんでもいいお。
そもそもMの部分はVMとのセパレーションさえできていればいわゆるModel的なものですらなくていいと思う。
なんというかViewに関連しないものでありさえするなら、ステートを持つ実体的なものでもサービスとのやり取りをするProxi的なものでもなんでも。
実際のアプリではVMとMが一体化してるようなものもあると思われ。
2012/06/06(水) 20:13:26.93
アプリケーションや実装固有の話だからといって、MVVMにおけるMやMVCにおけるMのパターンを語る気が無いなら
「V-VM-VとVM以外パターン」とか「V-C-VとC以外パターン」とか言っておくべきだな。
2012/06/06(水) 20:42:38.20
Mはドメインロジックなのでモデルといって問題ない
2012/06/06(水) 20:47:41.09
つうか、むしろ話としては、VVMな部分の話よりも、MVVMにおけるMの話の方が語ることは多いと思うが。
VMとして責務を分離する話に、スレを立てるほどの広がりがあるのかなあ？
2012/06/06(水) 20:48:35.99
ドメインロジックという言葉が何に対してでも都合良く使われる問題。
2012/06/06(水) 20:48:37.04
実装の話とか？
2012/06/06(水) 20:51:59.61
>>22
それはすげー思うｗ
2012/06/06(水) 20:54:32.74
Mについてはそれなりに構築できるけど、
そこにVを被せるときに毎回苦労するんだなー
2012/06/06(水) 20:58:39.14
対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。

MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、
ひいては状態を持っているるからドメインモデルです(｀・ω・´)ｷﾘｯ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。
2012/06/06(水) 22:10:29.54
いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな
2012/06/06(水) 23:41:43.34
だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある？、っていう。

まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。
DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、
サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。
2012/06/07(木) 00:03:55.68
それはアプリケーション（Model）の役目だろうよ
V＆VMはむしろ生成される側だと思われ
2012/06/07(木) 00:13:47.89
簡単に言えば
V　見た目
M　本処理
VM　接着剤
だろ
MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで
UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな
Modelって名前なんだから何々であるべきなんだ！！１なんて話はナンセンス
2012/06/07(木) 00:14:54.65
その「アプリケーション（Model）」っていう言い方も微妙だが…。
生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。
でも、その話すらしないのだとしたら、本当に何の話をするんだ？
2012/06/07(木) 00:15:55.19
ザックリ分けると
・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
・MVVMとしての各画面の作り方の部分
・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分
って感じかね。
2012/06/07(木) 00:16:50.09
>>30で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの？
2012/06/07(木) 00:23:50.25
>>33
>>30の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの？
2012/06/07(木) 00:36:57.38
MVVMの実装に関する話ならいくらでもできるんじゃね
2012/06/07(木) 01:12:27.18
むしろそちらの方を知りたいという人間多いんじゃね？
MVVM的に考えるとコマンドはVMに置くべきか否か
コードビハインドとイベントハンドラとVMの関係
コードビハインドはいわゆるプレゼンターか否か
バインディングとMVVMは切り離して考えるべきか否か
MVVMとしてふさわしいVMの実装は
もっと高速にVMを実装する方法はないかとかね
2012/06/07(木) 01:13:45.85
あとMVVMツールの良し悪しや使用方法についてとか
38デフォルトの名無しさん
垢版 |
2012/06/07(木) 01:19:01.75
ビヘイビアってよく聞くけどVMに入るの？
2012/06/07(木) 06:11:20.38
>>32みたいな、アプリケーション構造の話をするのはこのスレではあり？、なし？
MVVMフレームワークの実装比較の話は俺も聞きたいな。
2012/06/07(木) 06:16:05.12
定義論にまた脱線しない限りまあいいんじゃね
2012/06/07(木) 08:14:29.03
>>39
むしろそのためのスレだろ
2012/06/07(木) 09:30:27.00
Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。
その境界がどこかの確認。
2012/06/07(木) 09:57:41.92
>>42
新参者だが、荒れるん？
むしろMVVM作る上で重要なファクターだと思うんだが。
2012/06/07(木) 10:11:41.27
Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです！、な発言が出てくるから。
その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。
2012/06/07(木) 10:16:56.33
何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか
MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ
2012/06/07(木) 10:28:50.09
本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。
そこでV〜M間に仲介者を設け、V(XAML)、VM（C#）の二層構造とし、VMにViewの状態とModelのデータを保持させて
V〜VM間をバインディングで通信するのがMVVM。
2012/06/07(木) 10:30:41.00
ほらｗ

>>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途
WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。
2012/06/07(木) 10:35:21.73
>>45
それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには１も３も必要だろ。
2012/06/07(木) 10:58:40.42
＞DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。

ってMVVMとどう関係あるの？
洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがｗ
2012/06/07(木) 11:00:01.66
>>48
VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ
2012/06/07(木) 11:04:12.67
>>49,50
M内の構造はMVVMとは関係ないよ。
でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ？
MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。
2012/06/07(木) 11:07:44.33
>>51
ああ、ごめん。IDが出ないから流れがわかりにくいなこのスレ
>>49は>>47への反論です
>>50も俺だけど>>51と全く同意
2012/06/07(木) 11:16:28.31
>>46
そもそもVMはV層でしっかりVとMの分離になってるんじゃないか
Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし
2012/06/07(木) 11:18:42.66
やっぱり、VVM内に閉じた話だけを扱うスレなのか？、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか？、っていう最初に戻るじゃん。
VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。
2012/06/07(木) 11:26:13.73
定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる
定義知りたきゃMVVMでぐぐってろ
2012/06/07(木) 11:27:07.00
そもそもMVVMってなに？
2012/06/07(木) 11:27:49.63
>>56
>>2
2012/06/07(木) 11:33:08.35
Model
アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、
サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。
MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる
一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。
たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。
アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。
Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。
2012/06/07(木) 11:34:10.24
MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。
それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね？
2012/06/07(木) 11:36:30.09
>>58
それってU氏の記述だろ？
2012/06/07(木) 11:40:56.25
わかりにくいからMVVMをガンダムでたとえて
2012/06/07(木) 11:47:53.91
>>54
そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・｀)
2012/06/07(木) 11:49:55.46
>>61
M=ララァ
VM=サイコミュ
V=ビット
2012/06/07(木) 11:58:29.11
>>63
なんとなくこれ思い出した
http://d.hatena.ne.jp/hilapon/20120426/1335411488
2012/06/07(木) 12:54:35.30
スレのあり方を議論するだけで終わりそうだｗ
2012/06/07(木) 13:03:38.18
おまえが勝手に思ってるだけだろ
2012/06/07(木) 13:17:43.48
質問です。
ButtonクリックしてViewModelからWindowクローズしたいんだけど、ViewModel側にはどう書いたらいいのでしょうか？
2012/06/07(木) 13:21:47.51
ウィンドウを閉じる動作はViewで完結しているものなんじゃないでしょうか
2012/06/07(木) 13:57:19.39
ウィンドウサイズ保存したい
2012/06/07(木) 13:57:28.88
>68
そうなんですか？わかりました...(´･ω･`)
2012/06/07(木) 14:36:34.99
>>69
コードビハインドで実装すればいいよ
2012/06/07(木) 14:36:56.58
>>68
未保存のデータがあるときだけ確認メッセージを表示とか、Viewだけじゃ完結しないだろ。
2012/06/07(木) 16:02:42.75
LivetのMessengerクラス使えば、ViewModelからWindow閉じたり最大化・最小化を操作できる
http://d.hatena.ne.jp/hilapon/20111108/1320728308
2012/06/07(木) 16:10:07.46
よし分かった、俺がこれがコードビハインドだって
お手本のプログラムを作って見せてやるよ。
2012/06/07(木) 16:21:57.25
>>73
他のMVVMツールにも同様の機能はありますか？
2012/06/07(木) 17:01:49.59
>>75
その部分だけパチってくればいいじゃん。
2012/06/07(木) 19:40:33.37
ugaya40さん、MVVMの本書いてよ。
2012/06/07(木) 20:19:01.71
彼は文書よりもLivetのチュートリアルの優先度をあげるべきだろ。
2012/06/07(木) 20:39:57.25
チュートリアルないと使えないか？
サンプルなら探せばそれなりにあると思うけど
2012/06/07(木) 20:47:05.63
使える使えないという話ではなく、広くアピールしたいならそういう地味な作業の優先度の方が高いんじゃないの、という話。
2012/06/07(木) 20:47:06.97
ugaya40さんって誰？と思ってこれを読んだけど
http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html

MVPとPresentation Modelの認識がおかしいな
まぁ全体として意味は通じるけど…
2012/06/07(木) 20:52:17.02
ところで、これってMVCとどう違うの？
MVCのときとMとVも当然違うと思うんだけど。
2012/06/07(木) 20:52:18.22
u氏の言っていることは、VVMや実装の話についてはほぼ同意だしすごいとも思っているけど。

ただ、そこからMよりの話やもっと大きな構造の話になってくると、言っていることが微妙というか、
言おうとしていることはわかるけど、他の人の同意は得られないだろうな、っと思うことが多いかな。
2012/06/07(木) 21:28:22.45
Livet使ってるけど2chの名無しに返信しないで欲しい、とだけ言っておきたい
2012/06/07(木) 22:11:46.33
Livetネタは荒れるからやめろ。
本人に直接聞け。
2012/06/07(木) 22:23:47.65
>>77
そんなニッチ層向けの本書いても売れないだろ
2012/06/07(木) 22:59:32.63
MVVMってどれがええの？
Livetがオススメ？
2012/06/07(木) 23:01:51.98
mvvmlight
2012/06/08(金) 00:29:17.99
それはプログラミングにどの言語がいいのかと聞くようなもので
PrismもLivetもMVVMLightもどれも一長一短だからな
人に聞けばたぶんバラバラに返ってくるだろうから
一度使ってみて使いやすいのを判断したほうが早い
2012/06/08(金) 01:33:55.43
>>81
どの辺が認識おかしいの？
2012/06/08(金) 08:13:09.32
>>89
そういうんでは、その一長一短を聞きたいんだろ。
ぜんぶ試すってのはなかなか難しい。
2012/06/08(金) 10:23:56.69
>>86
いや、結構売れるかも知れんぞ。
2012/06/08(金) 11:41:06.72
VMへのサービス層のDIってどうやるべきものなの？
それ以前に、VMとMを繋ぐ方法として、VMにサービス層をインジェクションする、っていう考え方はあってる？
2012/06/08(金) 11:59:23.74
>>93
時と場合によるんだろうけど、そうするとMでやるべきのがぜんぶVMに来ない？
2012/06/08(金) 12:38:59.57
>>94

自分が想定したのは以下の様なサービスファサードがあったとして。

interface HogeServeiceFacade
{
IE<Foo> GetFooList();
}

HogeServeiceFacadeの実装の中では、外部サービスにアクセスしたり、ドメインモデルによる処理をしたり。
HogeServeiceFacade自体はバッチやWebでも使うものだとして。

ここがファサードになるので、それ以上Mの処理がVMに来ることは無いと思っているんだけど。

っで、このHogeServeiceFacadeとVMを接続する方法にコンテナ/サービスロケータを使う場合に
どうするのかとか？、それって考え方としてそもそもあっているの？、っていうのを聞きたかった。
2012/06/08(金) 12:44:10.40
>>95
そういうんではありなんじゃない？
そもそもMVVMは大本はViewとMの分離があって、それにさらに薄いVMいれると更にセパレーションで来て良いよねって話だから。
で、ロケータ使う場合色々あるけど既存の使うか自前で作るかじゃない。
薄いやつなら実質ただのKeyValueで出来るだろうし、それで結構まかなえると思われ。Prismとかはその辺も実装されてる。DIがより良くインテグレートされてる。他は知らん。
2012/06/08(金) 13:03:47.05
コンバータ(IValueConverterを実装したクラス)はMVVMのどの層に属するものなの？
2012/06/08(金) 13:07:30.90
>>97
View
2012/06/08(金) 13:20:41.29
コンバータ自体簡易VMみたいなもんじゃね？
2012/06/08(金) 13:32:59.19
>>97
それを分類することに何か意味があるの？
2012/06/08(金) 13:47:18.95
コンバータ、StringFormat、VMでの詰め替え等が混在していると保守性が悪くなりそうだ
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況