MVVMについて語ろう

**デフォルトの名無しさん** · 2012/06/06(水) 11:03:33.21

WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！

**デフォルトの名無しさん** · 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にそれをバインドするのがいいだろう

**639** · 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フォルダは何のためにあるの?

**654** · 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
たぶんサーバーの料金払ってないだけ

**デフォルトの名無しさん** · 2013/05/17(金) 15:27:29.29

MVPなんだからAzureの無料枠ぐらいもらってるだろうに……

**デフォルトの名無しさん** · 2013/05/17(金) 19:00:21.91

や　ら　な　い　か

**デフォルトの名無しさん** · 2013/05/17(金) 19:07:32.07

kon

**デフォルトの名無しさん** · 2013/06/24(月) 11:30:16.12

Uにリムーブされていることに気がついたｗ
まあ、ちょくちょく揉めてたからなｗ

**デフォルトの名無しさん** · 2013/10/03(木) 15:35:02.10

Vにバインドしたコマンドの内部で非同期操作を呼び出したときのお作法ってあるんですかね？

**デフォルトの名無しさん** · 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

**デフォルトの名無しさん** · 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をセットで入れる、みたいなのも
逆にそこだけで完結しないで複数にまたがるのが分類しにくかったり。

**デフォルトの名無しさん** · 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はフォルダどころか別プロジェクトだろ

**679** · 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で持つの?

**デフォルトの名無しさん** · 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.28

ModelがViewを意識しなきゃいけないとか言ってるアホの事は無視して良いですか？
それは単に、本来Modelの責務だったものっていうだけじゃないのかよ。

**デフォルトの名無しさん** · 2014/05/20(火) 17:04:41.75

>>699のような手合いは一度ふぁうらー先生の本でも読んだらいいよ
関心事の分離とフレームワーク依存がわかってない

**デフォルトの名無しさん** · 2014/05/20(火) 20:57:52.43

PoEAAは読んでるけど、どこがわかってないのかわからないので、教えてくれ。

**デフォルトの名無しさん** · 2014/05/20(火) 22:25:34.65

>>699
今迄一度もViewでこのデータが必要だからここに持たそうとかやったことのないものだけが石を投げなさい(｡-_-｡)

**デフォルトの名無しさん** · 2014/05/21(水) 21:50:13.56

>>700
マジでなにがどうわかってないんだか教えて欲しいんだがな。

**699** · 2014/05/24(土) 11:22:05.67

toroのログが欠落しちゃってるのか。

で、ごめんなさい、読み返してみて、自分の言い方が完全に悪かったと思いました。

toroの705の言っていることに対する認識の相違はないです。

自分がアホだと思ったのは[ModelがViewを意識]と[Modelの責務]をごっちゃにして、
[Modelの責務]として適切だった例を論拠に[ModelがViewを意識]を都合良く解釈して、
短絡的に、なんでもModelに実装して良いんだというような発言をしている人の事です。

**デフォルトの名無しさん** · 2014/08/08(金) 20:06:25.89

派遣で行った先がひどかった

VMで、いろんな処理に使われるプロパティAが
VMのコンストラクタとかで初期化されるわけでもなく、
一体どこで初期化されてるんだ? と思ったら、

そのVMの、全く別のプロパティBがVにバインドされてて、
そのプロパティBが読みだされる時に
初めてプロパティAが初期化される、というとんでもない仕組み。

当然、VとバインドしてBが呼び出されない限りAは永遠に初期化されないので
Aを使ういろんな処理も一切できないという、
Vなしでは成り立たないVM

正気の沙汰とは思えなかった

**デフォルトの名無しさん** · 2014/08/11(月) 04:58:47.86

なんか問題あったの？

**デフォルトの名無しさん** · 2014/08/28(木) 11:45:13.53

MVVMのM/VM/Vの各要素はなんとなく分かったけど、全体でどんな形になるかいまいち確信が持てないんだけど
何かいいサンプルコードないかな。
特にModelの設計で参考になるようなのが欲しい。

**デフォルトの名無しさん** · 2014/10/26(日) 00:10:47.24

Prism5.0が出たそうなんだけど、画面遷移とかで標準になりそうな新しい切り口出てた？

**デフォルトの名無しさん** · 2014/10/26(日) 07:28:37.82

MSがこれ使えっていう決定版出してほしいな。
プロジェクト形式でもいいから。

**デフォルトの名無しさん** · 2015/02/26(木) 21:33:45.94

ReactiveProperty良さげなんだけど使ってる人います？
週末にでも遊んでみよう。

**デフォルトの名無しさん** · 2015/09/25(金) 15:22:24.80

Livet1.3キタ

**デフォルトの名無しさん** · 2015/10/21(水) 22:31:30.80

WPF MVVMでアプリ作ってる人いるんだろうかと思えるくらい過疎っぷりだな
ほんと情報少なくて困ってる

**デフォルトの名無しさん** · 2015/10/22(木) 01:36:32.77

こんなスレあったのか。今まで気が付かなかった。
MVVMは机上の空論っていうか筋が悪いの一言に尽きると思う。
これは過去にオブジェクト指向が攻撃されたような批判者の理解不足に基づく誤解では必ずしもない。

**デフォルトの名無しさん** · 2015/10/22(木) 11:01:27.71

とオブジェクト指向の時にも同じようなことを言っていた人はいた。

**デフォルトの名無しさん** · 2015/10/22(木) 12:13:21.98

>>713
具体的にはMVVMのどこらへんが実情に即していない机上の空論で、筋の悪さなの？
可能であれば、古典的MVCやMVPとの比較も交えながら論じてみてほしい。

**デフォルトの名無しさん** · 2015/10/22(木) 13:13:45.09

>>714
オブジェクト指向は筋が悪かったからな

**デフォルトの名無しさん** · 2016/01/20(水) 23:45:57.28

結局どんな設計がいいの？
Rxに傾倒したけど、上手く使いこなせてない

**デフォルトの名無しさん** · 2016/05/01(日) 15:54:23.24

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ

The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
・

**デフォルトの名無しさん** · 2016/05/01(日) 22:27:00.95

>>717
fluxとかかな。まだよく分かっていないけど。
状態を一箇所に集約する

**デフォルトの名無しさん** · 2016/05/03(火) 11:18:03.92

fluxのデータフロー見てたらApache Strutsを再発明したかったのかなって思た

**デフォルトの名無しさん** · 2016/05/10(火) 17:20:07.82

MVVMって保守性が悪いよね。
WPF自体がそういう傾向が強いけど、MVVM使うと輪を掛けてそうなる。

他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。

MVVMで保守性が高くなるんだ！って喧伝してる人がいるのは知ってるけど、
正直裸の王様を褒めてるようにしか思えない。

**デフォルトの名無しさん** · 2016/05/10(火) 20:43:19.06

結局正解はなくて最適解があるだけなんだけどさ
よくある失敗はMVC、それも頭でっかちなコントローラーをVMに置き換えているだけパターン
この場合ビューモデルが主役で、テンプレートエンジンのビューと1:1の対となる入れ物の箱モデル
を量産することになる
ちょこっとイベントハンドラーをコードビハインドに書いたら、あとは全部ビューモデルにお任せ
という中央集権国家が誕生、疎結合どこいったって話だな

**デフォルトの名無しさん** · 2016/05/10(火) 21:04:44.88

>>721
>他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
>ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。

これって単に慣れてないからってだけじゃなくて？

**デフォルトの名無しさん** · 2016/05/10(火) 21:24:17.05

昔のようなデバッグして追いづらいってのはあるな。

**デフォルトの名無しさん** · 2016/05/11(水) 11:26:55.39

やっぱりrails系は偉大だったってことかなー。
どこにどんなコードを置くのかフレームワークとして強制するって大事だね。
iOSとかUIKitってだけだから特にファイル構成に対する強制がなくて悩む。

**デフォルトの名無しさん** · 2016/11/25(金) 20:31:02.28

お前らがMVVM頑張っても
画面設計者がMVVM理解者とは限らないから
どこかは破綻するんやで

**デフォルトの名無しさん** · 2016/12/15(木) 23:39:13.49

MV)o￥o(VM

**デフォルトの名無しさん** · 2017/03/23(木) 17:58:48.49

データを格納したdatatableをdatagridにバインドして表示させてます。
この場合、datatableはVMですか？Vですか？

**デフォルトの名無しさん** · 2017/03/23(木) 23:57:20.04

他のフレームワークに比べてMVVMが有用なケースって、WPF以外だとどんなのがありますか？

**デフォルトの名無しさん** · 2017/03/31(金) 23:28:02.62

>>729
Xamarin.Forms
vue.js

**デフォルトの名無しさん** · 2017/04/21(金) 04:30:27.44

UWPみたいな大きい画面から小さい画面までサポートする奴。
UIとロジック分けられないと死ねる。

**デフォルトの名無しさん** · 2017/05/11(木) 22:40:49.29

modelからViewModelに通信の結果を返すときに、
Rxとか使わずに、interfaceを渡してコールバックを返すようにするのは何かマズいんでしょうか

**デフォルトの名無しさん** · 2017/05/11(木) 23:10:02.50

Rxも結局インターフェースだしいいんじゃ？

**デフォルトの名無しさん** · 2017/05/11(木) 23:55:27.09

modelは状態の公開と戻り値のないメソッドの提供のみするそうですが、
状態の公開っていうのは要はpublicなfieldってことなんでしょうか
getterで提供したらなんで駄目なんでしょうか
c#のことはよくわかりませんandroid javaを想定しています

**デフォルトの名無しさん** · 2017/05/12(金) 11:29:50.90

>>734
メソッドの戻り値をvoidにする、setterを提供しないのはMVVM由来ではなく、非同期な作りをしたい場合に起因します。

これは非同期な作りの場合、メソッドを呼び出しても直ちに状態が変更されるとは限らないから。

なので、状態の変更が完了した時点でMが通知し、受信側がgetterを介して状態を取得することを推奨しているに過ぎない。

逆に同期的な呼び出ししかしないのであれば、setterやメソッドの戻り値も好きにすればいいと思います。

**デフォルトの名無しさん** · 2017/05/12(金) 12:01:49.68

がや氏の戻り値返すなとかはCQRSやReactみたいに処理の流れを固定しろってのが本質と思うが本人もアーキによって返しますよとかいってるからじゃああの煽りはなんだったの感もありよくわかんね

**デフォルトの名無しさん** · 2017/05/12(金) 18:50:06.13

本人の中では色々な蓄積もあってその上で言ってんだろうけど、間を飛ばすから外から見たらよくわからん事になってるという印象

**デフォルトの名無しさん** · 2017/05/12(金) 19:52:15.91

とりあえず御大の言うことはスルーしておいて、Flux、Reduxなんかについて調べてから、自分で答えを出せばよろし

**デフォルトの名無しさん** · 2017/05/12(金) 20:05:15.61

C#で状態の公開というとプロパティを使うわけだけど、
javaにはプロパティがないからgetter使うしかないだろうし…
そもそもMVVMではgetter使っちゃダメなんて話があるの…？

**デフォルトの名無しさん** · 2017/05/12(金) 20:34:29.17

状態の公開が何でpublicなfieldになんのか分からん
オブジェクト指向もっかい勉強した方がいい

**デフォルトの名無しさん** · 2017/05/12(金) 22:16:02.54

いや返り値のないメソッドしかテイギシタラ駄目っていう縛りがあると思ってたから、
getterも駄目なのかと

**デフォルトの名無しさん** · 2017/05/12(金) 23:10:52.37

MVVMの提唱がMSからだし、MSが作った言語にはプロパティがあるから…
…javaのgetterが駄目ならプロパティ使うのも駄目になるはず

**デフォルトの名無しさん** · 2017/05/12(金) 23:56:43.00

ゲッターかプロパティかは本質じゃないだろう。
ゲッターをフィールドっぽく見せてるのがプロパティなだけなんだし。