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