MVVMについて語ろう

■ このスレッドは過去ログ倉庫に格納されています
2012/06/06(水) 11:03:33.21
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
2013/01/30(水) 19:13:05.88
>>598
フレームワークとラーメンとが置換可能であることを証明できれば完璧だな。
イグノーベル賞がんばれよ。
2013/01/30(水) 20:13:22.03
COBOL最高だろうが
2013/01/30(水) 20:49:05.37
>>597
Vでしょ
というかそういう作り込みが必要な画面にMVVMを適用するのは不適切だと思うよ。
大してメリットがなく面倒なだけ。使うならダイアログとかで使う。
2013/01/30(水) 20:55:18.66
メニューとか(共有の)ツールバーとかウィンドウ制御のようなシェル的な部分に
MVVMを適用しようと考えてはいけない
そういうのはインフラとしてMVVMの枠外で実装して、その中で扱うドキュメントには
必要に応じてMVVM適用するのがスマート
2013/01/30(水) 22:12:56.62
あくまでVの都合だしな
MVVMは本体処理とUIの組み合わせ方のパターンでしかないので、ウィンドウのサイズ保存とかはロジックとは無関係
2013/01/30(水) 22:13:53.89
>>602
え？Modelじゃないの？
煽りじゃなくて、真面目な質問です
2013/01/30(水) 22:14:56.02
あぁ、確かにビジネスロジックではないのか
2013/01/30(水) 22:45:08.78
あえてシェルにMVVMを適用するんならMだろうな
どちらにしろGUIに閉じた話であって、ビジネスロジックの世界とは分けて考えるべき
2013/01/30(水) 22:47:03.45
>>597
VMで正しいよ。

ビューモデルというのは、ドメインモデルとビューとのギャップを埋めるラッパーの役割をするもので、
まさに>>597のようなビュー固有のデータを扱うのに適している。

Vに置くのは（少なくともこのスレにおいては）間違いだから>>602は気にしなくていい。
2013/01/30(水) 22:56:21.08
>>608
それこそビジネスロジックとUIがごっちゃになってね?
もともとビジネスロジックから見たらVの実装の詳細にすぎないことで、
それが少々複雑になるからMVVM適用しようってんなら
GUIの設定情報を持つためのMを使うのが適切だと思うよ
2013/01/30(水) 23:00:06.22
アプリケーションモデルというやつですか。
2013/01/30(水) 23:07:07.58
そもそもそんなロジックに直接関係なくてGUIに閉じた混みいった制御と
金,人間,住所,データベース,入力フォーム云々を一緒にして扱うのがおかしい
そこ明確に分けるのが一番大事だろ
2013/01/30(水) 23:19:21.22
そんなめんどくさいことせんでも、VBで画面にぽちぽちボタンとか張って、
ダブルクリックしてイベント追加したら、その中に全部処理書けばええやろww
2013/01/30(水) 23:22:23.10
PrismだとShellに対してVとVMがあって、ShellのVMのプロパティに
入力画面とかのVM渡して、ShellのVの中でその画面開いて、ツールバーなども
Shellが管理するようになってたはず。サンプルではShellに対するMは無かったけど、
ツールバーの細かい設定入れるとしたら当然この設計ではShellのMになるよね。
ShellのVMが本当に必要かどうかはかなり怪しいが。
2013/01/30(水) 23:22:30.14
>>609
ビジネスロジックというのを定形的に捉えすぎてね？
アプリケーションシェルと言った物の実装も対象が違うだけでビジネスロジックの実装と変わらんだろ。
MVVMはロジックとビューをブリッジ介して分離する仕組みでその対象がシェルでも構わんと思うけどね。
他の実装がしやすいなら無理に適応する必要はないけど。
2013/01/30(水) 23:26:54.51
>>609
ドメインモデル（ビジネスモデル）からはビューモデルに対して一切関知することはなく、完全に独立している。
ビューモデルからはドメインモデルを（継承やコンポジションなどの形で）参照することになるが、
当然ながらドメインの詳細には立ち入らないため、ごっちゃになることはない。

> GUIの設定情報を持つためのMを使うのが適切だと思うよ
ここではモデル（M）をドメインモデルとビューモデルとに明確に区別しているわけで、このGUIの設定情報と
いうのがまさに表示のためのモデルであり、ビューモデルだと>>608で書いたつもり。

なんか噛み合ってないかな？
616609
垢版 |
2013/01/30(水) 23:32:29.95
>>614-615
うん。だからシェルの抽象化がVMだしシェルのロジックやデータがMとするなら
Mじゃないかってことが言いたかった。省くならVMを省くべきじゃない?
バインディングもあんまり役に立たなそうだし。
2013/02/04(月) 00:54:01.35
ViewModelHelper.ReadOnlyDispatcherCollectionのソース見てるんだけど
Dispatcher経由でViewModelのDisposeしなくていいの?
2013/02/04(月) 02:17:34.63
WeakReferenceがなんとか
2013/02/12(火) 00:41:05.78
だからコードビハインドのあるなしとMVVMに何の関連もないと何度言ったら。。。最近コードビハインド付のMVVMしかしてない


おがやさん以前は、コードビハインドはMVVMの癌、肯定してる人は糞みたいなニュアンスのこと言ってませんでしたっけ？
この人若年性健忘症なのかな？
620デフォルトの名無しさん
垢版 |
2013/02/12(火) 00:45:23.42
そーとー昔じゃないかな？それ
2013/02/12(火) 00:59:57.57
いくら昔でも180度真反対に勘違いするほどの痴呆症を患った高齢の方には見えなかったもので。
2013/02/15(金) 08:39:40.77
>>621
ようするにやせ我慢だったと。そういう事です。

コードビハインドなんて所詮MS界隈でしか使われないローカル技術仕様の用語に過ぎず
モデル云々を語る抽象的な概念にはほど遠い。
単に趣味と程度の問題を高尚っぽく語りたい人が散見されるだけ。
623デフォルトの名無しさん
垢版 |
2013/02/16(土) 04:51:33.73
>>622
MS以外でも使われてるだろ
もっと幅広い知識を持たないといかんよ。
2013/02/16(土) 06:51:52.98
例
2013/02/16(土) 10:39:51.16
MS以外のコードビハインドkwsk！
626デフォルトの名無しさん
垢版 |
2013/02/16(土) 11:09:58.98
>>625
knockout.js
2013/02/16(土) 15:33:08.84
なんかデータバインディング持っているフレームワークなら何でもコードビハインドだとでも
言いたそうな勢いだなw

UIの画面設計の宣言的定義とUIロジックの手続き的記述を分けて書けるフレームワークなんて
MS以外にもいくらでもあるし、データバインディングもそのための定番手法の一つではあるが
knockout.js含めて「コードビハインド」という用語がMS関連以外の文脈で使われることなんて
ほとんどね〜よ。手続き的記述の部分をMSが独自にそう呼んでいるだけの話。
2013/02/16(土) 15:44:41.67
日本語だと分離コードになるのか。
確かにMS関連しかその言葉聞かないし、ぐぐってもMS関連しか出てこない
2013/02/19(火) 01:32:44.57
似たようなものだと、コードビハインドという単語ではないけどJSFの管理ビーンとか似た雰囲気
2013/02/19(火) 08:22:24.77
Adobe FlexのMXML+ActionScript3がかなり似ているというか洗練されていると思う。
MXMLでのV定義は単純にAS3でのクラス定義の別記法なので、AS3でのクラス定義と
同様に実装するinterfaceを指定出来る。VMにもinterfaceを定義してあげればVとVMが
互いの実装を知らずにinterfaceだけを通してやり取りが出来る。
VMのinterfaceの先頭にBindableとアノテーションをつければ勝手にgetter・settetが
バインド可能になるのでデータバインディングでVMの値をVにはり付けるのも簡単。
2013/03/03(日) 08:33:04.94
やっぱダイアログや画面遷移はView Serviceにするのが好きだな。
2013/03/03(日) 10:12:08.72
同意
共通に使えるものにメッセージ使うのはアンチパターン
というかメッセージいらない
2013/03/07(木) 11:13:30.47
MVVMの意図するところはこんな認識で合ってる？
・V<->VM の依存関係はバインディングに任せましょ
・VM はデータの加工と操作 (コマンド) の提供に専念しましょ
2013/03/09(土) 07:15:19.68
大雑把にはあってるんじゃないか
2013/03/09(土) 19:14:13.47
MとV&VMを別プロジェクトにして問題ある？
2013/03/09(土) 19:48:12.38
>>635
ないって言うかむしろしろ(´・ω・｀)　
2013/03/09(土) 19:48:13.70
よっぽど小規模でない限り分けるだろ
2013/03/22(金) 14:44:16.04
開幕迎える前にグッバイ・モーガンになるんか？
2013/04/01(月) 12:24:22.90
livet 詳しい人いたら教えてくれ。

ttps://github.com/karno/Mystique/blob/master/Mystique/Views/Dialogs/SettingSub/ColoringConfig.xaml

ここの200行あたりにある感じで、ConfirmationDialogInteractionMessageAction を使う、MenuItem を作った。
でもこの方法だと、MenuItem の IsEnabled に ListenerCommand の CanXXXX が反映されない。
IsEnabled に反映させるにはどうしたらいいんだろうか？
2013/04/01(月) 13:51:12.65
MenuItemに直接アクション持たせてIsEnabled管理も別プロパティでやるか、
CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ
641639
垢版 |
2013/04/01(月) 19:20:38.99
せっかく教えてもらったが、いってることがわからんズラ
「MenuItemに直接アクション持たせて」とはどのようすればいいんだろうか？
サンプルのサイトがあったら張ってもらえないだろうか。

「CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ」
これをやるためには、MenuItem の Command にバインディングする必要があるだろうが、ダイアログの表示はコード・ビハインドでやるという理解でよいでしょうか？

質問ばかりですまんです。
2013/04/01(月) 19:58:53.84
MenuItemのIsEnabledにコマンドの可否状態が反映されないって言うからMenuItemにコマンドはバインドした状態で反映されないって言ってるんじゃなかったの？
それともコマンドをMenuItemにバインドせずにMenuItemに反映されないって言ってるの？

ダイアログの表示ならコマンドで叩かれたVMからVへメッセージ飛ばしてやるんだろ
そのために確認用のトリガとアクション書いたんじゃないのか
643639
垢版 |
2013/04/01(月) 23:25:33.35
質問の仕方がまずかったかな。

IsEnabled と具体的なプロパティを書くのではなくて、
MenuItem の活性・不活性に CanXXXX が反映されない
と書けばよかった。

コードはリンク先に書いてあるのとほとんど同じ。
"Interaction.Triggers"に設定していあるのであって、
MenuItem の Command にはバインドされてない。

質問をかえれば、リンク先のようなコードを書いたが、
これでは SetDefaultColorCommand の CanSetDefaultColor
が MenuItem の状態（活性・不活性）に反映されません。
どうしたらいいでしょうか？
って感じです。
2013/04/02(火) 01:20:28.31
>>643
MenuItemはLivetのメッセージ機構なんて知らないし
DirectInteractionMessageにもコマンドの状態を反映させる仕組みは無いから
自分でやらなきゃならんだろうな。

VMにプロパティを用意してIsEnabledにバインドするとか
コマンドの状態をIsEnabledに反映させるBehaviorでも書けば?
2013/04/02(火) 13:33:43.91
LivetのCommandにはCanExecuteプロパティあるからIsEnabledにそれをバインドするのがいいだろう
646639
垢版 |
2013/04/02(火) 21:29:50.11
>>645
ありがとう。できた。
シンプルな解決策だね。
2013/04/05(金) 08:36:23.77
Livetの0.98辺りの時に書いてたソースコード、
今のバージョンだとそのまま使えないんだな…
DispatcherCollectionとかWindowMessageActionとか、
コンストラクタに渡せるパラメータの型とか順番とか、すっかり変わっちゃってる
2013/04/08(月) 17:23:05.27
Livet .NET4.5で、読み取り専用のスレッドセーフなコレクションをModelに持たせたいんですけど
ObservableSynchronizedCollectionをラップするクラスを自作するしかありませんか?
2013/04/08(月) 19:50:30.83
MVVMだのスレッドセーフだの言う前にマルチスレッドをちゃんと理解しろよ
読み取り専用ならスレッドセーフだからReadOnlyCollection<T>でいい
2013/04/08(月) 20:35:10.02
読取専用のコレクションは変更されないわけじゃないぞ
2013/04/08(月) 20:47:02.14
さすがにそれは無理があるだろ…
それに、随時少しずつ変更されるんじゃなくて時々ゴソっと入れ替わるだけなら
Observable*使わなくてもコレクションごと差し替えてしまえばいい
2013/04/08(月) 21:01:42.99
っていうか作法的には>>651のやり方の方が正しく「スレッドセーフ」だと思う
Observable*使うと、連続してコレクションを変更するときに変更途中の変な状態が晒されちゃうよ
決してObservableSynchronizedCollectionなら解決するという問題ではなく
2013/04/08(月) 21:35:22.96
一括で変化させるのではなく、逐一反映させたいのです。
その為読み取り専用ラッパもINotify〜でないといけません。
2013/04/11(木) 14:22:53.29
Livetプロジェクトを作った時にできるInfrastructureAssembliesフォルダは何のためにあるの?
655654
垢版 |
2013/04/11(木) 14:37:04.33
すいません。必要なDLLとクイックヒントのXMLっぽい事は分かりました。
でもLivet.Design.dllが何の役割があるのか分かりません。
2013/04/13(土) 02:18:05.29
>>648
ReadOnlyObservableCollection
2013/04/15(月) 14:41:24.53
昔の0.9xのLivetで開発してたもので、画面描画が完了したタイミングでアニメーション開始させるために

DispatcherHelper.BeginInvoke(action, DispatcherPriority.Render);

みたいに書いてたのがあるんだけど(actionはアニメーション開始させる処理)、
今のLivetだと「BeginInvokeは古い形式です」とかいう警告になってしまう。

まぁ、警告だからコンパイルできるし実行もできるんだけど…
警告出ない、古くない形式ってどう書けばいいんだろう?
2013/04/16(火) 00:44:11.22
UIDispatcherプロパティからBeginInvokeだったと思う。
2013/04/16(火) 07:45:34.55
>>658

それでOKみたいですね どうもでした

0.9xと1.xで、結構変わってるとこ多いですねー
2013/05/02(木) 16:37:49.02
MVVMでの非同期処理をする場合について質問なんですが

MはUIスレッドを意識せずプロパティやコレクションを変更し
それを監視してるVMが適宜UIスレッドにディスパッチする

という感じでするのでしょうか?
2013/05/02(木) 17:18:30.55
UIスレッドというものはView側の都合だからそんな感じだな
VかVMあたりだろう
2013/05/08(水) 13:29:53.61
Livetの公式ページが404 File Not Foundになってる…
2013/05/08(水) 14:57:34.62
よくあること
2013/05/10(金) 06:05:27.27
よくあるのか
たまにしか見に行かないから、この1年半くらいで初めてだった
そのうち直るのかな
2013/05/14(火) 17:27:08.94
@merancronと@ugaya40のサイレントバトルがかなり面白い
2013/05/17(金) 06:09:53.49
Livetのページ、1週間以上経ってもまだ404 File Not Foundなんだが閉鎖しちゃった?
それとも移転したのか?
閉鎖にしても移転にしても何かその旨書いといて欲しい
しかしユーザー困るな
2013/05/17(金) 14:40:36.69
>>666
たぶんサーバーの料金払ってないだけ
668デフォルトの名無しさん
垢版 |
2013/05/17(金) 15:27:29.29
MVPなんだからAzureの無料枠ぐらいもらってるだろうに……
669デフォルトの名無しさん
垢版 |
2013/05/17(金) 19:00:21.91
や　ら　な　い　か
670デフォルトの名無しさん
垢版 |
2013/05/17(金) 19:07:32.07ID:NuBHhb8n!
kon
671デフォルトの名無しさん
垢版 |
2013/06/24(月) 11:30:16.12
Uにリムーブされていることに気がついたｗ
まあ、ちょくちょく揉めてたからなｗ
2013/10/03(木) 15:35:02.10
Vにバインドしたコマンドの内部で非同期操作を呼び出したときのお作法ってあるんですかね？
673デフォルトの名無しさん
垢版 |
2013/10/03(木) 16:40:34.53
俺は気にしてないが、VMでは特に気にしなくていいんでね？
2013/10/10(木) 22:24:40.50
>>672
同じコマンドを複数回読んだ場合、場合によっては順序が変わる可能性あるからその辺に注意ぐらいかのー
2013/10/10(木) 23:00:23.03
いい加減日本語の書籍を出してほしい。
2013/10/14(月) 23:43:00.78
ModelがINotifyPropertyChangedを実装する理由は
Mを操作した結果、プロパティが変化したことを通知する
という理解でいいですか?
2013/10/15(火) 12:36:49.83
OK
2013/10/16(水) 15:35:26.82
>>676
OnPropertyChanged で渡すプロパティ名が間違っていると View への通知が
正しく行われない。当たり前の話だけど、この種のつまらないトラブルが
多いから注意してね。
2013/11/14(木) 23:01:29.82
>>394
ちょっと前の書き込みだけど、フォルダ分けみんなどうやってるかが気になる。
やっぱ、View/ViewModel/Modelって分けてるのかな？
なんか、画面が大量にある場合とかに、V/VMのクラスが大量にできて、対応するV/VMのペアが、IDEから辿りにくいんだよなぁ。。
V/VMがたくさんあるような時って、機能とかグループごとにサブフォルダでまとめた方がいいのかな。
こんな風に、、
・グループ1フォルダ
　・View
　　ここにグループ1のViewを複数入れる
　・ViewModel
　　ここにグループ2のViewModelを複数入れる
・グループ2フォルダ
　・View
　・ViewModel
2013/11/15(金) 07:23:33.44
俺も最初に参考にしたサンプルが
View/ViewModel/Model みたいにフォルダ作ってたので
それに倣ってそんな感じにしたけど、サンプル程度のクラス数ならいいんだけど
数が2桁くらいになってくるといまいちだよね。サブフォルダまで作っても。
むしろ、特定の機能のフォルダ作っちゃって、そこに
それに関連したView/ViewModel/Modelをセットで入れる、みたいなのも
逆にそこだけで完結しないで複数にまたがるのが分類しにくかったり。
681デフォルトの名無しさん
垢版 |
2013/11/15(金) 13:19:46.47
>>680
俺もそれが妥当と思う
2013/11/15(金) 14:20:43.75
少なくともView内は分けない方がいいと思う
2013/11/15(金) 14:31:37.31
昔はフォルダで分けてたけど、今はこんな感じ↓

　　ソリューション
　　　　- ModelLayerプロジェクト
　　　　- ViewModelLayerプロジェクト
　　　　- ViewLayerプロジェクト
　　　　- UnitTestプロジェクト
　　　　- Commonプロジェクト
2013/11/15(金) 14:38:30.55
書き忘れたけどもう一つ、ソリューション名と同名のプロジェクトが有るな
（仮にMainプロジェクト）

MainプロジェクトとUnitTestプロジェクトは、アプリケーションプロジェクトで
V/VM/M及びCommonプロジェクトは、クラスライブラリプロジェクト
2013/11/15(金) 18:56:17.04
C#の場合自動生成される名前空間にフォルダ階層が付加される仕様がこういう場合鬱陶しい
2013/11/15(金) 19:45:58.66
複数の機能(サブシステム)から構成されるようなアプリなら、俺も680派。
「レイヤ」よりも「機能」の方が凝集度高いんだし。
1機能内でもまだ画面が多いようなら、/機能/の下にView/ViewModelとかを作っても良いけど。
そこまででなければ、少なくともViewとViewModelはセットで。
Modelは、機能固有のものならセットにしても良いけど、だいたいはアプリケーションレベルで
考えるものな気もするので、別配置。
2013/11/15(金) 23:49:30.50
ModelはともかくViewとVMは一対一で対応してること多いからなあ
2013/11/16(土) 04:31:20.31
Modelはフォルダどころか別プロジェクトだろ
689679
垢版 |
2013/11/17(日) 16:07:31.49
>>680,686
機能ごとに分けて、そのフォルダの中にV/VMを突っ込むのよさそうだね。
VとVMは一緒にいじること多くて、近くに置いておきたいし。

ありがとう!!
すごく参考になった。
2013/11/17(日) 16:51:12.93
VMが扱うモデルは１つとは限らないわけで、そういうのは無理があると思うけどね
2013/11/18(月) 10:21:42.10
ん？
2013/11/19(火) 23:38:23.24
>>690
機能単位でまとめるのはVとVMまでにして、モデルは別フォルダとか別プロジェクトにまとめる、でいいんんじゃないかな？
2014/01/13(月) 13:39:58.61
Mの設計にいまいち確信が持てないんだけど
例えばChromeみたいなタブブラウザを作る場合、開いてるページのコレクションはMで持つの?
694デフォルトの名無しさん
垢版 |
2014/01/13(月) 18:47:34.47
>>693
MVVMはそんなに厳密に考えんでいいと思うけどね。
VMをVIEWを軽くするためのロジック移し場所ぐらいに考えてモデルを分ける必要あるなら作ると。そのモデルは一つでも複数でもいい。
Chromeの例なら自分なら開いてるタブやその他の状態を持つアクター一個作るかな。
2014/01/14(火) 13:13:51.65
MVVMの設計に関しては、
まずアプリケーションをVとMに分ける。
次にVをVとVMに分ける
くらいの考えでいいと思う
2014/01/15(水) 10:21:03.85
今はMVVMPCEARELS
2014/03/05(水) 07:59:10.50
test
2014/03/05(水) 16:17:16.97
普及している感じがしない
2014/05/19(月) 20:39:55.28ID:kwGHw8xe
ModelがViewを意識しなきゃいけないとか言ってるアホの事は無視して良いですか？
それは単に、本来Modelの責務だったものっていうだけじゃないのかよ。
2014/05/20(火) 17:04:41.75ID:Vv+C9W3P
>>699のような手合いは一度ふぁうらー先生の本でも読んだらいいよ
関心事の分離とフレームワーク依存がわかってない
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況