MVVMについて語ろう

■ このスレッドは過去ログ倉庫に格納されています
2012/06/06(水) 11:03:33.21
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
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での詰め替え等が混在していると保守性が悪くなりそうだ
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間の呼び出しってどうすべき？
120デフォルトの名無しさん
垢版 |
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
ラムダ式からプロパティ名を取り出す方法なら難読化できるよ
126125
垢版 |
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といわずに別の定義をした方が良いんじゃねと思ったんだけど。
145139
垢版 |
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
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況