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

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

**デフォルトの名無しさん** · 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ツールの良し悪しや使用方法についてとか

**デフォルトの名無しさん** · 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

**wikiから抜粋** · 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での詰め替え等が混在していると保守性が悪くなりそうだ

**デフォルトの名無しさん** · 2012/06/08(金) 13:55:44.00

VMでなんでも出来はするるが、責務としてVMでやるのはデータ構造の変換までにして、色だの文字だのの修飾はコンバーターでやるべきだろう。

**デフォルトの名無しさん** · 2012/06/08(金) 13:57:35.24

自分はコンバータも形式の変換で、修飾なりなんなりはViewにやらせるな

**デフォルトの名無しさん** · 2012/06/08(金) 14:47:38.34

おまえらユニットテストには何使ってるの

**デフォルトの名無しさん** · 2012/06/08(金) 14:53:47.65

>>96
Thx

考え方としてはありか。

Prismにはその辺の仕組みもあるのね。
じゃあ、各フレームワークでそういう機構を持っているものについて、該当クラス名とかを知っている人がいたら教えて下さい(*・ω・)*_ _)ﾍﾟｺﾘ

後は自分で調べるので。

**デフォルトの名無しさん** · 2012/06/08(金) 15:13:12.05

>>104
NUnit

**デフォルトの名無しさん** · 2012/06/08(金) 15:14:23.05

MVCとかMVPとかのパターンを判りやすく解説してる本あったら教えて

**デフォルトの名無しさん** · 2012/06/08(金) 15:24:26.98

>>104
俺もNUnit。

**デフォルトの名無しさん** · 2012/06/08(金) 15:27:32.55

上のご神託を読んでこい。

**デフォルトの名無しさん** · 2012/06/08(金) 15:36:30.90

>>109
いや、MVVMの前提となるMVCやMVPについて知りたいんだが
やっぱファウラー先生あたりの本になるのかな？

**デフォルトの名無しさん** · 2012/06/08(金) 15:57:52.51

偉い先生が書いたものとか読んだことないわー
MVCとかなにかのパターン本に乗ってたけどネットで探れるのと大差ない。
MSDNでMVPVMの説明してるやつでMVC,MVP説明してるのあったお

**デフォルトの名無しさん** · 2012/06/08(金) 16:02:11.72

MVCではクライアントはC(イベントハンドラ、リスナー、コールバック)に
アクセスしてVがレスポンスとして帰ってくるのに対し、
MVVMはクライアントがVにアクセスしてVが帰ってくる感じだな。

HTMLならステートレスなMVCが、Viewがクライアント内にある
ステートフルなappletとかsilverlight、デスクトップGUIならMVVMが良さそうだ。

**デフォルトの名無しさん** · 2012/06/08(金) 16:12:29.99

MVCについて知りたいならSmalltalkを調べろ。
WebのMVC(2)ならむしろRESTってキーワードで調べろ。
MVVM自体に関する本は知らん。
そしてそれとは関係無しに、PoEAAなんかも読んでおくべき。
PoEAAだけ読んで、ドメインモデルvsトランザクションスクリプト厨になったりする奴も多いけどな。

**デフォルトの名無しさん** · 2012/06/08(金) 16:18:06.91

そろそろ電子書籍で売ってくれ

**デフォルトの名無しさん** · 2012/06/08(金) 17:40:37.50

>>113
MVCってSmalltalkコミュニティから提唱されたのか

**デフォルトの名無しさん** · 2012/06/08(金) 18:47:52.68

たしか。
オブジェクト指向の元祖たるSmalktalkで発展したものだと効いた希ガス

**デフォルトの名無しさん** · 2012/06/08(金) 19:10:59.99

良スレの予感。

**デフォルトの名無しさん** · 2012/06/08(金) 20:31:39.36

やっぱりVMのライフサイクル管理やVMへのインジェクションを行うサービスロケータはあっても良いよな。
アプリケーションの構造によっては別にいらないだろうけど。

**デフォルトの名無しさん** · 2012/06/09(土) 10:42:20.11

複数ViewModel間の呼び出しってどうすべき？

**デフォルトの名無しさん** · 2012/06/09(土) 11:28:54.73

public string Name
{
　 get { return Model.Name; }
　 set { Model.Name = value; }
}

こういう感じで VM で M のプロパティを V に伝えるためだけの
プロパティってなんていうの？

**デフォルトの名無しさん** · 2012/06/09(土) 11:41:10.30

ごめん、knockout.js の話題はここで良い？

**デフォルトの名無しさん** · 2012/06/09(土) 11:45:02.52

>>120
NotifyPropertyChanged使わないなら直接Modelのプロパティにバインドしてよくね

**デフォルトの名無しさん** · 2012/06/09(土) 14:57:44.75

>>122
難読化でいちばん隠したい部分がまる見えになるからオススメできない
プロパティ多すぎて書きたくねぇ！ってならＴ４

**デフォルトの名無しさん** · 2012/06/09(土) 16:03:19.03

難読化か。難読化なら確かにラッピングは必要かもしれんが
internalなViewModelじゃだめなん？

**デフォルトの名無しさん** · 2012/06/09(土) 22:58:26.63

ラムダ式からプロパティ名を取り出す方法なら難読化できるよ

**125** · 2012/06/09(土) 23:02:50.05

ああXAMLには影響が出るから無理か
インターフェイスが曝されるだけなら別によくない?
VMでラップしまくるのも大差ないと思うが

**デフォルトの名無しさん** · 2012/06/10(日) 02:20:40.65

まあ全部ラッピングしたらしたでやっぱり中身の名前はそのまま出てくるわけだしな
それなら直接Model繋げた方がいい

**デフォルトの名無しさん** · 2012/06/10(日) 19:31:10.74

ふむ。
ttp://www.mnow.jp/LinkClick.aspx?fileticket=U%2b2U8DNLxfs%3d&tabid=220&mid=867

確かにナビゲーションなんかは、MessengerやBehaivorで解決できはするんだけど、
VVMの責務としてどうなのかとか、MVVMというよりもBlend至上主義になりすぎているのではと思うことはあって。

何かしら別の層があっても良いと感じてはいたが。
それをPと呼ぶかどうかはともかく。

**デフォルトの名無しさん** · 2012/06/10(日) 19:42:58.13

世の中にはコードビハインドというものがあってだな

**デフォルトの名無しさん** · 2012/06/10(日) 20:08:46.96

コードで書くかと、コードをどこに書くかは全然違う話であってだな

**デフォルトの名無しさん** · 2012/06/10(日) 20:22:58.07

ところでVS2012のデザイナはBlendベースで刷新されて前と比べ物にならないくらい良くなってるぞ
アニメーションやテンプレートやリソースの編集にはBlendがまだ必要だけど
MVVMのV作るときにはそろそろBlendいらないと思う

**デフォルトの名無しさん** · 2012/06/11(月) 07:53:21.15

>>121 のやつ
http://en.m.wikipedia.org/wiki/KnockoutJS
http://knockoutjs.com/

SilverlightとKnockoutJSの比較
http://www.codeproject.com/Articles/365120/KnockoutJS-vs-Silverlight

**デフォルトの名無しさん** · 2012/06/11(月) 09:04:31.43

コマンドもバインディングできて、シンプルなテンプレートも付いてるのはいいな。
なかなか使いやすそうな感じだね。これは確かにMVVMだ。

質問とかだったらWeb制作板のライブラリ質問スレが適当かな。

**デフォルトの名無しさん** · 2012/06/11(月) 09:12:27.73

WebはWebでもJSはクライアント側でUIを扱うからMVVMなんだな

**デフォルトの名無しさん** · 2012/06/12(火) 01:28:10.49

VS2012になるとビューモデルは Portable Library でサポートされるそうだ、VM と M は可能な限り Portable Library に押し込んでマルチプラットフォーム化を目指せるのか。

**デフォルトの名無しさん** · 2012/06/12(火) 02:06:46.27

VMが厚くなるな

**デフォルトの名無しさん** · 2012/06/12(火) 02:23:38.61

MetroとWPFでVM使い回しはきついだろ
ギャップが大きすぎるから、大量のコードビハインドでVMを相当抽象化することになるか
互換性のためにどっちつかずでプラットフォームの空気を読まない不自然なUIになりそう

**デフォルトの名無しさん** · 2012/06/12(火) 07:04:36.86

Portable Libraryは別に良いんだけど、別にVMのマルチプラットフォーム対応を目指す必要は無いと思うんだよね。
使用するビューのテクノロジーやデバイスが異なればVMに求められる構造だって変わってくるし。

WebのMVCでPCサイトとモバイルサイトで同じControllerを使う、程度には面倒で制約が多い気がする。

むしろマルチプラットフォーム化できるんならしたいのはMじゃね？

**デフォルトの名無しさん** · 2012/06/12(火) 12:49:34.16

Livet で、Winodws.Loaded 時にコマンド発行させたいんだが、どうすればいいの？
WindowAction みたいなので、コマンドを発行するだけの Action があればいいだんけど、
見つからなかった。
自分で作るしかない？

**デフォルトの名無しさん** · 2012/06/12(火) 13:12:31.77

>>139
i:EventTrigger
i:InvokeCommandAction

**デフォルトの名無しさん** · 2012/06/12(火) 16:51:30.23

Portable Library に Model を押し込む努力はするべきだ。
Portable Library に押し込むには ViewModel は View にプロパティを提供するだけにせざる負えない。
と書いてどっかで聞いたなと思ったら。 MVPVMパターンあった。

Portable Library に ViewModel と Model を押し込んで View と Presennter をプラットフォーム依存にするのか。

**デフォルトの名無しさん** · 2012/06/12(火) 17:21:46.72

で、そのPresenterってコードビハインドじゃん、ってなった

**デフォルトの名無しさん** · 2012/06/12(火) 18:36:18.33

状況によってはPresenter設けてもいいと思う
Viewのサイズや表示位置、グリッドのソート順や列の表示・非表示等を構成ファイルに保存/読み込みさせるのに独立したPresenter設けても可

**デフォルトの名無しさん** · 2012/06/12(火) 20:43:19.56

Presenterの役割定義が昔に比べて広いものを指すようになってきている気がするのは俺だけ？

IHogeViewを実装しているビューなら、それがWPFだろうがWindows FormsだろうがConsoleアプリだろうが、
HogePresenterから操作できる、みたいなのがMVPのイメージだったんだけど、
コードを書く = Presenterな使われ方が増えている気がするんだけど、MVPってそういうものだったの？

ビュー間にまたがるものやアプリケーション横断的な処理の記述箇所については、
Presenterといわずに別の定義をした方が良いんじゃねと思ったんだけど。

**139** · 2012/06/12(火) 22:17:28.41

>>140
ありがとう。
Livet 関係なくできたのか、
ぐぐっても出ないわけだ・・・。

**デフォルトの名無しさん** · 2012/06/13(水) 02:37:56.25

>>142
V->VMが密結合にならないのがコードビハインドとは違うところ
実際やるかどうかは別にしてVMの差し替えが可能

**デフォルトの名無しさん** · 2012/06/13(水) 10:57:45.00

NVPVMはあくまでMVVMの派生パターン
特殊なコンポーネント使っててViewの負荷が異常に高い場合、有効なパターンだよ

**デフォルトの名無しさん** · 2012/06/13(水) 12:44:02.37

じゃぁViewにプロパティを提供する入力検証の一部をする以外の、
VMでやっていることを考えてみよう。

非常にめんどくさいコーディングスタイルのコントローラじゃないのか？

**デフォルトの名無しさん** · 2012/06/13(水) 13:12:22.81

それでいいんだろ
一つのViewを異なる使い方で使いまわすときに
VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う

**デフォルトの名無しさん** · 2012/06/13(水) 13:19:04.84

>>149
> 一つのViewを異なる使い方で使いまわすときに
> VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う

え？

一つのViewModelを異なるアーキテクチャで使いまわすときに
Viewごと入れ替えるのは無駄が多いから

の間違いじゃね？

**デフォルトの名無しさん** · 2012/06/13(水) 13:21:02.28

MVPVMのサンプルも、VM－Mのコンビは汎用性持たせ、Pで差分吸収するサンプルに思えたが

**デフォルトの名無しさん** · 2012/06/13(水) 13:26:43.72

両方だろ
VがVM、VMとビジネスロジックがそれぞれ密結合しないことでVとVMの再利用性を高めるのがねらい

**デフォルトの名無しさん** · 2012/06/13(水) 13:30:43.53

こういう意見もありますが
ttps://gist.github.com/2041069

**デフォルトの名無しさん** · 2012/06/13(水) 13:37:22.90

2chの煽りと変わらんだろw
ugayaはこういう説明の仕方を見習うべき
www.global-webnet.net/blogengine/post/2010/02/05/MVPVM-Model-View-Presenter-View-Model-the-natural-evolution.aspx

**デフォルトの名無しさん** · 2012/06/13(水) 13:40:07.82

VがVMに密結合してしまってるのが問題だといってたぞ。
U氏も遷移を切り離すならしっくりくると書いてある。

VMから遷移を切り離したら何が残るの？
Viewにプロパティを提供する入力検証の一部をする位じゃないの？

**デフォルトの名無しさん** · 2012/06/13(水) 13:46:36.47

>>155
VがVMに密結合するのはコードビハインドな
それをPに切り出してPを差し替え可能にしてるから密結合しない

**デフォルトの名無しさん** · 2012/06/13(水) 13:47:19.86

Viewで相互運用使うならMVPVM有りとの話もあるが、実際作業するとコードビハインドしか逃げようがないんだよなぁ～

**デフォルトの名無しさん** · 2012/06/13(水) 13:49:10.29

コードビハインドってPじゃねえの？

**デフォルトの名無しさん** · 2012/06/13(水) 15:20:15.29

質問。
VMの第一の目的って、Mの構造をVでバインディングしやすい形に変換した形で持つ事っていうのであってる？

例えば、DBの2次元表の構造を、複雑なViewにバインディングするためLINQで変換する、とか。
なので、Mの構造そのままを表示するようなVだと、VMは単純なラッパに見えてしまう。

**デフォルトの名無しさん** · 2012/06/13(水) 15:27:06.16

Mの構造そのまま表示できる場合においてはVMは不要

**デフォルトの名無しさん** · 2012/06/13(水) 15:45:57.26

実際に作ってみりゃわかるけど
純粋にＭのプロパティだけでインターフェースは作れない
タブやエキスパンダの状態とか環境設定とかの話ね

めんどくせぇから全部詰め込むってのもありだけど
無駄に一緒にするのは保守性を悪くする

どうせそこらへんはほとんどラッパなんだから
書くのがめんどくさい部分は全部Ｔ４使えとＴ４

**デフォルトの名無しさん** · 2012/06/13(水) 15:51:40.10

T4使いづらいって印象しかないんだが、なんか間違ってる？

**デフォルトの名無しさん** · 2012/06/13(水) 15:57:40.49

外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ
複数ファイルの処理が面倒なのはわかるが

**デフォルトの名無しさん** · 2012/06/13(水) 16:36:31.97

>>162
俺も同じ印象だ。

結局MsBuildタスクで、
http://d.hatena.ne.jp/okazuki/20110116/1295166605
の様な属性からコードを生成するようにしたよ。

**デフォルトの名無しさん** · 2012/06/13(水) 17:01:14.95

どうもこうも

ViewModelBase<T>から派生してたら
partialでTのプロパティを全部ラップしてやればいいのさ
簡単だろ？

Ｔ４で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら
調べろとしかいいようがないが

**デフォルトの名無しさん** · 2012/06/13(水) 17:10:39.16

リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね

**デフォルトの名無しさん** · 2012/06/13(水) 17:23:42.40

> Ｔ４で自分のプロジェクトからリフレクション
このあたりは、みんなどの方法を採用してる気か聞いてみたいね。

俺はWPFのコンパイルプロセスを見習って、
自分自身を一度ビルドしてからCecilでアセンブリにアクセスしてる。

他にも
Cecilではなく普通のリフレクションAPIを使ったり、
ビルドせずにRoslynやNRefactoryを使ったりという方法もあるけど
こっちを使ってる人もいるのかな？

**デフォルトの名無しさん** · 2012/06/13(水) 17:36:11.05

>>166
アセンブリがアンロードできない・・・と来れば、あとはわかるな？

そう、AppDomainの出番だ。

**デフォルトの名無しさん** · 2012/06/13(水) 17:39:54.72

>>168
おい、やめろ
AppDomain芸をよりにもよってT4でとか地獄過ぎる

RoslynはまだCTPだしT4上で現実的なところで言えばCecilだろうな
コード生成じゃなくてポストプロセスでのIL書き換えでよければPostSharpなんかも選択肢に入るが

**デフォルトの名無しさん** · 2012/06/13(水) 18:07:49.37

うん、AppDomainは無い

まだ別プロセスを起動した方がマシ

**デフォルトの名無しさん** · 2012/06/13(水) 20:42:48.42

PostSharpとか使ってやるのがお手軽？
自前でTaskを作ってビルドプロセスに追加する方が良い？

**デフォルトの名無しさん** · 2012/06/13(水) 21:09:57.27

一番手軽なのは某氏のDSL

**デフォルトの名無しさん** · 2012/06/13(水) 21:11:07.57

Castle.DynamicProxyでいいわ
コード生成だるい

**デフォルトの名無しさん** · 2012/06/13(水) 23:33:29.53

>>172
えむなうさんの？あれってC#専用だよね？

**デフォルトの名無しさん** · 2012/06/13(水) 23:47:53.09

T4使ったら、少なくともテンプレートのコードが
コンパイルされた結果のアセンブリはロードされるはずだろ
だからもともと別AppDomainで実行されるようになってるから
普通にロードして問題ないんじゃないの?

**デフォルトの名無しさん** · 2012/06/13(水) 23:50:14.79

>>174
VB.NETやF#とか茨の道だし、C#で普通に使えれば問題ないだろ？

**デフォルトの名無しさん** · 2012/06/13(水) 23:51:37.83

必要ならVB作れってCodePlexかBlogでリクエストすればいい。
まさかJavaScriptやF#じゃないよな。

**デフォルトの名無しさん** · 2012/06/14(木) 00:07:25.99

リフレクションでやるんならわかるけど、いちいちDSLでプロパティ定義するんだったら
public virtual int Hoge { get; set; }
としといてCastleのDynamicProxyで変更通知を自動実装させればいいと思うよ

**デフォルトの名無しさん** · 2012/06/14(木) 00:14:39.91

>>176
VB.NETは茨の道でもなんでもないんだが？

**デフォルトの名無しさん** · 2012/06/14(木) 00:16:41.28

>>178
プロパティ追加・Hoge・int の3ステップでできる。
赤シャツの嫌いなAOPで実装することもあるまい。

**デフォルトの名無しさん** · 2012/06/14(木) 01:42:25.17

VB続けたい奴がXAMLに手を付けるのが不思議だわ

**デフォルトの名無しさん** · 2012/06/14(木) 08:06:59.93

>>181
それは偏見。いまのVBはC#と比べて大差ない程機能強化されとる

**デフォルトの名無しさん** · 2012/06/14(木) 09:14:33.85

>>176
むしろすべてF#で作りたいんだが。
VMまではF#でやってる。

**デフォルトの名無しさん** · 2012/06/14(木) 13:20:58.33

MS自身はVBにも力を入れてるけど、周りが付いてきていない。

サンプルがC#でのみ提供ってのもよく見るし、
MonoはVBコンパイラを非サポートにしつつあるし。

**デフォルトの名無しさん** · 2012/06/14(木) 13:24:58.84

F#は面白そうだね。

計算式で上手くリアクティブプログラミングができたら
相当VMが作りやすくなりそうな予感がする。

けど、茨の道には違いないだろう。
IDEの支援は弱いし、ライブラリの中にはC#の文法で使うことが前提のようなものもあるし。

**デフォルトの名無しさん** · 2012/06/14(木) 20:01:18.03

VBにいくら機能を追加しても言語仕様が腐ってるから駄目だよ
それにどうせ新機能が増えるたびに「冗長な予約語導入→C#より利便性が下がる」って悪循環でしょ

**デフォルトの名無しさん** · 2012/06/15(金) 01:35:08.89

VBのラムダ式とか狂った文法だし、機能面だけはC#と対等にしてるけど、もはやボロボロでしょ

**デフォルトの名無しさん** · 2012/06/15(金) 10:44:01.68

言語がどうの以前に、MVVM的インフラとして
他人のコードが重要になるから少数派は厳しい

**デフォルトの名無しさん** · 2012/06/15(金) 11:55:14.41

>>186
予約語増えるたびIDEが支援強化するからあまり不便に感じないのも事実
XAML開発の場合、IDEがどれだけその言語をサポートしているかが最重要
そういう意味でF#は終わってるとしかいいようがない

**デフォルトの名無しさん** · 2012/06/15(金) 13:19:16.42

VBはVB2005のように、厨言語と呼ばれてもいいから
VBらしさを重視していた頃のほうが健全だった
C#のクローンに成り下がったVBに存在意義はもう無い

**デフォルトの名無しさん** · 2012/06/15(金) 13:53:34.63

>C#のクローンに成り下がったVBに存在意義はもう無い

そんなことばかり言うからC#厨は嫌われるんだよ
おまえが存在意義感じなくても俺には必要なの！引っこんでろタコ！

**デフォルトの名無しさん** · 2012/06/15(金) 13:55:47.35

VBはクラシックVBとの互換性を維持したいのかしたくないのかよくわからないはじまり方をしたのが最大の失敗だったな
せっかくのしがらみを捨てる最大のチャンスを逃してしまった

**デフォルトの名無しさん** · 2012/06/15(金) 13:56:55.90

>>191
でもまぁ今から.Net始める場合はVB.NetじゃなくてC#選ぶんちゃう？

**デフォルトの名無しさん** · 2012/06/15(金) 13:59:50.60

>>192
言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい
とはいえVB６との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない

**デフォルトの名無しさん** · 2012/06/15(金) 14:00:50.13

>>193
VB.NETに移行する案件、山ほどあるんだが

**デフォルトの名無しさん** · 2012/06/15(金) 14:37:26.30

VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな

**デフォルトの名無しさん** · 2012/06/15(金) 14:51:15.90

>>196
でしょｗ　でも変にForms覚えてる奴より

「こ　れ　が　.NET　じ　ゃ　定　番　だ　か　ら」

と言えば、素直に話を聞いてくれるのから嬉しい

**デフォルトの名無しさん** · 2012/06/15(金) 14:59:21.72

Forms直に行ってデフォルトインスタンス触られるよりいいのか

**デフォルトの名無しさん** · 2012/06/15(金) 15:15:25.52

>>194
開発に使う分には問題ないが、言語チームがかなり苦労してそうなのが構文とかからにじみ出てくるぜ・・・

**デフォルトの名無しさん** · 2012/06/16(土) 04:16:43.61

VB（.NETじゃない方）も未だに元気だからなぁ
PHPがじわじわ下がってきてVBと逆転してしまった。
今はまだ一時的な物だけど今後数ヵ月かけて順位が入れ替わりそうだとか何とか。
http://www.tiobe.com/index.php/content/paperinfo/tpci/