- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
303 ：デフォルトの名無しさん[sage]：2014/12/15(月) 20:04:14.79 ID:1MwIPKbX - >>302
Modelの変更の影響がViewの実装に影響してるし、逆も然りでしょ
FormsでいうViewとModel間の結合の役割は、MVVMではViewModelとModelの結合だと思ったほうがいいよ
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
307 ：デフォルトの名無しさん[sage]：2014/12/15(月) 20:26:05.87 ID:1MwIPKbX - >>304
ViewModelがModelを抽象化する層じゃないのは、当然そうでしょ。
ViewModelはViewを抽象化するための層であって、Model…ロジックには基本的に影響しない。
MVVMで言うViewとModelの分離っていうのは
FrameworkElementクラスを継承したControl群とロジックが直接結びつかないという意味でしかない。
ViewModelとModelの間の層という表現はおかしくて、ViewとViewModelで画面を表現し、
それ以外の全てのロジックはModel層に属するんだから、そこに新しい層なんて必要ない
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
309 ：デフォルトの名無しさん[sage]：2014/12/15(月) 20:42:50.30 ID:1MwIPKbX - >>308
Viewの呼び出し単位が代わったらModelが公開してるI/Fの粒度が変わりうるというような意味で書いたが、
それ単純に設計がクソなだけだな。MVVM関係ないわ。
Modelに影響を与えうる系の所は忘れてくれ
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
311 ：デフォルトの名無しさん[sage]：2014/12/15(月) 20:56:54.78 ID:1MwIPKbX - >>310
>それだと「分離」による「Model変更時のViewへの影響」の排除はほとんどできていないと思う
>もし改善があるなら、元のコードが汚いだけ
Viewへの影響は排除できるでしょ。ModelがViewを一切関知しないんだから。
実際のControlクラス群と関係ない「抽象化された外見」であるViewModelとModelが結合し、
ViewModelとViewがBindingを介して緩くつながる事で、
具体的な外見である「View」とロジック部分である「Model」が分離されるでしょ
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
313 ：デフォルトの名無しさん[sage]：2014/12/15(月) 21:11:16.68 ID:1MwIPKbX - >>312
Modelの意味ってViewとViewModel以外 以上の意味は存在しない
って所まではそろそろ一般的に知られてるんじゃないの？
VM以下の話はしてるつもりないんだが
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
316 ：デフォルトの名無しさん[sage]：2014/12/15(月) 21:29:59.44 ID:1MwIPKbX - >>314
>Viewの変更量(VM無しの場合)≒Viewの変更量＋ViewModelの変更量(VMありの場合)
>になるので、メリットとは言えない、と言いたかった
これだけど、「変更量が減る」という主張はそもそもしてないつもりだったので、全面的に同意。
減るのは具体的なViewとの結合度だけであって、実装コード量はむしろ増える傾向にある。
>Modelが変更されると必要な表示項目が増えたりするので、排除できてるってほどでもないと思う
表示項目が増えたりするのは、MVVMが云々じゃなくて、そも要件とか仕様が変わった場合でしょ？
それはViewがModelが云々って話じゃなくて、当然の現象なだけじゃない？
>FrameworkElementの継承階層自体が既に「抽象化された外見」なんだよ
この表現は違和感あるな。
FrameworkElement、ControlTemplate（というかTemplate）まで含んだ意味で使わないか？
VisualTreeにぶら下がってるのって、FrameworkElement（正確にはDependencyObjectだけど）群なんだし。
ViewModelを挟むことの利点は、テスト可能になる点、具体的なデザインとアプリケーションのロジックが分離できる点。
あとは、利点以前にWPFがMVVM(というかBinding)前提のアーキテクチャだから、
是非もないってだけだと思うけど。
基本的に、MVVMってBinding機構を持つアーキテクチャ上のMVC変形でしかないし。
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
318 ：デフォルトの名無しさん[sage]：2014/12/15(月) 21:42:57.64 ID:1MwIPKbX - >>317
どっちの場合でもVMがあろうが無かろうがMに変化は無い気はするが、
>・ViewModelを使用しない場合と変わらない部分(4のみ)
って本当に画面とかの都合が全く関係ない部分の事をModelと呼ぶヤツだよね？
いわゆる後者の「Model」って、用語的にはWeb系のサーバーサイドとかの用語である「Model」であって、
MVVMが表現している所の「Model」じゃないって認識だな。
基本的にリッチクライアントにおけるパターンなんだから、メモリ上の状態を持つ奴は誰か居るはずだし。
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
321 ：デフォルトの名無しさん[sage]：2014/12/15(月) 23:18:51.15 ID:1MwIPKbX - >>320
それで十分じゃね？ VM以上が分離できてる前提を共有できてさえいれば、具体的な話が出来る
観念的なMVVMの話題は前提として、実装方法とか設計方法の話をしたい
|