- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
183 ：デフォルトの名無しさん[sage]：2014/11/25(火) 18:17:07.96 ID:Tsd4ayeq - >>180
Vに本当にべったりな処理をVMに書いているのが間違い
Vにべったりなら、素直にVのコードヒハインドに書くべき
VのボタンClickがComboBoxのSelectionChangeに変わっても
困らないようにする為の存在としてVMを書くのが普通
参照される箇所の数は関係ない
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
186 ：デフォルトの名無しさん[sage]：2014/11/25(火) 18:41:27.80 ID:Tsd4ayeq - >>185
Vに実装べったり書いて、XAMLでちょちょっと変えればいいだけに出来るならそれでいいんじゃね
それが難しいから、外見と振る舞いの分離できるWPFが出てきたんでしょ
それが不要な複雑さと言えるなら、仕様変更とか少なそうな良い環境だなという感想しかない
>「VMはVと独立して機能(I/F)を提供するのみ」とかいう幻想に酔ってるんじゃないの？
そもそもその幻想なるものが間違ってないか？
VMはVの状態ストア兼インターフェイスに過ぎないだろ
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
190 ：デフォルトの名無しさん[sage]：2014/11/25(火) 18:55:09.18 ID:Tsd4ayeq - >>188
共通のメソッド呼ぶにしても、その実行時トリガとかマスターデータとする値とかの部分は
コントロール依存になっちゃって辛いでしょ。もうちょっと良い例があればいいとは思うけど。
>>189
画面領域ごとに作って差し替え可能にするのがCompositeAppの思想
安直にやるならUserControl単位で分ける
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
192 ：デフォルトの名無しさん[sage]：2014/11/25(火) 19:14:03.03 ID:Tsd4ayeq - >>191
あくまで一例だけど、共通部品プロジェクト1つとShellとその他の三種類がポピュラーじゃね。
V-VM-Mっていう機能単位でプロジェクトを切ってて、
Model同士はEventAggregator(Pub-Subのアレ)を経由して相互にメッセージ送りあうみたいな。
細かい部品じゃなくて、単独で存在しても意味が分かるレベルの画面ごとにプロジェクト分ける感じで。
|
- WPF(XAML, XBAP, .NET4.0)GUIプログラミング Part18
194 ：デフォルトの名無しさん[sage]：2014/11/25(火) 19:15:52.83 ID:Tsd4ayeq - >>192
>V-VM-Mっていう機能単位でプロジェクトを切ってて、
V-VM-Mのセットによる最低限の機能を実現できる単位でプロジェクトを切ってて、
の間違い
|