1デフォルトの名無しさん2012/06/06(水) 11:03:33.21
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
2デフォルトの名無しさん2012/06/06(水) 11:09:54.07
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
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
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
25デフォルトの名無しさん2012/06/06(水) 20:54:32.74
Mについてはそれなりに構築できるけど、
そこにVを被せるときに毎回苦労するんだなー
26デフォルトの名無しさん2012/06/06(水) 20:58:39.14
対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。
MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、
ひいては状態を持っているるからドメインモデルです(｀・ω・´)ｷﾘｯ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。
27デフォルトの名無しさん2012/06/06(水) 22:10:29.54
いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな
28デフォルトの名無しさん2012/06/06(水) 23:41:43.34
だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある？、っていう。
まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。
DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、
サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。
29デフォルトの名無しさん2012/06/07(木) 00:03:55.68
それはアプリケーション（Model）の役目だろうよ
V＆VMはむしろ生成される側だと思われ
30デフォルトの名無しさん2012/06/07(木) 00:13:47.89
簡単に言えば
V 見た目
M 本処理
VM 接着剤
だろ
MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで
UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな
Modelって名前なんだから何々であるべきなんだ！！１なんて話はナンセンス
31デフォルトの名無しさん2012/06/07(木) 00:14:54.65
その「アプリケーション（Model）」っていう言い方も微妙だが…。
生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。
でも、その話すらしないのだとしたら、本当に何の話をするんだ？
32デフォルトの名無しさん2012/06/07(木) 00:15:55.19
ザックリ分けると
・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
・MVVMとしての各画面の作り方の部分
・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分
って感じかね。
33デフォルトの名無しさん2012/06/07(木) 00:16:50.09
>>30で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの？ 34デフォルトの名無しさん2012/06/07(木) 00:23:50.25
>>33
>>30の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの？ 35デフォルトの名無しさん2012/06/07(木) 00:36:57.38
MVVMの実装に関する話ならいくらでもできるんじゃね
36デフォルトの名無しさん2012/06/07(木) 01:12:27.18
むしろそちらの方を知りたいという人間多いんじゃね？
MVVM的に考えるとコマンドはVMに置くべきか否か
コードビハインドとイベントハンドラとVMの関係
コードビハインドはいわゆるプレゼンターか否か
バインディングとMVVMは切り離して考えるべきか否か
MVVMとしてふさわしいVMの実装は
もっと高速にVMを実装する方法はないかとかね
37デフォルトの名無しさん2012/06/07(木) 01:13:45.85
あとMVVMツールの良し悪しや使用方法についてとか
38デフォルトの名無しさん2012/06/07(木) 01:19:01.75
ビヘイビアってよく聞くけどVMに入るの？
39デフォルトの名無しさん2012/06/07(木) 06:11:20.38
>>32みたいな、アプリケーション構造の話をするのはこのスレではあり？、なし？
MVVMフレームワークの実装比較の話は俺も聞きたいな。 40デフォルトの名無しさん2012/06/07(木) 06:16:05.12
定義論にまた脱線しない限りまあいいんじゃね
41デフォルトの名無しさん2012/06/07(木) 08:14:29.03
42デフォルトの名無しさん2012/06/07(木) 09:30:27.00
Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。
その境界がどこかの確認。
43デフォルトの名無しさん2012/06/07(木) 09:57:41.92
>>42
新参者だが、荒れるん？
むしろMVVM作る上で重要なファクターだと思うんだが。 44デフォルトの名無しさん2012/06/07(木) 10:11:41.27
Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです！、な発言が出てくるから。
その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。
45デフォルトの名無しさん2012/06/07(木) 10:16:56.33
何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか
MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ
46デフォルトの名無しさん2012/06/07(木) 10:28:50.09
本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。
そこでV〜M間に仲介者を設け、V(XAML)、VM（C#）の二層構造とし、VMにViewの状態とModelのデータを保持させて
V〜VM間をバインディングで通信するのがMVVM。
47デフォルトの名無しさん2012/06/07(木) 10:30:41.00
ほらｗ
>>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途
WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。
48デフォルトの名無しさん2012/06/07(木) 10:35:21.73
>>45
それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには１も３も必要だろ。 49デフォルトの名無しさん2012/06/07(木) 10:58:40.42
＞DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
ってMVVMとどう関係あるの？
洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがｗ
50デフォルトの名無しさん2012/06/07(木) 11:00:01.66
>>48
VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ 51デフォルトの名無しさん2012/06/07(木) 11:04:12.67
>>49,50
M内の構造はMVVMとは関係ないよ。
でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ？
MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。
52デフォルトの名無しさん2012/06/07(木) 11:07:44.33
53デフォルトの名無しさん2012/06/07(木) 11:16:28.31
>>46
そもそもVMはV層でしっかりVとMの分離になってるんじゃないか
Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし 54デフォルトの名無しさん2012/06/07(木) 11:18:42.66
やっぱり、VVM内に閉じた話だけを扱うスレなのか？、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか？、っていう最初に戻るじゃん。
VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。
55デフォルトの名無しさん2012/06/07(木) 11:26:13.73
定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる
定義知りたきゃMVVMでぐぐってろ
56デフォルトの名無しさん2012/06/07(木) 11:27:07.00
そもそもMVVMってなに？
57デフォルトの名無しさん2012/06/07(木) 11:27:49.63
58wikiから抜粋2012/06/07(木) 11:33:08.35
Model
アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、
サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。
MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる
一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。
たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。
アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。
Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。
59デフォルトの名無しさん2012/06/07(木) 11:34:10.24
MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。
それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね？
60デフォルトの名無しさん2012/06/07(木) 11:36:30.09
61デフォルトの名無しさん2012/06/07(木) 11:40:56.25
わかりにくいからMVVMをガンダムでたとえて
62デフォルトの名無しさん2012/06/07(木) 11:47:53.91
>>54
そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・｀) 63デフォルトの名無しさん2012/06/07(木) 11:49:55.46
>>61
M=ララァ
VM=サイコミュ
V=ビット 64デフォルトの名無しさん2012/06/07(木) 11:58:29.11
65デフォルトの名無しさん2012/06/07(木) 12:54:35.30
スレのあり方を議論するだけで終わりそうだｗ
66デフォルトの名無しさん2012/06/07(木) 13:03:38.18
おまえが勝手に思ってるだけだろ
67デフォルトの名無しさん2012/06/07(木) 13:17:43.48
質問です。
ButtonクリックしてViewModelからWindowクローズしたいんだけど、ViewModel側にはどう書いたらいいのでしょうか？
68デフォルトの名無しさん2012/06/07(木) 13:21:47.51
ウィンドウを閉じる動作はViewで完結しているものなんじゃないでしょうか
69デフォルトの名無しさん2012/06/07(木) 13:57:19.39
ウィンドウサイズ保存したい
70デフォルトの名無しさん2012/06/07(木) 13:57:28.88
>68
そうなんですか？わかりました...(´･ω･`)
71デフォルトの名無しさん2012/06/07(木) 14:36:34.99
72デフォルトの名無しさん2012/06/07(木) 14:36:56.58
>>68
未保存のデータがあるときだけ確認メッセージを表示とか、Viewだけじゃ完結しないだろ。 73デフォルトの名無しさん2012/06/07(木) 16:02:42.75
74デフォルトの名無しさん2012/06/07(木) 16:10:07.46
よし分かった、俺がこれがコードビハインドだって
お手本のプログラムを作って見せてやるよ。
75デフォルトの名無しさん2012/06/07(木) 16:21:57.25
>>73
他のMVVMツールにも同様の機能はありますか？ 76デフォルトの名無しさん2012/06/07(木) 17:01:49.59
77デフォルトの名無しさん2012/06/07(木) 19:40:33.37
ugaya40さん、MVVMの本書いてよ。
78デフォルトの名無しさん2012/06/07(木) 20:19:01.71
彼は文書よりもLivetのチュートリアルの優先度をあげるべきだろ。
79デフォルトの名無しさん2012/06/07(木) 20:39:57.25
チュートリアルないと使えないか？
サンプルなら探せばそれなりにあると思うけど
80デフォルトの名無しさん2012/06/07(木) 20:47:05.63
使える使えないという話ではなく、広くアピールしたいならそういう地味な作業の優先度の方が高いんじゃないの、という話。
81デフォルトの名無しさん2012/06/07(木) 20:47:06.97
82デフォルトの名無しさん2012/06/07(木) 20:52:17.02
ところで、これってMVCとどう違うの？
MVCのときとMとVも当然違うと思うんだけど。
83デフォルトの名無しさん2012/06/07(木) 20:52:18.22
u氏の言っていることは、VVMや実装の話についてはほぼ同意だしすごいとも思っているけど。
ただ、そこからMよりの話やもっと大きな構造の話になってくると、言っていることが微妙というか、
言おうとしていることはわかるけど、他の人の同意は得られないだろうな、っと思うことが多いかな。
84デフォルトの名無しさん2012/06/07(木) 21:28:22.45
Livet使ってるけど2chの名無しに返信しないで欲しい、とだけ言っておきたい
85デフォルトの名無しさん2012/06/07(木) 22:11:46.33
Livetネタは荒れるからやめろ。
本人に直接聞け。
86デフォルトの名無しさん2012/06/07(木) 22:23:47.65
>>77
そんなニッチ層向けの本書いても売れないだろ 87デフォルトの名無しさん2012/06/07(木) 22:59:32.63
MVVMってどれがええの？
Livetがオススメ？
88デフォルトの名無しさん2012/06/07(木) 23:01:51.98
mvvmlight
89デフォルトの名無しさん2012/06/08(金) 00:29:17.99
それはプログラミングにどの言語がいいのかと聞くようなもので
PrismもLivetもMVVMLightもどれも一長一短だからな
人に聞けばたぶんバラバラに返ってくるだろうから
一度使ってみて使いやすいのを判断したほうが早い
90デフォルトの名無しさん2012/06/08(金) 01:33:55.43
91デフォルトの名無しさん2012/06/08(金) 08:13:09.32
>>89
そういうんでは、その一長一短を聞きたいんだろ。
ぜんぶ試すってのはなかなか難しい。
92デフォルトの名無しさん2012/06/08(金) 10:23:56.69
93デフォルトの名無しさん2012/06/08(金) 11:41:06.72
VMへのサービス層のDIってどうやるべきものなの？
それ以前に、VMとMを繋ぐ方法として、VMにサービス層をインジェクションする、っていう考え方はあってる？
94デフォルトの名無しさん2012/06/08(金) 11:59:23.74
>>93
時と場合によるんだろうけど、そうするとMでやるべきのがぜんぶVMに来ない？ 95デフォルトの名無しさん2012/06/08(金) 12:38:59.57
>>94
自分が想定したのは以下の様なサービスファサードがあったとして。
interface HogeServeiceFacade
{
IE<Foo> GetFooList();
}
HogeServeiceFacadeの実装の中では、外部サービスにアクセスしたり、ドメインモデルによる処理をしたり。
HogeServeiceFacade自体はバッチやWebでも使うものだとして。
ここがファサードになるので、それ以上Mの処理がVMに来ることは無いと思っているんだけど。
っで、このHogeServeiceFacadeとVMを接続する方法にコンテナ/サービスロケータを使う場合に
どうするのかとか？、それって考え方としてそもそもあっているの？、っていうのを聞きたかった。
96デフォルトの名無しさん2012/06/08(金) 12:44:10.40
>>95
そういうんではありなんじゃない？
そもそもMVVMは大本はViewとMの分離があって、それにさらに薄いVMいれると更にセパレーションで来て良いよねって話だから。
で、ロケータ使う場合色々あるけど既存の使うか自前で作るかじゃない。
薄いやつなら実質ただのKeyValueで出来るだろうし、それで結構まかなえると思われ。Prismとかはその辺も実装されてる。DIがより良くインテグレートされてる。他は知らん。 97デフォルトの名無しさん2012/06/08(金) 13:03:47.05
コンバータ(IValueConverterを実装したクラス)はMVVMのどの層に属するものなの？
98デフォルトの名無しさん2012/06/08(金) 13:07:30.90
99デフォルトの名無しさん2012/06/08(金) 13:20:41.29
コンバータ自体簡易VMみたいなもんじゃね？
100デフォルトの名無しさん2012/06/08(金) 13:32:59.19
101デフォルトの名無しさん2012/06/08(金) 13:47:18.95
コンバータ、StringFormat、VMでの詰め替え等が混在していると保守性が悪くなりそうだ
102デフォルトの名無しさん2012/06/08(金) 13:55:44.00
VMでなんでも出来はするるが、責務としてVMでやるのはデータ構造の変換までにして、色だの文字だのの修飾はコンバーターでやるべきだろう。
103デフォルトの名無しさん2012/06/08(金) 13:57:35.24
自分はコンバータも形式の変換で、修飾なりなんなりはViewにやらせるな
104デフォルトの名無しさん2012/06/08(金) 14:47:38.34
おまえらユニットテストには何使ってるの
105デフォルトの名無しさん2012/06/08(金) 14:53:47.65
>>96
Thx
考え方としてはありか。
Prismにはその辺の仕組みもあるのね。
じゃあ、各フレームワークでそういう機構を持っているものについて、該当クラス名とかを知っている人がいたら教えて下さい(*・ω・)*_ _)ﾍﾟｺﾘ
後は自分で調べるので。 106デフォルトの名無しさん2012/06/08(金) 15:13:12.05
107デフォルトの名無しさん2012/06/08(金) 15:14:23.05
MVCとかMVPとかのパターンを判りやすく解説してる本あったら教えて
108デフォルトの名無しさん2012/06/08(金) 15:24:26.98
109デフォルトの名無しさん2012/06/08(金) 15:27:32.55
上のご神託を読んでこい。
110デフォルトの名無しさん2012/06/08(金) 15:36:30.90
>>109
いや、MVVMの前提となるMVCやMVPについて知りたいんだが
やっぱファウラー先生あたりの本になるのかな？ 111デフォルトの名無しさん2012/06/08(金) 15:57:52.51
偉い先生が書いたものとか読んだことないわー
MVCとかなにかのパターン本に乗ってたけどネットで探れるのと大差ない。
MSDNでMVPVMの説明してるやつでMVC,MVP説明してるのあったお
112デフォルトの名無しさん2012/06/08(金) 16:02:11.72
MVCではクライアントはC(イベントハンドラ、リスナー、コールバック)に
アクセスしてVがレスポンスとして帰ってくるのに対し、
MVVMはクライアントがVにアクセスしてVが帰ってくる感じだな。
HTMLならステートレスなMVCが、Viewがクライアント内にある
ステートフルなappletとかsilverlight、デスクトップGUIならMVVMが良さそうだ。
113デフォルトの名無しさん2012/06/08(金) 16:12:29.99
MVCについて知りたいならSmalltalkを調べろ。
WebのMVC(2)ならむしろRESTってキーワードで調べろ。
MVVM自体に関する本は知らん。
そしてそれとは関係無しに、PoEAAなんかも読んでおくべき。
PoEAAだけ読んで、ドメインモデルvsトランザクションスクリプト厨になったりする奴も多いけどな。
114デフォルトの名無しさん2012/06/08(金) 16:18:06.91
そろそろ電子書籍で売ってくれ
115デフォルトの名無しさん2012/06/08(金) 17:40:37.50
>>113
MVCってSmalltalkコミュニティから提唱されたのか 116デフォルトの名無しさん2012/06/08(金) 18:47:52.68
たしか。
オブジェクト指向の元祖たるSmalktalkで発展したものだと効いた希ガス
117デフォルトの名無しさん2012/06/08(金) 19:10:59.99
良スレの予感。
118デフォルトの名無しさん2012/06/08(金) 20:31:39.36
やっぱりVMのライフサイクル管理やVMへのインジェクションを行うサービスロケータはあっても良いよな。
アプリケーションの構造によっては別にいらないだろうけど。
119デフォルトの名無しさん2012/06/09(土) 10:42:20.11
複数ViewModel間の呼び出しってどうすべき？
120デフォルトの名無しさん2012/06/09(土) 11:28:54.73
public string Name
{
get { return Model.Name; }
set { Model.Name = value; }
}
こういう感じで VM で M のプロパティを V に伝えるためだけの
プロパティってなんていうの？
121デフォルトの名無しさん2012/06/09(土) 11:41:10.30
ごめん、knockout.js の話題はここで良い？
122デフォルトの名無しさん2012/06/09(土) 11:45:02.52
>>120
NotifyPropertyChanged使わないなら直接Modelのプロパティにバインドしてよくね 123デフォルトの名無しさん2012/06/09(土) 14:57:44.75
>>122
難読化でいちばん隠したい部分がまる見えになるからオススメできない
プロパティ多すぎて書きたくねぇ！ってならＴ４ 124デフォルトの名無しさん2012/06/09(土) 16:03:19.03
難読化か。難読化なら確かにラッピングは必要かもしれんが
internalなViewModelじゃだめなん？
125デフォルトの名無しさん2012/06/09(土) 22:58:26.63
ラムダ式からプロパティ名を取り出す方法なら難読化できるよ
1261252012/06/09(土) 23:02:50.05
ああXAMLには影響が出るから無理か
インターフェイスが曝されるだけなら別によくない?
VMでラップしまくるのも大差ないと思うが
127デフォルトの名無しさん2012/06/10(日) 02:20:40.65
まあ全部ラッピングしたらしたでやっぱり中身の名前はそのまま出てくるわけだしな
それなら直接Model繋げた方がいい
128デフォルトの名無しさん2012/06/10(日) 19:31:10.74
129デフォルトの名無しさん2012/06/10(日) 19:42:58.13
世の中にはコードビハインドというものがあってだな
130デフォルトの名無しさん2012/06/10(日) 20:08:46.96
コードで書くかと、コードをどこに書くかは全然違う話であってだな
131デフォルトの名無しさん2012/06/10(日) 20:22:58.07
ところでVS2012のデザイナはBlendベースで刷新されて前と比べ物にならないくらい良くなってるぞ
アニメーションやテンプレートやリソースの編集にはBlendがまだ必要だけど
MVVMのV作るときにはそろそろBlendいらないと思う
132デフォルトの名無しさん2012/06/11(月) 07:53:21.15
133デフォルトの名無しさん2012/06/11(月) 09:04:31.43
コマンドもバインディングできて、シンプルなテンプレートも付いてるのはいいな。
なかなか使いやすそうな感じだね。これは確かにMVVMだ。
質問とかだったらWeb制作板のライブラリ質問スレが適当かな。
134デフォルトの名無しさん2012/06/11(月) 09:12:27.73
WebはWebでもJSはクライアント側でUIを扱うからMVVMなんだな
135デフォルトの名無しさん2012/06/12(火) 01:28:10.49
VS2012になると ビュー モデルは Portable Library でサポートされるそうだ、VM と M は可能な限り Portable Library に押し込んでマルチプラットフォーム化を目指せるのか。
136デフォルトの名無しさん2012/06/12(火) 02:06:46.27
VMが厚くなるな
137デフォルトの名無しさん2012/06/12(火) 02:23:38.61
MetroとWPFでVM使い回しはきついだろ
ギャップが大きすぎるから、大量のコードビハインドでVMを相当抽象化することになるか
互換性のためにどっちつかずでプラットフォームの空気を読まない不自然なUIになりそう
138デフォルトの名無しさん2012/06/12(火) 07:04:36.86
Portable Libraryは別に良いんだけど、別にVMのマルチプラットフォーム対応を目指す必要は無いと思うんだよね。
使用するビューのテクノロジーやデバイスが異なればVMに求められる構造だって変わってくるし。
WebのMVCでPCサイトとモバイルサイトで同じControllerを使う、程度には面倒で制約が多い気がする。
むしろマルチプラットフォーム化できるんならしたいのはMじゃね？
139デフォルトの名無しさん2012/06/12(火) 12:49:34.16
Livet で、Winodws.Loaded 時にコマンド発行させたいんだが、どうすればいいの？
WindowAction みたいなので、コマンドを発行するだけの Action があればいいだんけど、
見つからなかった。
自分で作るしかない？
140デフォルトの名無しさん2012/06/12(火) 13:12:31.77
>>139
i:EventTrigger
i:InvokeCommandAction 141デフォルトの名無しさん2012/06/12(火) 16:51:30.23
Portable Library に Model を押し込む努力はするべきだ。
Portable Library に押し込むには ViewModel は View にプロパティを提供するだけにせざる負えない。
と書いてどっかで聞いたなと思ったら。 MVPVMパターンあった。
Portable Library に ViewModel と Model を押し込んで View と Presennter をプラットフォーム依存にするのか。
142デフォルトの名無しさん2012/06/12(火) 17:21:46.72
で、そのPresenterってコードビハインドじゃん、ってなった
143デフォルトの名無しさん2012/06/12(火) 18:36:18.33
状況によってはPresenter設けてもいいと思う
Viewのサイズや表示位置、グリッドのソート順や列の表示・非表示等を構成ファイルに保存/読み込みさせるのに独立したPresenter設けても可
144デフォルトの名無しさん2012/06/12(火) 20:43:19.56
Presenterの役割定義が昔に比べて広いものを指すようになってきている気がするのは俺だけ？
IHogeViewを実装しているビューなら、それがWPFだろうがWindows FormsだろうがConsoleアプリだろうが、
HogePresenterから操作できる、みたいなのがMVPのイメージだったんだけど、
コードを書く = Presenterな使われ方が増えている気がするんだけど、MVPってそういうものだったの？
ビュー間にまたがるものやアプリケーション横断的な処理の記述箇所については、
Presenterといわずに別の定義をした方が良いんじゃねと思ったんだけど。
1451392012/06/12(火) 22:17:28.41
>>140
ありがとう。
Livet 関係なくできたのか、
ぐぐっても出ないわけだ・・・。 146デフォルトの名無しさん2012/06/13(水) 02:37:56.25
>>142
V->VMが密結合にならないのがコードビハインドとは違うところ
実際やるかどうかは別にしてVMの差し替えが可能 147デフォルトの名無しさん2012/06/13(水) 10:57:45.00
NVPVMはあくまでMVVMの派生パターン
特殊なコンポーネント使っててViewの負荷が異常に高い場合、有効なパターンだよ
148デフォルトの名無しさん2012/06/13(水) 12:44:02.37
じゃぁViewにプロパティを提供する入力検証の一部をする以外の、
VMでやっていることを考えてみよう。
非常にめんどくさいコーディングスタイルのコントローラじゃないのか？
149デフォルトの名無しさん2012/06/13(水) 13:12:22.81
それでいいんだろ
一つのViewを異なる使い方で使いまわすときに
VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
150デフォルトの名無しさん2012/06/13(水) 13:19:04.84
>>149
> 一つのViewを異なる使い方で使いまわすときに
> VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
え？
一つのViewModelを異なるアーキテクチャで使いまわすときに
Viewごと入れ替えるのは無駄が多いから
の間違いじゃね？ 151デフォルトの名無しさん2012/06/13(水) 13:21:02.28
MVPVMのサンプルも、VM−Mのコンビは汎用性持たせ、Pで差分吸収するサンプルに思えたが
152デフォルトの名無しさん2012/06/13(水) 13:26:43.72
両方だろ
VがVM、VMとビジネスロジックがそれぞれ密結合しないことでVとVMの再利用性を高めるのがねらい
153デフォルトの名無しさん2012/06/13(水) 13:30:43.53
154デフォルトの名無しさん2012/06/13(水) 13:37:22.90
2chの煽りと変わらんだろw
ugayaはこういう説明の仕方を見習うべき
www.global-webnet.net/blogengine/post/2010/02/05/MVPVM-Model-View-Presenter-View-Model-the-natural-evolution.aspx
155デフォルトの名無しさん2012/06/13(水) 13:40:07.82
VがVMに密結合してしまってるのが問題だといってたぞ。
U氏も遷移を切り離すならしっくりくると書いてある。
VMから遷移を切り離したら何が残るの？
Viewにプロパティを提供する入力検証の一部をする位じゃないの？
156デフォルトの名無しさん2012/06/13(水) 13:46:36.47
>>155
VがVMに密結合するのはコードビハインドな
それをPに切り出してPを差し替え可能にしてるから密結合しない 157デフォルトの名無しさん2012/06/13(水) 13:47:19.86
Viewで相互運用使うならMVPVM有りとの話もあるが、実際作業するとコードビハインドしか逃げようがないんだよなぁ〜
158デフォルトの名無しさん2012/06/13(水) 13:49:10.29
コードビハインドってPじゃねえの？
159デフォルトの名無しさん2012/06/13(水) 15:20:15.29
質問。
VMの第一の目的って、Mの構造をVでバインディングしやすい形に変換した形で持つ事っていうのであってる？
例えば、DBの2次元表の構造を、複雑なViewにバインディングするためLINQで変換する、とか。
なので、Mの構造そのままを表示するようなVだと、VMは単純なラッパに見えてしまう。
160デフォルトの名無しさん2012/06/13(水) 15:27:06.16
Mの構造そのまま表示できる場合においてはVMは不要
161デフォルトの名無しさん2012/06/13(水) 15:45:57.26
実際に作ってみりゃわかるけど
純粋にＭのプロパティだけでインターフェースは作れない
タブやエキスパンダの状態とか環境設定とかの話ね
めんどくせぇから全部詰め込むってのもありだけど
無駄に一緒にするのは保守性を悪くする
どうせそこらへんはほとんどラッパなんだから
書くのがめんどくさい部分は全部Ｔ４使えとＴ４
162デフォルトの名無しさん2012/06/13(水) 15:51:40.10
T4使いづらいって印象しかないんだが、なんか間違ってる？
163デフォルトの名無しさん2012/06/13(水) 15:57:40.49
外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ
複数ファイルの処理が面倒なのはわかるが
164デフォルトの名無しさん2012/06/13(水) 16:36:31.97
165デフォルトの名無しさん2012/06/13(水) 17:01:14.95
どうもこうも
ViewModelBase<T>から派生してたら
partialでTのプロパティを全部ラップしてやればいいのさ
簡単だろ？
Ｔ４で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら
調べろとしかいいようがないが
166デフォルトの名無しさん2012/06/13(水) 17:10:39.16
リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね
167デフォルトの名無しさん2012/06/13(水) 17:23:42.40
> Ｔ４で自分のプロジェクトからリフレクション
このあたりは、みんなどの方法を採用してる気か聞いてみたいね。
俺はWPFのコンパイルプロセスを見習って、
自分自身を一度ビルドしてからCecilでアセンブリにアクセスしてる。
他にも
Cecilではなく普通のリフレクションAPIを使ったり、
ビルドせずにRoslynやNRefactoryを使ったりという方法もあるけど
こっちを使ってる人もいるのかな？
168デフォルトの名無しさん2012/06/13(水) 17:36:11.05
>>166
アセンブリがアンロードできない・・・と来れば、あとはわかるな？
そう、AppDomainの出番だ。 169デフォルトの名無しさん2012/06/13(水) 17:39:54.72
>>168
おい、やめろ
AppDomain芸をよりにもよってT4でとか地獄過ぎる
RoslynはまだCTPだしT4上で現実的なところで言えばCecilだろうな
コード生成じゃなくてポストプロセスでのIL書き換えでよければPostSharpなんかも選択肢に入るが 170デフォルトの名無しさん2012/06/13(水) 18:07:49.37
うん、AppDomainは無い
まだ別プロセスを起動した方がマシ
171デフォルトの名無しさん2012/06/13(水) 20:42:48.42
PostSharpとか使ってやるのがお手軽？
自前でTaskを作ってビルドプロセスに追加する方が良い？
172デフォルトの名無しさん2012/06/13(水) 21:09:57.27
一番手軽なのは某氏のDSL
173デフォルトの名無しさん2012/06/13(水) 21:11:07.57
Castle.DynamicProxyでいいわ
コード生成だるい
174デフォルトの名無しさん2012/06/13(水) 23:33:29.53
>>172
えむなうさんの？あれってC#専用だよね？ 175デフォルトの名無しさん2012/06/13(水) 23:47:53.09
T4使ったら、少なくともテンプレートのコードが
コンパイルされた結果のアセンブリはロードされるはずだろ
だからもともと別AppDomainで実行されるようになってるから
普通にロードして問題ないんじゃないの?
176デフォルトの名無しさん2012/06/13(水) 23:50:14.79
>>174
VB.NETやF#とか茨の道だし、C#で普通に使えれば問題ないだろ？ 177デフォルトの名無しさん2012/06/13(水) 23:51:37.83
必要ならVB作れってCodePlexかBlogでリクエストすればいい。
まさかJavaScriptやF#じゃないよな。
178デフォルトの名無しさん2012/06/14(木) 00:07:25.99
リフレクションでやるんならわかるけど、いちいちDSLでプロパティ定義するんだったら
public virtual int Hoge { get; set; }
としといてCastleのDynamicProxyで変更通知を自動実装させればいいと思うよ
179デフォルトの名無しさん2012/06/14(木) 00:14:39.91
>>176
VB.NETは茨の道でもなんでもないんだが？ 180デフォルトの名無しさん2012/06/14(木) 00:16:41.28
>>178
プロパティ追加・Hoge・int の3ステップでできる。
赤シャツの嫌いなAOPで実装することもあるまい。
181デフォルトの名無しさん2012/06/14(木) 01:42:25.17
VB続けたい奴がXAMLに手を付けるのが不思議だわ
182デフォルトの名無しさん2012/06/14(木) 08:06:59.93
>>181
それは偏見。いまのVBはC#と比べて大差ない程機能強化されとる 183デフォルトの名無しさん2012/06/14(木) 09:14:33.85
>>176
むしろすべてF#で作りたいんだが。
VMまではF#でやってる。 184デフォルトの名無しさん2012/06/14(木) 13:20:58.33
MS自身はVBにも力を入れてるけど、周りが付いてきていない。
サンプルがC#でのみ提供ってのもよく見るし、
MonoはVBコンパイラを非サポートにしつつあるし。
185デフォルトの名無しさん2012/06/14(木) 13:24:58.84
F#は面白そうだね。
計算式で上手くリアクティブプログラミングができたら
相当VMが作りやすくなりそうな予感がする。
けど、茨の道には違いないだろう。
IDEの支援は弱いし、ライブラリの中にはC#の文法で使うことが前提のようなものもあるし。
186デフォルトの名無しさん2012/06/14(木) 20:01:18.03
VBにいくら機能を追加しても言語仕様が腐ってるから駄目だよ
それにどうせ新機能が増えるたびに「冗長な予約語導入→C#より利便性が下がる」って悪循環でしょ
187デフォルトの名無しさん2012/06/15(金) 01:35:08.89
VBのラムダ式とか狂った文法だし、機能面だけはC#と対等にしてるけど、もはやボロボロでしょ
188デフォルトの名無しさん2012/06/15(金) 10:44:01.68
言語がどうの以前に、MVVM的インフラとして
他人のコードが重要になるから少数派は厳しい
189デフォルトの名無しさん2012/06/15(金) 11:55:14.41
>>186
予約語増えるたびIDEが支援強化するからあまり不便に感じないのも事実
XAML開発の場合、IDEがどれだけその言語をサポートしているかが最重要
そういう意味でF#は終わってるとしかいいようがない 190デフォルトの名無しさん2012/06/15(金) 13:19:16.42
VBはVB2005のように、厨言語と呼ばれてもいいから
VBらしさを重視していた頃のほうが健全だった
C#のクローンに成り下がったVBに存在意義はもう無い
191デフォルトの名無しさん2012/06/15(金) 13:53:34.63
>C#のクローンに成り下がったVBに存在意義はもう無い
そんなことばかり言うからC#厨は嫌われるんだよ
おまえが存在意義感じなくても俺には必要なの！引っこんでろタコ！
192デフォルトの名無しさん2012/06/15(金) 13:55:47.35
VBはクラシックVBとの互換性を維持したいのかしたくないのかよくわからないはじまり方をしたのが最大の失敗だったな
せっかくのしがらみを捨てる最大のチャンスを逃してしまった
193デフォルトの名無しさん2012/06/15(金) 13:56:55.90
>>191
でもまぁ今から.Net始める場合はVB.NetじゃなくてC#選ぶんちゃう？ 194デフォルトの名無しさん2012/06/15(金) 13:59:50.60
>>192
言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい
とはいえVB６との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない 195デフォルトの名無しさん2012/06/15(金) 14:00:50.13
>>193
VB.NETに移行する案件、山ほどあるんだが 196デフォルトの名無しさん2012/06/15(金) 14:37:26.30
VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな
197デフォルトの名無しさん2012/06/15(金) 14:51:15.90
>>196
でしょｗ でも変にForms覚えてる奴より
「こ れ が .NET じ ゃ 定 番 だ か ら」
と言えば、素直に話を聞いてくれるのから嬉しい 198デフォルトの名無しさん2012/06/15(金) 14:59:21.72
Forms直に行ってデフォルトインスタンス触られるよりいいのか
199デフォルトの名無しさん2012/06/15(金) 15:15:25.52
>>194
開発に使う分には問題ないが、言語チームがかなり苦労してそうなのが構文とかからにじみ出てくるぜ・・・ 200デフォルトの名無しさん2012/06/16(土) 04:16:43.61
201デフォルトの名無しさん2012/06/16(土) 12:32:05.90
実はMVVMってしっくりこないんです！
わたしはこれまで、C/C++、Visual Basic、最近になって Java、C# などの言語を使ってきた。
「自分でViewModelを作ってMVVMっぽいことをしている」なんてことはまったくない。
特に「Visual Studioでポトペタ開発ができる」ということ知ってからは、従来のVB6のように開発している。
共有変数も、pubulic staticで宣言する。したがってプロパティなんて作らない。
自称上級者のコードを見ると、いちいちM・V・VMのクラス分けをしているので笑ってしまう。
データベースにアクセスするアプリケーションをを書いているのだが、Visual Studioが供給している
機能を使えばMVVMなど使わなくてもできてしまうのだから。
202デフォルトの名無しさん2012/06/16(土) 12:40:31.71
なにおじさん？
203デフォルトの名無しさん2012/06/16(土) 13:20:33.52
何のコピペだっけそれ
204デフォルトの名無しさん2012/06/16(土) 14:14:46.22
懐かしいなｗ
205デフォルトの名無しさん2012/06/16(土) 17:03:22.48
オブジェクト指向か
206デフォルトの名無しさん2012/06/16(土) 17:52:59.93
VMのコストが高いのは事実
207デフォルトの名無しさん2012/06/16(土) 23:27:28.75
Livet で Drag and Drop やりたいんだけど、どこかにサンプルないですか？
208デフォルトの名無しさん2012/06/17(日) 11:27:52.39
時間の無駄だと思わないの?
お前がMVVM教の修験者か何かでないならコードビハインドを使え
209デフォルトの名無しさん2012/06/17(日) 14:45:06.19
210デフォルトの名無しさん2012/06/17(日) 16:08:05.74
イベントだけ拾っても仕方ないでしょ
素直にコードビハインドを書くか、
Dropイベントを受け取って引数にデータ入れてバインドしたVMのコマンドを呼ぶ
ビヘイビアを作りましょう
211デフォルトの名無しさん2012/06/21(木) 18:57:52.75
MVVMって誰が提唱しだしたの？
212デフォルトの名無しさん2012/06/21(木) 19:34:30.00
MSの中の人
213デフォルトの名無しさん2012/06/21(木) 19:36:38.56
ビヘイビアに書くと再利用性が上がるってだけで中身はコードビハインドと大して変わらんしな
まあD&Dはどっちにしても面倒だが
214デフォルトの名無しさん2012/06/21(木) 22:54:05.30
コードビハインド書くと、VからVMアクセスするでしょ？
それがかっこ悪いのよね〜
215デフォルトの名無しさん2012/06/22(金) 23:26:34.40
VからVMにアクセスするのはコマンドも一緒だと思うが…
216デフォルトの名無しさん2012/06/23(土) 07:54:12.87
つーかほぼすべてVからVMへのアクセスだろが。
217デフォルトの名無しさん2012/06/23(土) 09:25:51.09
VMはVを知らないがVはVMを知っている
218デフォルトの名無しさん2012/06/23(土) 11:10:17.65
こんにちは！VMさん。
あなたは、Vさんにフォローされてます。
Vさんをフォローしますか？
する
→しない
219デフォルトの名無しさん2012/06/23(土) 11:29:14.41
MVCのCとMVVMのVMって何が違うの？
データを扱うMと画面を扱うVがいて、それらを制御するCでしょ？
VMもCもいっしょじゃん。
220デフォルトの名無しさん2012/06/23(土) 15:06:23.66
>>219
ASP.NET MVCを想像してみろよ
あれはCとVMの両方を持つが、どう見ても同じものじゃないだろ 221デフォルトの名無しさん2012/06/23(土) 15:13:22.96
>>220
それが理解できていれば聞かずに済んでいるんだ、無能ですまん。 222デフォルトの名無しさん2012/06/23(土) 15:30:26.15
VMってのは、Vから扱いやすいインターフェイスを備えたMのラッパーだよ
Vを制御したりなんかしない
223デフォルトの名無しさん2012/06/23(土) 15:57:05.63
Vを制御するのは誰？
簡単な話、Viewにある文字をModelでなんかした結果で変えたいみたいな。
224デフォルトの名無しさん2012/06/23(土) 16:02:41.88
V自身がバインディングで変える
225デフォルトの名無しさん2012/06/23(土) 19:19:17.03
MVCだとVは入力を扱わない
226デフォルトの名無しさん2012/06/24(日) 17:03:07.28
Mの状態でフォーカス位置を変えたりするのがめんどい
227デフォルトの名無しさん2012/06/24(日) 17:04:30.15
SとMの関係を一言で言うと？
228デフォルトの名無しさん2012/06/24(日) 18:36:15.75
rot(M, -π) = S
229デフォルトの名無しさん2012/06/24(日) 21:45:32.65
Vを制御するのはVMだろ
Vの状態を持つためのMなんだから
230デフォルトの名無しさん2012/06/25(月) 14:05:28.44
VMがVを制御しないんならVを制御する別のオブジェクトが必要だな
そうだなープレゼンターとかいう名前にするといいんじゃね？
231デフォルトの名無しさん2012/06/25(月) 15:04:10.95
232デフォルトの名無しさん2012/06/25(月) 18:19:46.52
Mのプロパティをラップすることがあるのは、MVVM関係なく、隣人とだけ話せっていうOOPの作法だよな
MVVM的には別にどっちでもよくて、やっぱりVMの本質はVの状態を持つことだよ
233デフォルトの名無しさん2012/06/25(月) 22:39:40.76
従来のウェブアプリ（Ajaxアプリ除く）、
ウェブフレームワークといったらいいかな？
で、MVVMを使うメリットある？
234デフォルトの名無しさん2012/06/25(月) 22:50:54.35
JSのか？
235デフォルトの名無しさん2012/06/25(月) 22:54:54.79
JS関係なくて、普通のフォーム使った
ウェブアプリ。
236デフォルトの名無しさん2012/06/26(火) 00:01:38.39
数ある既存の素晴らしいMVC系フレームワーク(あくまでWebでいうMVCね)
に乗せられるというメリットを捨ててまで使うほどのメリットは無いと思う
237デフォルトの名無しさん2012/06/26(火) 00:15:01.78
ASP.NET MVCにはViewModelと呼ばれるものがあるけど
ステートレスでただVと1対1なだけのデータの入れ物だからMVVMとは別物だと思う
238デフォルトの名無しさん2012/06/26(火) 00:17:39.51
MVVMはVが入力を扱う場合において威力を発揮する
WebのサーバサイドだとVは入力を扱わないし、MVCはVではなくCが入力を扱う
239デフォルトの名無しさん2012/06/26(火) 00:20:17.19
あと選択状態とかだろ
ステートレスなVMはただのMだ
240デフォルトの名無しさん2012/06/26(火) 00:41:58.72
そもそもウェブアプリってMVCじゃないだろ？
データとってきてテンプレートに入れるだけじゃん。
241デフォルトの名無しさん2012/06/26(火) 19:38:03.37
何を突然スレ違いなことを
242デフォルトの名無しさん2012/06/26(火) 20:46:48.60
>>233でウェブアプリの話してるじゃん。
ちゃんと読まないでレスするの良くないよ。 243デフォルトの名無しさん2012/06/26(火) 20:53:00.50
ここはMVCのスレではないし、クライアントとWebのMVCが同一だと言ってる奴も居ないけど
244デフォルトの名無しさん2012/06/26(火) 20:57:02.48
このスレの1/10には
MVCという単語が含まれているが？
MVCのスレじゃなくても
MVCと比較するのだからなんの問題もないだろ。
245デフォルトの名無しさん2012/06/28(木) 18:23:25.38
コミュ障って生きていくの大変そうだな。
246デフォルトの名無しさん2012/06/29(金) 00:08:52.57
そうだな。そういうことにしておけば？
247デフォルトの名無しさん2012/06/29(金) 14:32:07.81
そこはもちょっと親身に相談に乗ってあげなきゃ
245が自殺でもしたら大変だろ
248デフォルトの名無しさん2012/06/29(金) 15:32:22.10
ちょっと死にたい
249デフォルトの名無しさん2012/06/29(金) 16:26:05.86
コードビハインドさえ書かなければ死なない
250デフォルトの名無しさん2012/06/29(金) 17:17:54.12
いや、別に責務さえはっきりしていれば、別にコードビハインド書いてもいいんだよ。
MVVM≠コードビハインドはよくある誤解なので、ご注意を。
251デフォルトの名無しさん2012/06/29(金) 20:05:40.23
252デフォルトの名無しさん2012/07/01(日) 09:58:01.85
LivetってPrismにあるようなナビゲーションスタイルのアプリケーションには対応してないよね
アホみたいに時間かかってる割には全体的に…
253デフォルトの名無しさん2012/07/01(日) 10:29:40.96
お前は何を言っているんだ
254デフォルトの名無しさん2012/07/01(日) 10:44:49.81
>>253
ウインドウ内で画面遷移するやつ(PrismのRegionみたいなの)
できるなら教えてほしい 255デフォルトの名無しさん2012/07/02(月) 02:00:05.07
個人製作のフレームワークがごく限られたケースにしか対応してないのはよくあること
配慮してくれないと
256デフォルトの名無しさん2012/07/02(月) 17:16:37.30
ContentControlでも使ってろ
257デフォルトの名無しさん2012/07/04(水) 01:06:26.25
Livetの中の人、ついったーがキモい・・・
258デフォルトの名無しさん2012/07/04(水) 01:21:34.90
259デフォルトの名無しさん2012/07/04(水) 10:36:51.30
260デフォルトの名無しさん2012/07/04(水) 15:31:22.65
いやなら反論してみればいいんじゃね
261デフォルトの名無しさん2012/07/04(水) 15:43:14.21
例の人は目先の細かい実装に囚われすぎなんだよ
>>154で説明されているような
・VMをビジネスロジックに依存させないことによるVMの再利用性の向上
・VをVMに依存させない(つまりVMを直接触るようなコードビハインドを書かない)ことによるVの再利用性の向上
・Pは差し替え可能
・DIとの相性
と言ったことに全く触れられていない 262デフォルトの名無しさん2012/07/04(水) 15:56:30.88
直接言って来いよ
ここでやんな
263デフォルトの名無しさん2012/07/04(水) 18:25:12.71
技術的な話はここでいいだろ。
性格批判は向こうでどうぞ。
264デフォルトの名無しさん2012/07/04(水) 18:36:48.98
そうそう、そのためのスレなんだから
MVPVMのサンプル見ると、三つのプラットホームでVMを共通化してる
VとVMの疎結合のためにPを設けてるわけだが、
現実的に考えると、VMの共通化を図る要件って実際あり得るのだろうか？
265デフォルトの名無しさん2012/07/04(水) 18:44:57.68
>>154のリンク先の例にあるような、同じV-VMペアを別の用途で使いまわすっていうのは
割とあるんじゃないかと思う 266デフォルトの名無しさん2012/07/04(水) 19:12:57.94
VMの共通化は無い派。
デバイスが変われば見た目も変えたくなるし、全てのデバイスで使えるスーパーセットのVMもどうかと思う。
Mが可能な限り共有できればそれでよいと思う。
267デフォルトの名無しさん2012/07/04(水) 19:25:18.53
要件によるけど、スーパーセットのVM使えるところも多々あるんじゃない？
使えないところだけVMを個別作るとかが望ましいなぁ
268デフォルトの名無しさん2012/07/04(水) 19:42:38.71
最近客に「文字大きくしてくれ」って言われてVだけコピペしたよ
269デフォルトの名無しさん2012/07/04(水) 22:00:23.71
ねぇ。これがどうウェブアプリに使えるの？
270デフォルトの名無しさん2012/07/04(水) 22:17:08.46
ステートフルなGUIを作るためのものだからサーバーがHTML吐くだけのアプリには無意味
SilverlightやAjaxなら普通に使える
271デフォルトの名無しさん2012/07/04(水) 23:22:11.82
うがやって彼女いるの？
24時間キモイことつぶやいてるよね 。
さっきも、アスペルガー丸出しだった。
彼女どころか友達いなそう。
272デフォルトの名無しさん2012/07/04(水) 23:38:25.94
個人攻撃に走るのはいかがなものか。
273デフォルトの名無しさん2012/07/05(木) 00:22:46.48
>>272
今Twitter見てみ？
完全にアスペだぜ？ 274デフォルトの名無しさん2012/07/05(木) 01:34:01.44
何言ってるのかはみてないが24/7ではなかったな
日付が飛んでたから
275デフォルトの名無しさん2012/07/05(木) 01:42:41.83
技術的な突込みならともかく、スレに関係ない話で個人攻撃はいくない
276デフォルトの名無しさん2012/07/05(木) 07:05:45.91
個人の話がしたければヲチ板へ。
アスペの話がしたければメンヘラ板へ。
277デフォルトの名無しさん2012/07/05(木) 07:37:21.07
ウガヤ氏に罵倒された勘違いMVVMerなんですね。わかります(´・ω・｀)
278デフォルトの名無しさん2012/07/05(木) 15:11:50.77
あれも２ちゃんでの話に文句があるなら２ちゃんでいえばいいのにな
279デフォルトの名無しさん2012/07/05(木) 19:40:28.20
煽り耐性ゼロだから2ch無理とか言ってたけど
正直あのエントリに比べたらここやWPFスレの方がマイルドw
280デフォルトの名無しさん2012/07/05(木) 20:43:53.52
いやさすがにそれはない
281デフォルトの名無しさん2012/07/05(木) 20:46:14.32
ム板は煽られても他人の振りが出来るからなあ
282デフォルトの名無しさん2012/07/05(木) 21:23:08.74
ここってJavaFXの話題もあり？
283デフォルトの名無しさん2012/07/05(木) 22:08:33.80
ありじゃね
284デフォルトの名無しさん2012/07/05(木) 22:53:24.29
JavaFXが最初に世に出た当時はなんでXMLじゃなくてわざわざ独自スクリプトなんだ
ボケカスと言われてたが、デザイナとプログラマの分業なんて幻想であって
ある程度ビューに振る舞い書けた方が便利だということを見越した判断だったんだな
XAMLのビヘイビア地獄よりははるかにマシだわ
285デフォルトの名無しさん2012/07/05(木) 22:57:52.73
今FXやるぐらいならSLでいいわ
286デフォルトの名無しさん2012/07/05(木) 23:14:34.76
ビヘイビア地獄ってなんだよ
そんなに地獄に感じるならコードビハインドにコード書いたっていいんだぞ
287デフォルトの名無しさん2012/07/06(金) 00:55:22.61
.triggerを手で書くのはうぜぇっていうのは同意するが
あれはblendで書く物だろ
288デフォルトの名無しさん2012/07/06(金) 01:54:31.30
ビヘイビアもトリガーもｲﾝﾌﾗが整った環境じゃないとまともに使えん
自力で整えようとすると相応の労力が強いられる
遊びや自己学習でする分には良いけど、サクッと作りたいときや仕事だと２の足を踏むなー
Blendみたいな環境が無いと本気で使おうとは思わない
コードビハインドでもMVVM自体は可能だから手っ取り早く作りたいときはコードビハインドで良いだろ
289デフォルトの名無しさん2012/07/12(木) 00:19:31.36
MVVMってプラガブルMVC劣化させたのと同じじゃねぇの？
プラガブルMVC劣化版と何が違うの？
290デフォルトの名無しさん2012/07/12(木) 00:36:47.13
XAMLのこと知らないなら黙ってろ
291デフォルトの名無しさん2012/07/12(木) 10:06:32.25
非同期処理ってモデルでSynchronizationContextとか使って面倒見たほうがいい?
それともやっぱりモデルの状態が複雑になるのは避けてVMでスレッド動かす?
292デフォルトの名無しさん2012/07/12(木) 10:13:46.36
ポリシー次第じゃない？
モデルまではそのへんを気にせずガンガン使う→VMで考慮
VMはシンプルに作りたい→上で考慮
自分は前者だな。
293デフォルトの名無しさん2012/07/12(木) 18:25:57.29
モデルで非同期してVMではメインスレッドが普通じゃない？
ViewからVM呼ぶんだし
294デフォルトの名無しさん2012/07/12(木) 18:51:53.23
UIにアクセスするとことか内部の状態を変えるとかだけVMでContextで同期取ればいいやん
295デフォルトの名無しさん2012/07/19(木) 21:22:47.22
DIコンテナは何がいい?
UnityとNinjectとAutofac試してAutofacが気に入ったんだけど
296デフォルトの名無しさん2012/07/21(土) 17:29:43.89
297デフォルトの名無しさん2012/07/24(火) 05:21:39.59
Livetの新しいの公開されたけど、これ、
旧バージョンインストールして作ってたアプリある場合、
新しいLivet入れても問題ないのかな?
旧バージョンのままじゃないと動かなくなるとかだと困る
298デフォルトの名無しさん2012/07/24(火) 06:12:23.43
Livetのプロジェクトテンプレート使ったんならLivet.dllのローカルコピーがあるべ。
299デフォルトの名無しさん2012/07/24(火) 06:28:21.45
それだと古い方のdllも残しておかないといけないってこと?
新しい方に差し替えたらそのまま動かないのかな…
新しいPCにVisualStudioとLivetの新しいのだけ入れたら、
旧バージョンで作ったアプリの修正とかはできなくなる?
上書きインストールしていいのかとか、
そこら辺、公式サイトに何も書いてないから怖くて入れられない
300デフォルトの名無しさん2012/07/24(火) 08:16:05.78
301デフォルトの名無しさん2012/07/24(火) 08:39:50.00
Livetのテンプレート使って作ったプロジェクトならInfrastructureAssembliesフォルダにいままでのLivet.dllはそのままあるし
参照設定もそれを参照しているから自分で明示的に置き換えない限り新しいバージョンのLivetを入れてもそいつのバージョンはそのまま
自分でProgram FilesにあるLivet.dllに参照設定してたらアップデートしたらアップデートしたバージョンのものになる
また新しいものに差し替えたとしても破壊的変更があるものはそのままでは動かないし、特定バージョン参照してたらたとえ破壊的変更がなくともリビルドが必要
Livetに限らずライブラリ使うときの基本的なことだと思うが
302デフォルトの名無しさん2012/07/24(火) 10:53:05.83
>>300
諸般の事情で直接連絡したくない場合もあるんだよ
そのための2chだろうが 303デフォルトの名無しさん2012/07/24(火) 13:52:17.88
んなわけねーだろ
捨てアカで報告してこい
304デフォルトの名無しさん2012/08/08(水) 10:33:09.91
MVVMerなら即VS2012にするよな？
305デフォルトの名無しさん2012/08/08(水) 10:47:52.07
それはあんまり関係ないな
306デフォルトの名無しさん2012/08/08(水) 19:08:07.03
MVVMerとかフルMVVMとか、日本だけの造語が目立つな
307デフォルトの名無しさん2012/08/08(水) 19:16:36.34
2012というか.NET4.5だとXP切り捨てになるのが
308デフォルトの名無しさん2012/08/08(水) 19:20:24.35
>>307
です。
VB6ランタイムはWin8でも動くと言うのに酷い話だ。 309デフォルトの名無しさん2012/08/08(水) 19:33:31.78
MVVMはWindows7以降用技術です
310デフォルトの名無しさん2012/08/08(水) 23:10:28.72
311デフォルトの名無しさん2012/08/10(金) 00:03:20.35
Win8でも動作するし、VB6でのMVVMまだ？
312デフォルトの名無しさん2012/08/10(金) 00:29:56.78
パターンにまだ？って言われても
自分でやることじゃねーのか
313デフォルトの名無しさん2012/08/10(金) 00:44:36.96
vb6でも普通にMVVMできるだろう
Observerやビヘイビア作るのが難儀な気がするからコードビハインド主体になりそうだけど
314デフォルトの名無しさん2012/08/10(金) 10:33:45.16
おまいら、なにか根本的に勘違いしてるだろ
315デフォルトの名無しさん2012/08/10(金) 12:38:35.91
誰に言ってんの
何を言ってんの
316デフォルトの名無しさん2012/08/10(金) 13:57:56.40
MVVMの定義に相当するものはVB6ではできんだろ。
MVPも厳しい。
おとなしく、モジュール分割をちゃんとした昔ながらのC/Sシステムっぽくやっていろ。
…っという話かな？
317デフォルトの名無しさん2012/08/10(金) 22:33:15.87
クラスをちゃんと定義すりゃできるだろ
ライブラリで用意されてるインフラ全部自分で作らにゃならんけど
318デフォルトの名無しさん2012/08/10(金) 22:48:20.32
VB6の仕様だけでインフラ作るのは厳しくないかね？
いや、API使ってフックレベルからやれば、そりゃ出来るだろうけど
319デフォルトの名無しさん2012/08/10(金) 22:52:44.04
MVVMのどういう場面だ？
320デフォルトの名無しさん2012/08/11(土) 01:28:16.52
VBだとクラスモジュールから
イベント送信できるんだから
MVVMは実装しやすい方法言語だよ。
321デフォルトの名無しさん2012/09/08(土) 12:02:20.04
可能性とかで語られてもな。
実際にそれを VB6 でやる気になるかい？ って話も重要だろ
322デフォルトの名無しさん2012/09/08(土) 12:30:15.15
「VB6 を やる気にならない」が正解
323デフォルトの名無しさん2012/09/08(土) 12:58:28.48
VBってまだ絶滅してないのか
何のためにMSはC#出したんだ
324デフォルトの名無しさん2012/09/08(土) 23:34:49.46
MSほど多様な製品を長期に渡ってサポートしてくれるとこは他にない。
VB6が世に出てから14年経つがWin8でも公式にサポートされた。
リプレースするにも金がかかるから動く限りは保守しながら使いたいって客は案外多いよ。
325デフォルトの名無しさん2012/09/10(月) 11:25:40.15
そういう用途ならhost側で動かなくてもVMで動いてくれりゃ充分なんだが
326デフォルトの名無しさん2012/09/21(金) 19:02:26.84
VB早く消えてなくならないかなー
MSもサクッと切ればいいのに
327デフォルトの名無しさん2012/09/21(金) 19:03:37.99
リプレースに金がかかるかもしれないが保守にも金がかかる
328デフォルトの名無しさん2012/09/21(金) 20:02:31.93
案外金が掛かった方が良いのかも知れない
払ってくれる相手なら
329デフォルトの名無しさん2012/09/21(金) 21:11:01.59
VB6からC#へのリプレースおいしいです
330デフォルトの名無しさん2012/10/06(土) 11:05:26.15
んで MVVMでアプリつくってるやついるの？？？
まじでいらねぇんだが．
331デフォルトの名無しさん2012/10/08(月) 09:21:35.40
一つの画面でいろいろやるタイプのアプリには向かないのは事実
332デフォルトの名無しさん2012/10/08(月) 19:09:14.56
一つの画面で色々やるというか、Vの作り込みの比重が多いアプリだとあんま活躍しないわな。
333デフォルトの名無しさん2012/10/08(月) 20:43:24.80
ツール類には向かんわな
せいぜい複雑なダイアログがあればそこに使う程度
334デフォルトの名無しさん2012/10/08(月) 21:26:12.25
複雑なウィンドウなら複数のコントロールに分割すればいい話じゃね
335デフォルトの名無しさん2012/10/13(土) 17:02:29.65
メモリリークする原因がわからない
336デフォルトの名無しさん2012/10/13(土) 17:08:27.07
イベント
337デフォルトの名無しさん2012/10/13(土) 19:31:26.75
>>335
メモリを使っている人がいるんじゃないかな 338デフォルトの名無しさん2012/10/14(日) 16:54:03.98
徐々にウェブの世界でも
MVVMが浸透してきたな。
MVCだけじゃ、いろいろ足りない。
339デフォルトの名無しさん2012/10/14(日) 17:05:03.26
340デフォルトの名無しさん2012/10/14(日) 20:38:40.26
>>338
Ajaxとかだるすぎ
WebはサーバーでHTMLを垂れ流すだけという低脳さが良いのに 341デフォルトの名無しさん2012/10/16(火) 00:33:06.45
>>340
テンプレート使ったこと無いの？
サーバーでテンプレートに渡す値を
値そのまま渡せばそれがAjaxになる。
サーバーサイドアプリ - テンプレート処理
なのだから、確実にAjaxの方が簡単になってる。； 342デフォルトの名無しさん2012/10/16(火) 01:04:33.51
意味がわからない
テンプレートって普通サーバーで使うもんだろ? クライアント側でテンプレート使うってこと?
それがサーバーでやるより簡単だと言える根拠は?
343デフォルトの名無しさん2012/10/16(火) 01:11:23.92
どっちも簡単だろ。
jQueryみたいなライブラリが充実してきて笑えるぐらい簡単になった。
これが難しいってム板に居られる資質がないとしか思えん。
344デフォルトの名無しさん2012/10/16(火) 18:10:03.69
>>342
サーバの負荷の関係上、サーバでテンプレートエンジン使わない方がいいとかもあるんだけど、
最近は、サーバから戻ってくるのはJSONオブジェクトとテンプレートで、クライアントでテンプレート
エンジンかましてページを生成する方が良いような気がしてるよ。基本Ajaxで。
受けとったJSONオブジェクトを元に、自力でDOMを書き換えても良いし。 345デフォルトの名無しさん2012/10/16(火) 20:40:35.72
クライアントが以前より負荷が高くなるという問題もあるけれど、
以前というのはもう十数年前だったら問題になるというレベルで
今はクライアントは十分な性能を持ってるしね。
ブラウザ自体も速くなった。
それに比べるとネットワークはまだまだ遅いわけで、
テンプレートはローカルにキャッシュしておいて
データ量を減らすほうが得策かな。
サーバー負荷も低くなるし。
これぐらいだれでも思っていることで、
普通サーバーでやるもんだろで終わってる人ってのは
何も考えてないとしか思えないけどｗ
346デフォルトの名無しさん2012/10/16(火) 20:43:20.12
一方Twitterは以前API直接たたいてJSONからDOM生成してたのが最近生成済みのhtml片を鯖から受け取るようになった
347デフォルトの名無しさん2012/10/16(火) 21:07:29.77
完全なAjaxができるならいいが、
普通そうはいかないもんな
どうせサーバーで生成しなきゃいけないならなるべくサーバーにまとめちゃった方が楽
348デフォルトの名無しさん2012/10/16(火) 21:18:45.66
どっちみちAjaxは使わないといけないんだから
クライアントにまとめちゃったほうが楽
349デフォルトの名無しさん2012/10/16(火) 21:24:48.64
Ajaxはオプションだろ
利便性のためにクライアントでAjax使ってバリデーションしたとしても、
どのみちサーバーでもやらないといけない
350デフォルトの名無しさん2012/10/16(火) 21:30:02.30
Ajaxはバリデーション以外で使うものって
わからないのか？ｗ
バリデーションなら単なるJavaScriptで良い
351デフォルトの名無しさん2012/10/16(火) 21:31:42.33
>>350
JavaScriptでもいちいちバリデーションするの？
バカ？ 352デフォルトの名無しさん2012/10/16(火) 21:32:50.76
JavaScriptでバリデーションが通ったら
サーバーでは検証せずにそのままDBに入れちゃうの?
やばくねそれ
353デフォルトの名無しさん2012/10/16(火) 21:34:43.44
話し理解できてないの？ｗ
バリデーションをAjaxで行う＝サーバーで通信して行うから、
そのバリデーションはサーバーでやってる事になるだろうって話だ。
あと、サーバーでやらないなんて一言も言ってない。
なんでこんなに文章読めないの？馬鹿なの？
354デフォルトの名無しさん2012/10/16(火) 21:36:01.79
サーバとJavaScript両方でバリデーションするの？
マジキチ？
355デフォルトの名無しさん2012/10/16(火) 21:36:16.18
>Ajaxはバリデーション以外で使うもの
>バリデーションなら単なるJavaScriptで良い
さっきと言ってることが180度違うけど
356デフォルトの名無しさん2012/10/16(火) 21:38:07.68
うーん？
> Ajaxはオプションだろ
>>349が
オプションでやるって書いてあるじゃん。
みんな最初っから、両方でやるという前提で話してるんだが。
両方でやるのは、レスポンスを早くしてユーザビリティを上げ
無駄な通信を削減するため。言わなくても常識だと思っているが。
357デフォルトの名無しさん2012/10/16(火) 21:38:54.60
>>355
そりゃ、さっき言った人俺は別人だからねｗ 358デフォルトの名無しさん2012/10/16(火) 21:40:19.92
みんなって誰？
マジキチは一人で十分なんだがｗ
359デフォルトの名無しさん2012/10/16(火) 21:40:51.87
360デフォルトの名無しさん2012/10/16(火) 21:41:02.38
ああ、別人という設定なんですね、わかります
361デフォルトの名無しさん2012/10/16(火) 21:41:14.80
鯖とJS両方で検証するだろうよ
検証はカスタム属性から自動生成でもしたらいいってかそういうのすでにある
362デフォルトの名無しさん2012/10/16(火) 21:43:13.41
一人だけ、程度の低い人が居ますね
363デフォルトの名無しさん2012/10/16(火) 21:45:12.56
364デフォルトの名無しさん2012/10/16(火) 21:58:42.34
今時Ajaxだるいと言って済ませられるような、簡単なお仕事をしているぬるま湯な環境うらやましす
コストをかけずにAjaxやJSでのMVVMをどう実現するか試行錯誤している人が多い中で
365デフォルトの名無しさん2012/10/16(火) 21:59:49.81
×今時Ajax
○いまさらAjax
366デフォルトの名無しさん2012/10/16(火) 22:12:49.60
クライアントにまとめるとか言って鯖から全件投げつけてクライアント側で検索やらせる奴とかが現れませんように
367デフォルトの名無しさん2012/10/16(火) 22:16:13.83
>>366
それはさすがに見た事ないけど
ページングせずに数万件の検索結果のレコードを送り付けてくるやつなら見た事がある。 368デフォルトの名無しさん2012/10/16(火) 22:16:48.57
そのうちJavaScriptでクラサバやるわけですね
369デフォルトの名無しさん2012/10/16(火) 22:17:15.76
node.js最強
370デフォルトの名無しさん2012/10/16(火) 22:20:02.67
>>366
ASP.NET素人だとクライアント側にViewStateで全データを保管して、サーバー側でページングとか日常茶飯事だぜ？ 371デフォルトの名無しさん2012/10/16(火) 22:22:07.06
まーた、なんか低レベルの流れになってんなー
372デフォルトの名無しさん2012/10/16(火) 22:30:55.59
下見てもつまらないよ
373デフォルトの名無しさん2012/10/17(水) 01:35:57.07
374デフォルトの名無しさん2012/10/21(日) 22:42:39.14
なんか最近尾上の言うことがぶれすぎ
先月ぐらいから少しずつさりげなくぶれ始めてたんだが
なにがあったんだ？
コードビハインドとか頭おかしくなったのか？
その内容自体は宗教だからどうでもいいが
さんざん自分の考えと違うやつを罵倒してきた人間が
そこまでころっと価値観変えてどうなんだ？
375デフォルトの名無しさん2012/10/21(日) 22:56:05.22
コードビハインドを無理に排除しようとすると、どうしても
特定のビュー専用のビヘイビアがしばしば出てくる。
その場合無駄に煩雑になるだけで実質何のメリットもない。
彼も気付いちゃったんだよ。
376デフォルトの名無しさん2012/10/22(月) 06:04:37.89
単に自分の考えが甘かった、自分の見える世界だけしか見ていなかった事に気がついただけだろ。
ああいうキャラの人間はだいたいそんなもん。
377デフォルトの名無しさん2012/10/22(月) 08:48:01.98
MVVMやっててWPFの仕組みがわかってくると、
意外とWPFのコードビハインドってよくできてることに気付くよね
正直、ビヘイビアは再利用できるものだけに限定して積極的にコードビハインド使うのがベストだと思う
378デフォルトの名無しさん2012/10/22(月) 09:20:38.69
メッセージも多くの場合Vがインターフェイスを実装すれば十分
ﾒﾓﾘﾘｰｸｶﾞｰとか言うけど、そんな大したことじゃないだろ。
参照管理の問題なんてどうせWPF関係ないところでも常に付きまとうのに、
それをコードビハインドの問題であるかのように大袈裟に騒いで、
WPFがまだよくわかってない人に変な先入観を植え付けている。
379デフォルトの名無しさん2012/10/22(月) 09:41:07.23
MVVMというより、Blend至上主義みたいな話になっちゃってるような所があったからな。
380デフォルトの名無しさん2012/10/22(月) 12:14:52.36
本人はBlendを第一に考えてるようだしその辺だろうな
381デフォルトの名無しさん2012/10/24(水) 00:05:27.67
Blend 2012まだかよ
382デフォルトの名無しさん2012/11/02(金) 12:07:46.01
ViewModelのインターフェイスって意味ある？
383デフォルトの名無しさん2012/11/02(金) 14:00:24.51
Mや各種サービスからのコールバックに使うとか
コードビハインドでVからVMのメソッドを呼ぶときにV->VMを密結合させたくないとか
そういうときには意味ある
384デフォルトの名無しさん2012/11/02(金) 14:32:57.66
まあ通常は継承ベースでいいと思う
385デフォルトの名無しさん2012/11/04(日) 22:35:06.98
>>383
コードビハインドってViewって認識なの？
否定じゃなくて単純に質問。 386デフォルトの名無しさん2012/11/04(日) 22:49:04.80
Viewとみなすのがふつう
ビヘイビアもコードビハインドの一形態なので同じくView
387デフォルトの名無しさん2012/11/05(月) 20:21:18.14
結局
vmに置かれるviewに強く関係するけど
共通ロジックの置き場がない
388デフォルトの名無しさん2012/11/05(月) 23:16:15.79
共通ロジックならUTILとかに置けばいいだろ？
389デフォルトの名無しさん2012/11/05(月) 23:36:53.45
>>386
Viewとみなすのは分かったんだけど
VMじゃななくてVとみなす理由はなんなのかな？ 390デフォルトの名無しさん2012/11/05(月) 23:38:49.26
391デフォルトの名無しさん2012/11/05(月) 23:45:04.35
>>390
WinFormsのコードビハインドなら不可分といえなくもないけど
WPFはそうともいえないんじゃね？
392デフォルトの名無しさん2012/11/05(月) 23:51:07.82
>>391
この場合の不可分は「単体テスト可能かどうか」な。
ユーザーコントロールやウィンドウのクラスに対してXAMLを差し替えることは普通はできないし
無理矢理読み込むファイルを変えたとしてもコードビハインドからコントロールを直接触ってるから
結局ビューを表示して実際に操作してみないとテストできないわけ。
だからコードをビューから分離してビューなしでテストできるようにしましょうっていうのがVM。 393デフォルトの名無しさん2012/11/06(火) 00:03:14.09
394デフォルトの名無しさん2012/11/06(火) 00:05:46.84
>>387
ViewModelsってフォルダにそういう機能のクラスを作ればええんや
まーそもそも、Views、ViewModels、Modelsってフォルダ群もなんだかなーって気もするが
そのほかのフォルダ構成でやってるやつおる？ 395デフォルトの名無しさん2012/11/06(火) 03:50:39.94
フォルダ分けない方が楽な気はするがその3つにしてるな
396デフォルトの名無しさん2012/11/06(火) 15:16:09.04
М氏も「MVVM＝コードビハインド無し」みたいな誤解撒き散らしてたし
「フルMVVM」って造語が誤解生んだのも事実
でもだからなんなの？勝手に誤解してずっこけたの本人のせいじゃん
お前が元信者だから裏切られた感強いだけだろ
397デフォルトの名無しさん2012/11/06(火) 16:34:58.61
dynamicを積極的に使うのはどうだろう
VMがdynamic型でVへの参照を保持して動的にVのメソッドを呼ぶようにすれば、
メッセージやインターフェイスを介さなくてもVM->Vの密結合が避けられる。
dynamicなら完全に透過的なプロキシが使えるから、たとえばメモリリークの恐れがある箇所は
WeakReferenceでビューへの参照を持ち、ビューがGCされたらnullオブジェクトとして振る舞う
ようなプロキシを利用すれば、メモリリークの問題もコードの見た目を全く汚さずに解決。
型無しがダメだというならメッセージだって同じようなもんだよね。
(Vが当該メッセージをサポートしているかどうかはコンパイル時にチェックされないという意味で)
398デフォルトの名無しさん2012/11/06(火) 17:03:56.14
マルチキャストが必要な場合(メモリリークを避けるためにイベントを置き換えるとき)もこんな感じで
class HogeModel {
//弱参照で複数のリスナへの参照を持つ複合プロキシ
private WeakCompositeProxy listeners;
public void AddListener(dynamic listener) { listeners.Add(listener); }
private void RaiseSomethingHappened() {
//登録された全てのリスナのOnSomethingHappenedメソッドを呼び出す
//リスナがOnSomethingHappenedメソッドを持たない場合は何もしない
((dynamic)listeners).OnSomethingHappened();
}
}
399デフォルトの名無しさん2012/11/09(金) 04:16:24.83
MVVMってメトロになってもやること変わらんの？
技術的にはあっちが本流だと思うんだけど
400デフォルトの名無しさん2012/11/09(金) 09:11:57.38
どうしてデザパタが環境によって変化すると思うんだｗ 技術じゃないぜ。概念だろ。
401デフォルトの名無しさん2012/11/09(金) 10:13:41.46
この手の概念って「ある一定の規則とか法則に名前をつける」
だけの話だからね。
402デフォルトの名無しさん2012/11/09(金) 11:31:24.11
コーディング段階は結構変わるがな
403デフォルトの名無しさん2012/11/09(金) 22:45:20.26
>>401
概念の話と
概念に名前をつけるって
話がごっちゃになってるよ。
概念に名前をつけるのは重要なことだが、
もちろん概念そのものも重要なことだぞ。 404デフォルトの名無しさん2012/11/11(日) 00:32:37.19
すいません、よかったら教えてください
MVVM Light Toolkitで遊んでるんですが、テンプレートから作成されるModelの
IDataServiceのメソッドがActionを渡して結果をコールバックさせる形になっています
普通に戻り値や例外を返せばいいと思うのですが、あえてコールバックさせているのはなぜなんでしょう？
考えても理由がちっとも思いつかないので、もしわかったらお教えください
よろしくお願いします
405デフォルトの名無しさん2012/11/11(日) 00:36:08.24
>>401
MVVM以前からMVVM的な物が存在していたということ？ 406デフォルトの名無しさん2012/11/11(日) 00:40:40.06
>>404
処理に時間がかかる場合にGUIが固まるのを防ぐためだろ
Webからデータを取ってくるような場合は言うまでもないが、
ローカルなファイルやデータベースからちょっと取ってくるくらいでも結構固まる 407デフォルトの名無しさん2012/11/11(日) 00:53:11.62
>>406
それはasync、awaitの非同期処理はModel内部で行ってServiceのメソッドをasync宣言しない方がよい
ということでしょうか？
Serviceのメソッド自体が非同期メソッドであれば画面が固まったりしないですよね？
そこら辺も初めてさわったのでトンチンカンなこと言ってたらすいません 4084062012/11/11(日) 00:56:51.28
あ、MVVM Light Toolkitは別にasync、awaitのサポート環境を限定してないからかな？
逆にいうとasync、awaitが使える環境ならば別にコールバックさせる必要はないってことでいいんでしょうか？？
409デフォルトの名無しさん2012/11/11(日) 00:57:16.17
>>407
いやMVVM Light Toolkitは結構昔からあって、当時はasyncが無かっただけ
U氏はasyncは内部で使うものであってインターフェイスに使うなとか
思い込みだけで頓珍漢なことを言ってたが
今からasync前提で作るなら普通に使っていいよ 4104062012/11/11(日) 01:01:22.02
>>409
なるほど、納得しました
サービスレベルでasyncにしてコールバックは利用しない方法でいってみます
いろいろありがとうございました 411デフォルトの名無しさん2012/11/12(月) 00:22:58.42
>>409
うがやは、C#というか言語や.NETに関して知識なさすぎだからな。
ライブラリ設計者としてのセンスもない。 412デフォルトの名無しさん2012/11/12(月) 20:04:14.60
MVVMでユーザコントロール使う場合のお作法？で質問があります
Page内に異なるユーザコントロールが2種類AとBがあります
Aはリストを表示するコントロールでBはその明細を表示するコントロールです
AとBにはそれぞれ専用のVMを作ってバインドしています
この時、A内のリストで選択されたものをBに渡したいのですがどう実装するのがスマートなんでしょうか？
現在は、PageのVMの中にAVMとBVMを保持していて、AVMのPropertyChangedイベント
をPageのVMの中で拾ってBVMのプロパティに設定しています
が・・・なんかいまいち感が
他にいいアイディアってあるのでしょうか？
413デフォルトの名無しさん2012/11/12(月) 20:12:25.87
ListBoxのItemsSourceにVMたくさん入ったコレクションセットして
ContentControlのContentか任意のViewコントロールのDataContextにListBoxのSelectedItemをバインドするのが楽じゃね
414デフォルトの名無しさん2012/11/12(月) 21:01:20.01
あぁそっか、そういうやり方があるんですね
勉強になります
ありがとうございました
もしよかったらもう一つ教えてください
実はAで選択されたItemをまた別のコントロールに今度は単一を設定するのではなくて
どんどん追加もしたいんですが・・・
そういう場合はどうするのが良いのでしょうか？
一つ一つの機能は徐々にわかってきたんですが、合わせ技になると発想がついてこないっす
415デフォルトの名無しさん2012/11/12(月) 21:01:56.33
SelectedItemは同意だけど、VM自体はPage用1つだけでいいと思う
「AB両方の表示用を子プロパティとして持つクラス」のコレクションを
VMがプロパティとして公開して、Aがそれにバインド、
BがAのSelectedItemにバインド、が一番すっきりかな
416デフォルトの名無しさん2012/11/12(月) 21:14:21.92
>>415
なるほど、そういうやり方もあるのか
そこで一つ疑問が出てきてしまったんですが・・・
WebでMVVMのユーザコントロールのサンプルをいくつか見たところ
たまたま？すべてのサンプルがユーザコントロール毎に定義されていて
それを鵜呑みにしてたんですが・・・
親になるビューだけがVMを持つのとコントロールも独自にVMを持つケース
どういった感じで使い分けたらいいのでしょうか？
ちなみに今回の場合、AもBも表示するだけではなくて、それなりに個々の
コントロールに機能を持っています
Aはソート順を変えたり絞り込んだり、Bは詳細を編集したりなどです 417デフォルトの名無しさん2012/11/12(月) 23:25:58.38
>>416
俺は複数のWindowでControl使いまわしてるから、Controlに専用のViewModel持たせてるよ 418デフォルトの名無しさん2012/11/13(火) 00:54:12.58
Model側でコレクションを持つ場合、そのVMも子ModelのVMのコレクションを持つようにしてるかな
この場合Model側もObservableCollection的な通知機能付コレクションを使うことになるが
子ModelがVM持つほどの意義がない場合は親Modelのコレクションそのまま使ったりもする
419デフォルトの名無しさん2012/11/13(火) 04:42:27.67
414は単純に、「別のコントロール」側のItemsSourceになってるコレクションに
Addしてやればいいだけだと思う…
単純過ぎるので質問の意味取り違えてるかも知れないけど
416についてはケースバイケース
どうするのが、開発や保守しやすいか。それ次第でしょう
4204142012/11/13(火) 20:36:52.73
昨日はレスいただいたのに返事できずにすみません
>>417-418
コントロールは再利用するつもりなので、今回はコントロールにVM持たせてみます
子もVMに入れてみようと思います 421デフォルトの名無しさん2012/11/13(火) 20:43:05.86
>>419
1. ItemSourceになっているコレクションに誰が値を入れるべきか？
2. ItemSourceは誰が持つべきか？
の2点で悩んでいました
Page AとBを持っている親Window
A 全てのオブジェクトをリスト表示するコントロール
B Aで選択されたものを1つずつ追加してリストに表示するコントロール
となっています。
ABはそれぞれ再利用を考えているため、個別のVMを持ち、子のVMは親のVMが持つ事としようと考えています
なので2.についてはBで持つ事にしようと思います
まだ悩んでいるのは1.でして、今のところの実装は
1) AのListのSelectedItemをAVMのプロパティにバインド
2) PageVMでAVMのPropertyChangedイベントをハンドリング
3) PageVM内のロジックでBVMで定義したAddItem（自作）を呼び出す
4) BVMのAddItemメソッドないでObservableCollectionに追加
としています。
この中の2)の部分が特にしっくりこなくて気持ち悪いというのが、質問させていただいた経緯です 422デフォルトの名無しさん2012/11/13(火) 21:27:06.52
>>421
あまり参考にならないかもですけど、
もし俺が、そういうPage,A,Bの3つのVMでやるとしたら
Aのコンストラクタの引数で、デリゲートを受け取れるようにしておく
AではPropertyChangedのハンドラで、その受け取ったデリゲート呼ぶようにしておく
PageからA,Bをインスタンス化する際に、
BのAddItemを呼び出す処理や、Pageでやるべき処理もあればまとめて、
Aのコンストラクタに全部、ラムダ式で渡す
これで後は、AのPropertyChanged内だけで、PageやBの処理も全て完結
って感じにするかな…。 423デフォルトの名無しさん2012/11/13(火) 21:40:19.58
>>422
ふむふむ、なるほど
レス読ませてもらって考えているうちに思ったんですが、AVMにItemが選択された
ことを通知するイベントを定義して、そこにラムダ式突っ込んであげれば良いのかな？
って気がしてきました
何が気持ち悪かったって、AVMにはほかにプロパティもあるわけで、PropertyChangedを
ハンドルしていると、別にPageには興味がないプロパティも飛んでくるわ
プロパティの名前をAVMで定数定義してAVMからもPageVMからも参照しようとすると、
MVVM Light ToolkitでVMのインスタンスを生成するときにエラーで落ちちゃって
プロパティ名をAとPageの双方に文字列で指定してた所なんで、一番キモイ所は解決された気がします
ただなんか手法が古臭いような気がしないでもないですがｗ
XAMLでこう書いてああ書いてすればサクっとできちゃうよ！的な解決策はさすがにないですよね？ｗ 424デフォルトの名無しさん2012/11/13(火) 23:15:36.04
@ugaya40: 難しいとかいってる人はコードビハインドでMVVMしましょ
コイツ、MVVMでコードビハインド使うのはMVVMを理解していない無能のすること とか散々ほざいてたくせしてなに言っちゃってんのって感じなんだが。
「難しいとか言ってる人」とかつけ加えてて誤魔化してんじゃねーよ。
難しいとか難度の問題じゃないってわかんねーのかな？
425デフォルトの名無しさん2012/11/13(火) 23:18:09.19
コードビハインドを使用したものは神の怒りに触れ
永久にメモリリークの責め苦を受けるんじゃなかったのかw
426デフォルトの名無しさん2012/11/13(火) 23:23:22.77
テンプレートにハンドラつけた場合じゃねそれ
427デフォルトの名無しさん2012/11/13(火) 23:28:45.74
自作のライブラリーをコードビハインドに対応させるって言ってたし完全に方向転換したんじゃないのかな？
それ自体はいい事だとは思うけどね
ただ、間違った持論でMVVMの概念をめちゃくちゃにした罪は大きいよね
きちんと間違ってたことを認めればいいけど、あの歪んだ性格じゃ無理だろうな…
428デフォルトの名無しさん2012/11/13(火) 23:33:30.98
必死にPSDって略語を流行らせようとしてるのに誰も使ってないのが泣ける、というか笑えるｗ
429デフォルトの名無しさん2012/11/13(火) 23:39:32.37
PDS言ってるのは知ってるがPSDは知らんな
430デフォルトの名無しさん2012/11/13(火) 23:40:55.84
DPSならしってる。全部知ってる。DPS全部
431デフォルトの名無しさん2012/11/13(火) 23:43:51.07
社内ではよく使うがネットで使う機会が無い
432デフォルトの名無しさん2012/11/13(火) 23:45:32.47
本人もあれだけど最近はアンチのがウザいな
直接煽られたことある人はそうなるのか
433デフォルトの名無しさん2012/11/13(火) 23:50:31.04
面白がってアンチに乗じてアンチごっこしてるやつが一番うざいし役に立たない
434デフォルトの名無しさん2012/11/14(水) 00:37:00.22
MSの将来が不安なのでAndroidのMVVM環境教えてください
435デフォルトの名無しさん2012/11/14(水) 00:42:27.62
JavaScriptでよければ
KnockoutがMVVMのフレームワークだよ
436デフォルトの名無しさん2012/11/14(水) 00:47:11.25
Androidでバインディングは無理だと思う
コントロールがそれぞれ独自にXML読むクソ設計なんだぜ?w
437デフォルトの名無しさん2012/11/14(水) 00:59:28.17
AndroidのフレームワークでバインディングやるならActivityのコード側でsetBindingみたいなメソッド呼んで
実装はリフレクションで頑張るしかないだろうけど
そんなことするくらいならPassive Viewの方がいいと思う
438デフォルトの名無しさん2012/11/14(水) 01:13:42.40
さすがに今年中にBlend出してくれんとしんどいわMSさん
439デフォルトの名無しさん2012/11/14(水) 01:24:18.30
Expression Studio 5まだー？
440デフォルトの名無しさん2012/11/14(水) 02:03:13.02
android binding があるでしょ
441デフォルトの名無しさん2012/11/14(水) 21:26:33.41
@ugaya40: 俺はWin8デスクトップにはスタートメニューが必要だと思うけど、シノフスキーさんの辞任と現時点で結びつけたりするわけもなく。ただその反対意見もまた極端なのが散見してるな。どっちもアホじゃないですか。
散々、極端なことを言ってたのはお前だろ？ｗ
自分で自分がアホって自覚がちゃんとあるんだな。
442デフォルトの名無しさん2012/11/14(水) 21:27:50.23
>>426
メモリーリークするの？
メンドクサイからテンプレートから呼ぶようにしたんだけど・・・ 443デフォルトの名無しさん2012/11/14(水) 21:49:40.33
444デフォルトの名無しさん2012/11/14(水) 22:08:23.42
そのうちVSスレのキチみたいに発狂しちゃうんだろうな
445デフォルトの名無しさん2012/11/14(水) 22:12:55.52
さすがに粘着が過ぎる
446デフォルトの名無しさん2012/11/14(水) 23:17:24.64
まぁ、こういう個人攻撃はネットウォッチ板でやるもんだな
447デフォルトの名無しさん2012/11/15(木) 10:53:44.15
>>442
そんなことでリークするわけない。動的に生成された要素は、XAMLでイベントハンドラが登録されたままでも
ツリーから外れた時点でGC対象になる。XAMLではなくコードビハインドなどから追加した場合は当然
WPF管理外のため、イベントハンドラによる強参照が当然残るのでそれがマズい場合があるだけ。
つまりWPF自身の問題などでは決してなく、あくまで愚かな人間によるミス。
例の宗教はあえてそのあたりをぼかす(信者の多くはそもそも理解してないまま復唱してるだけだろうが)
ことによって恣意的なイメージ操作を行っている。 448デフォルトの名無しさん2012/11/15(木) 10:57:08.02
そもそもWindow自体を解放する手段ないだろ
4494472012/11/15(木) 11:01:14.57
ItemsTemplate/DataTemplateの中のコントロールのイベントに対して
コードビハインドのイベントハンドラを登録したときの話な
試してみたら分かるが、要素を削除した後にGCが走れば
ちゃんとコントロールのファイナライザが呼び出される。
450デフォルトの名無しさん2012/11/15(木) 11:25:23.41
メッセージに応答してダイアログを開いたりする汎用的なビヘイビアって本当に必要?
VMからダイアログ開きたいんだったら、IoCでVMからIOpenFileDialogServiceのような
インターフェイスを通してメソッドを呼び出せばいいだけの話だと思うんだけど。
わざわざメッセージ投げてVで処理するなんて複雑だしXAMLも無駄に汚れるしタイプセーフじゃないし。
特定のビューでしか使わないようなサービスにするまでもない処理ならメッセージもアリだと思うけど
その場合ビヘイビアにする意味はなく(再利用しないんだから)、コードビハインドで受けて処理すればいい話だよな。
451デフォルトの名無しさん2012/11/15(木) 17:05:54.35
テスト
452デフォルトの名無しさん2012/11/15(木) 20:05:32.67
行き過ぎたBlend主義。
俺もサービスにするかな。
453デフォルトの名無しさん2012/11/15(木) 22:36:46.09
VMからのメッセージでアニメーションを開始させたいときなんかにはビヘイビアが便利かも
と思ったけどそんなビューの細かいことをVMで意識するのも本末転倒な気がするな
そこはメッセージとXAMLは直接繋がないと割り切った方がいいのかも
454デフォルトの名無しさん2012/11/15(木) 22:46:23.39
俺はビヘイビアで済ませたほうが楽かな
455デフォルトの名無しさん2012/11/15(木) 22:52:24.24
Livet教のMVVM…ドカタMVVM
IoC使うPrism系のMVVM…JavaっぽいMVVM
456デフォルトの名無しさん2012/11/15(木) 23:15:07.41
MVVM Light…光のMVVM
457デフォルトの名無しさん2012/11/17(土) 00:05:50.69
よく話にでるlivetってライブラリ落としてみたけどクラス名にまでlivetって入ってんのね。
ダサすぎる。
458デフォルトの名無しさん2012/11/17(土) 00:08:09.15
てゆーか、9割以上がPrismとMVVM light toolkitのパクリコードってのはどうなの？
Ugayaはずいぶんえらそーなことを言ってたがただのパクリライブラリじゃんか。
459デフォルトの名無しさん2012/11/17(土) 06:32:58.08
そうだなC#はJavaのパクリだもんな
つーかソース見たことはないが本当にパクリなら大問題だしそれならここで言ってないで大々的に批判すればいいんじゃないか
460デフォルトの名無しさん2012/11/17(土) 09:52:41.30
>>459
見ればわかるがおおざっぱに言えばLivetの独自部分でメソッドキャッシュとT4コンバーターぐらいじゃね？
C#っつーか.NET Frameworkだろ
1.0のころはパクリだったんじゃないの？
実際Javaがなければ今と同じ1.0は生まれてなかった 461デフォルトの名無しさん2012/11/17(土) 10:11:39.47
なんだコード盗用とかじゃなくて概念の話だったのか
462デフォルトの名無しさん2012/11/17(土) 11:07:14.48
463デフォルトの名無しさん2012/11/17(土) 12:09:36.74
>>461
綺麗に言えば、車輪の再発明？
ぱくりライブラリと言われても仕方がない代物ではある
何を目的にやってるのか分からないところもあるし
インフラを乱立させたって混乱するだけだし
ドキュメントやサンプル充実させて裾野を広げるってわけでもないし
尾上が自身の狂った思想から少しでもずれてる意見を発見すると
死ぬまで粘着されるしな
尾上は自分が日本での唯一のMVVM啓蒙者になるために
他人がおいそれと語れないようにしてるだけ
完全に癌でしかない 464デフォルトの名無しさん2012/11/17(土) 12:14:26.42
MVVMの土台として画面遷移は極めて重要だと思うが、そこがいい加減なのはいただけない
同期ダイアログによる遷移のみってWinFormsかよw WinRTじゃそんなもん使えないぞ?
465デフォルトの名無しさん2012/11/17(土) 12:30:02.96
>>464
MVVMはMSが本気で取り組まない限り無理。
言語、.NET Framework、IDEが三位一体で対応しないと今はまだ欠陥が多すぎる。 466デフォルトの名無しさん2012/11/17(土) 12:38:05.90
>>465
WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
IDEでどうするもんでもないだろう
Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。 467デフォルトの名無しさん2012/11/17(土) 13:33:39.79
U氏に親殺されたやつ多すぎだろ
468デフォルトの名無しさん2012/11/17(土) 14:04:28.46
>>467
叩かれてる奴に「氏」付けるのは本人だけ
ってだいぶ前に小学生の妹が言ってたよ。 469デフォルトの名無しさん2012/11/17(土) 14:08:17.71
画面遷移についてはMVVMと絡めてもっと真剣に議論されるべきだと思うぞ?
U氏関係なく。自称MVVMインフラではたいてい完全スルーされてるが(Livetでもおまけ程度)
どうしてもインフラ的なコードを書くことになる部分だし、MVVM使ってるなら画面遷移の設計も
それに強く影響されることになる。
470デフォルトの名無しさん2012/11/17(土) 14:08:19.65
>>466
> WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
WPFの話じゃなくてMVVMな
> IDEでどうするもんでもないだろう
IDEにどれだけ恩恵受けてるかわかってないの？
MVVMだってフレームワークだけではどうにもならないことがある
> Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
Prismがもっと使いやすく標準で.NET Fxに乗らないと無理ってこと 471デフォルトの名無しさん2012/11/17(土) 14:44:14.95
コードビハインド前提のMVVMフレームワークが出てきたら少しは前進すると思う。
Livetがダメなのは作者がコードビハインド完全否定してることと
>>458が言う通り、既存フレームワークの単なる2番煎じで
MVVMの問題点を克服するものではないから。
コードビハインドいいと思うんだけどな。
うがやのサイト見ていると分業とか書いてるが
Vをデザイナーに別注してるチームってあるのか。
デザイナーとデベロッパーの分業なんて幻想じゃないのかな。
XAMLをフルに理解してるデザイナーなんて一人もいないと思うよ。 472デフォルトの名無しさん2012/11/17(土) 14:57:27.23
>>471
その点に関してはすでに奴は考え改めてコードビハインドの有無はどうでもよくなってるみたいだぞ 473デフォルトの名無しさん2012/11/17(土) 15:03:53.77
VMの処理中にユーザの入力を求めたくなった場合とかかね画面遷移は
ぶっちゃけどのライブラリも何かあるたびにクラスやらインターフェイスやら増やさないとならなかったりして面倒だわ
MSはMVVMを推奨するんならASP.NET MVCくらい充実させるべき
474デフォルトの名無しさん2012/11/17(土) 16:41:52.99
>>473
そういう遷移はビューだけで完結するのでほとんどMVVM関係ない。
ビューの実装の詳細だ。
設計に大きく影響するのはVMごと遷移するやつな。 475デフォルトの名無しさん2012/11/17(土) 17:27:45.79
具体的な例で言ってくれよ
476デフォルトの名無しさん2012/11/17(土) 17:34:46.35
例も何も、無理にVMくつけなきゃ 一覧画面 <-> 編集画面 とか大概の画面遷移はVMごと遷移だろ
ダイアログベースならそんなに意識しないだろうけどさ
477デフォルトの名無しさん2012/11/17(土) 17:43:10.77
それならDataContextにVM突っ込んでもらうだけでよくね
478デフォルトの名無しさん2012/11/17(土) 17:54:24.04
そのコードをどこに書くのかとかいろいろ問題があるよ
本来、一覧画面VMで 画面遷移しろ("編集ビュー", selectedItemId); だけで済むはずで
一覧画面のVMやVが遷移先の画面のVやVMのクラスを知っている必要は全くないけど
そう書けるようにするためには結局インフラがいるんだよね
479デフォルトの名無しさん2012/11/17(土) 18:03:52.82
railsのscaffoldみたいにサクッとアプリを作れるようなインフラが欲しい・・・
480デフォルトの名無しさん2012/11/17(土) 19:28:02.12
>>472
どうでもいいわけないよね？
氏のMVVMサイト見てくれば。 481デフォルトの名無しさん2012/11/17(土) 20:46:12.52
プロ粘着なら奴のツイッターも観察すべき
482デフォルトの名無しさん2012/11/17(土) 23:51:38.42
>>481
前はフォローしてたんだけどね。
自分とちょっとでも意見が違うと噛みついて粘着のパターンが多すぎて
ずいぶん前にフォロー解除したよ。
あの人ちょっとアスペ入ってるよね。
ちょっとというかかなり。
高卒で会社員経験なし、ってとこで人間の底が知れるわ。 483デフォルトの名無しさん2012/11/18(日) 00:01:26.49
と２ちゃんねるで批判するガキｗｗｗ
484デフォルトの名無しさん2012/11/18(日) 00:03:44.32
>>483
ugayaの負けず嫌いもここまで来ると褒めたくなるなｗ
せっかく社会人になれたんだから2chで自演擁護とかやめたら？ｗｗｗｗｗ 485デフォルトの名無しさん2012/11/18(日) 00:09:01.67
>>484
まともな社会人は多少の煽りには反応しねーんだよ
お前みたいな無職のクズとは違うんだよ
分かったらとっとと寝ろ 486デフォルトの名無しさん2012/11/18(日) 00:11:32.55
ugayaは2chの煽りにtwitterやブログでキレまくってたけどなw
487デフォルトの名無しさん2012/11/18(日) 00:17:22.53
488デフォルトの名無しさん2012/11/18(日) 00:20:54.13
反応はしてたけど別にキレまくってたってほどじゃなかったろ
489デフォルトの名無しさん2012/11/18(日) 00:24:44.54
MVPVMの(Uによる)煽りはひどかった
490デフォルトの名無しさん2012/11/18(日) 01:06:10.42
お前ら本当に暇なんだな
文句があるなら一度でいいからGoogleの検索トップになってみろよ
U氏のサイトはMVVMで検索すると余裕でトップなんだが
491デフォルトの名無しさん2012/11/18(日) 01:10:17.68
そんなんだと宗教に騙されるぞ
U氏も言ってるだろ? 「MVVMだからこうしなければならない」じゃなくて目的を考えろと
492デフォルトの名無しさん2012/11/18(日) 01:14:55.07
>>491
自分の考えた最強の目的しか許さず
その目的を達成するにはこうするしかないと決めつける
そこから外れたツイートを見つけると相手が黙るまで粘着ツイート
相手が黙ると「都合が悪くなると無視かよ、これだからクズは困る」的なツイートで〆
尾上さんのそこにシビれる！あこがれるゥ！ 493デフォルトの名無しさん2012/11/18(日) 01:15:09.27
目的を考えろと言ってる本人が一番権威主義を煽ってる元凶という皮肉
494デフォルトの名無しさん2012/11/18(日) 01:19:48.67
尾上を擁護してるのはいったい誰なの？
誰がどう見てもアスペルガーじゃん。
尾上にへこへこ媚び売って家畜に成り下がってる奴って
高野将かぐらばくぐらいなもんだろ？
495デフォルトの名無しさん2012/11/18(日) 01:40:50.56
相手を擁護と認定してしまえばどんな誇大を使って過激に叩いても正当化できて安心だもんな
496デフォルトの名無しさん2012/11/18(日) 01:49:36.48
文句があるなら同じMVVMの土俵で反論すればいいじゃないか。
このスレに持論を垂れ流すだけでも人格攻撃よりはマシだしまともな議論なら歓迎だぞ。
考え方に関してはここはわりとU氏に反発してる人が多いみたいだし(俺もその一人だが)。
497デフォルトの名無しさん2012/11/18(日) 07:01:25.21
MVVMの思想に関してはいい加減多少は理解したから、
そろそろMVVMの実装について語って欲しいなぁ、
498デフォルトの名無しさん2012/11/18(日) 07:25:20.92
とりあえずインフラ使っとけっていう風潮？って
MVVMじゃなくてMVVMライブラリの使い方を憶える事になる
危険性高い気がするのよね。
MVVMインフラが解決しているであろう、
様々な問題を自力で解決できるように成らないと
ほんとうの意味でMVVMやXAML環境を理解したとは言わない気がする。
MVVMの啓蒙者ならそのぐらいまでやってくれないと片手落ちだろって思う。
ところでMVVMインフラってどんな問題を解決してるの？
499デフォルトの名無しさん2012/11/18(日) 13:25:29.40
コードビハインドのこともそうだしModelの責務の話もそうだけど
言ってることがコロッと変わるのはどうにかならないものなのか
なんか昨日もフォーカス制御をModelでとか唐突に言い始めるわけですよ
それが正しいかどうかは別として
ざんざん大声で他人を罵倒してまで言い続けてたことを
ちょこちょこ小出しでさりげなく路線変更してくる卑怯なところが俺が気に入らないところ
といういか、それがうがやが叩かれる原因じゃね？
500デフォルトの名無しさん2012/11/18(日) 15:58:45.35
>>499
やっぱ大学もいってないし、会社員としての経験もほぼ0でしょ？
どう考えても性格、人格が歪んでるというか問題があるんでしょう。
完全にアスペだよ、アスペ。 501デフォルトの名無しさん2012/11/18(日) 16:01:06.83
お前アスぺの意味やその性質わからずに罵倒語として使ってるだけだろ
502デフォルトの名無しさん2012/11/18(日) 16:06:22.21
人格の話は別の板でやれ。
503デフォルトの名無しさん2012/11/18(日) 16:17:28.34
私怨ならヲチでやれ
504デフォルトの名無しさん2012/11/18(日) 18:51:48.91
ここって元々WPFスレを正常化するための隔離スレッドだからいいんだよ。
便所の落書きスレッドで。
いやなら見るなｗ
by 岡村
505デフォルトの名無しさん2012/11/18(日) 18:59:24.39
まあアスペには違いない
506デフォルトの名無しさん2012/11/18(日) 20:26:20.24
尾上さんは
「日本でMVVMを正しく語れる人間は自分以外にいないッ！！」
って断言してたしスレ名を「尾上について語ろう」に修正してもよいと考えられる
507デフォルトの名無しさん2012/11/18(日) 20:52:02.11
ここMVVMやってる奴はキチガイだらけという見本のスレか
508デフォルトの名無しさん2012/11/18(日) 20:58:34.33
そもそもMVVMって何だよ
ぐぐってもクソみてーなサンプルコード乗せただけの記事しか出てこないしまともに概念を解説してるやついねーのな
コマンド(笑)とか冗長すぎてもうね
509デフォルトの名無しさん2012/11/18(日) 21:04:18.24
510デフォルトの名無しさん2012/11/18(日) 22:37:36.36
>>508
尾上さんのサイト見れば簡単に理解できる。
簡単に言うとPDS的にコードビハインドを記述しないで開発する手法だよ。 511デフォルトの名無しさん2012/11/18(日) 22:40:25.76
一応言っておくとPDSは一般的な用語じゃないから通じないと思うぞ。
512デフォルトの名無しさん2012/11/18(日) 22:41:17.17
一般的にはフリーソフトで通じる
513デフォルトの名無しさん2012/11/18(日) 23:36:11.21
>>511
自分が知らないことは一般的じゃないと考える根拠は何だろうね
自分の無知を晒しているだけと気が付かない人には何を言っても無駄ではあるが、助言だけはしておくかな 514デフォルトの名無しさん2012/11/18(日) 23:39:05.83
Wikiにないから一般的じゃないと推定される
515デフォルトの名無しさん2012/11/18(日) 23:40:30.50
どこのWikiだよ
516デフォルトの名無しさん2012/11/18(日) 23:42:35.17
PDS
http://ja.wikipedia.org/wiki/PDS
パブリックドメインソフトウェア(Public domain software)
かつてのドイツの政党である民主社会党(Partei des Demokratischen Sozialismus)。合併し、現在は左翼党 (ドイツ)に。
FTTHにおけるネットワーク構成（ネットワークトポロジー）の一つ。(Passive Double Star)
毛利元貞が考案した護身術パーソナルディフェンスシステムの略。
テレビ番組の制作会社の名称。PDS (制作プロダクション)を参照。
先駆動システム(Pre Driving System)
プラン・ドゥー・シー(Plan Do See) PDCAサイクルを参照。
アップルが採用していた拡張スロット。(Processor Direct Slot) 517デフォルトの名無しさん2012/11/18(日) 23:44:53.19
518デフォルトの名無しさん2012/11/18(日) 23:48:19.69
>>510
PDSという概念があるよということなら納得できる
ただしPDSという言葉が一般的というのは賛同しかねる 519デフォルトの名無しさん2012/11/18(日) 23:51:14.50
で、そのPDSとMVVMに何の関係が？
5205182012/11/18(日) 23:57:05.51
MVVMは、XAML系フレームワークにおけるP(resentation層)の問題を解決するもの
その前提としてPとD(omain層)の分離がある
5215182012/11/18(日) 23:59:12.80
とはいえこれはあくまでパターンであり、絶対の解法ではない
その証拠として、MicrosoftもXAML系コンポーネントベンダーもMVVMを推奨してないという事実がある
5225182012/11/19(月) 00:02:35.76
WPF・Silverlight・RTの公式ドキュメントで、一ヶ所でもMVVM必須と謳っている箇所があるだろうか？
また国内だとGrapeCity・Infragistics等のベンダーがXAML系コンポーネントを販売している
これらベンダーのマニュアルにも、MVVMを必須・提唱しているドキュメントは全く見当たらない
523デフォルトの名無しさん2012/11/19(月) 00:07:49.16
MがちゃんとしててVMはぺらっぺらになるのがMVVMの設計としては理想だからな
Web MVCではいくらぺらっぺらでもC無しというわけにはいかないが
VMがぺらっぺらになっていき、ついに無くなるのは別に問題ない
微妙に矛盾したパターンだよ
524デフォルトの名無しさん2012/11/19(月) 00:07:57.56
そりゃ必須なわけがない
MSDNマガジンやChannel9とかで適度に触れられている程度だな
あと「推奨していない」だと非推奨と主張しているように聞こえるから注意だ
「触れていない」あたりでいい
5255182012/11/19(月) 00:08:10.96
勘違いしてはいけないのは、パターンはあくまでパターンであり、絶対の解法ではないことだ
逆にパターンに振り回されてその本質を見失えば、返って障害が発生する場合もある
MVVMを使わずに開発できるのならそれでよし
526デフォルトの名無しさん2012/11/19(月) 00:09:31.95
VMとテスト
527デフォルトの名無しさん2012/11/19(月) 00:11:53.87
>>526
MがちゃんとしててMのテストだけで済むならそれに越したことはない 528デフォルトの名無しさん2012/11/19(月) 00:12:18.51
>>524
どうかな？
「MVVMが必須」という誤ったイメージが蔓延し過ぎて参入障壁が上がり過ぎると
Microsoftや周辺ベンダーしては返って喜ばしくない事態になると思う
・・・いやすでになっているな
「触れていない」というより、いまとなっては「触れたくない」が正解だと思う 5295182012/11/19(月) 00:15:52.43
かくいう私はどうかといえばMVVMは割と好きなパターンであるし、
実際これでかなり問題を解決できているのも事実だ
しかし、使えない、理解できない、開発速度が極端に落ちて苦痛に感じるくらいなら、
そこまで無理に使う必要もないと思う
530デフォルトの名無しさん2012/11/19(月) 00:28:44.37
VMがわかりにくいのって、CとかPとかと違ってVMにはこれといって
Mとの間に役割の違いが無いことだよ
特定のVとバインドすることを意識して作ったMってだけだからな
531デフォルトの名無しさん2012/11/19(月) 00:53:44.94
なにいってんだ？
ビューの状態を表すモデルデータという
役割があるだろ。
532デフォルトの名無しさん2012/11/19(月) 00:58:48.11
別に選択状態持つためのMを設けてもいいんだぜ?
533デフォルトの名無しさん2012/11/19(月) 01:02:55.31
それはもはやMではない。
Mの役割としては、GUIアプリではなく
CUIアプリからでも普通に使えるようなものを
目指すべきだ。
そんなGUIに依存した機能を持たせるべきじゃない。
534デフォルトの名無しさん2012/11/19(月) 01:04:56.93
その選択状態がGUIとしてあらわす際に必要となる選択状態なのか、
そのプログラムの動作自体を構成するにおいて存在する必然性のある選択状態なのかによるね
535デフォルトの名無しさん2012/11/19(月) 01:19:56.04
画面ごとのVMはいいけど、モデルごとのVMはめんどい
536デフォルトの名無しさん2012/11/19(月) 10:20:32.56
>>532
GUIの選択状態を維持するためのモデルをViewModelという 537デフォルトの名無しさん2012/11/19(月) 22:03:23.29
グリッドのボタン付けるときとかの
行ごとにVM作る派と作らない派の比率が知りたい
538デフォルトの名無しさん2012/11/19(月) 22:15:46.48
行って何の話だよ
539デフォルトの名無しさん2012/11/19(月) 22:20:34.86
WPFでデータグリッド使ったら負けだろ
それならWinForms使うわ
WPFならテンプレートで作れ
540デフォルトの名無しさん2012/11/19(月) 22:29:30.62
普通コンボボックスの項目毎VM作るだろ
541デフォルトの名無しさん2012/11/19(月) 23:23:02.89
グリッドって何かと思ったらDataGridのほうか
542デフォルトの名無しさん2012/11/20(火) 13:30:22.35
>>540
？？？
コンボボックスにモデルのコレクションをバインドするだけでええやん 543デフォルトの名無しさん2012/11/20(火) 13:54:25.91
HeaderedItemsControlとかをこねくり回すのは常套手段なのか
544デフォルトの名無しさん2012/11/28(水) 11:11:37.09
考え増やしたいから、
MVVM の各レイヤーの具体的な責務を教えてください
以下、テンプレ
M:
V:
VM:
545デフォルトの名無しさん2012/11/28(水) 11:22:45.65
>>544
> M:
ビューに関係無いデータ構造など変更部分。いわゆるモデル。UIスレッドと分離されてる事が望ましい。
> V:
ビューの見た目。極力もらったデータを表示したりインプットを上にあげるだけで何もしない。
> VM:
その両者を繋ぐもの。そのビューに関係するコーディネーター。ユニットテストできること。スレッド間の調整をここで吸収。 546デフォルトの名無しさん2012/11/28(水) 11:22:46.45
Set-Location : ドライブが見つかりません。名前 'M' のドライブが存在しません。
547デフォルトの名無しさん2012/11/28(水) 11:34:44.90
一番ありそうな間違いは、WebMVCの典型的な間違った使い方のように
M: データ
VM: ロジック
としてしまうことだな
注文画面のMは注文処理クラス。VMはあくまでインターフェイスの差を吸収するだけ。
5485442012/11/28(水) 11:45:53.66
549デフォルトの名無しさん2012/11/28(水) 12:47:28.47
使う側ならそれでいい
550デフォルトの名無しさん2012/11/28(水) 14:02:32.93
Mのビジネスロジックがバックエンドに移って
結果的にMがデータだけになることはあるだろうけど
VMから見たら特に関係ない話。VMにビジネスロジックを書いてるわけじゃない。
551デフォルトの名無しさん2012/11/28(水) 21:50:02.31
プレゼンテーションに関わるものとしてVMに置いとくべきデータやロジックがあるって意見も耳にするけど
自分には区別が難しいので極力Mに持たせるわ。
5525442012/11/28(水) 22:50:19.03
永続化しないデータとか？
553デフォルトの名無しさん2012/11/28(水) 23:14:06.28
MVVM界隈の話はVMが強調されすぎるきらいがあるよな。
本当はMの方が遥かに重要なのに。どちかか省くなら迷わずM。
VMはMVVMパターンのアイデンティティだから仕方がないけど。
5545532012/11/28(水) 23:14:52.00
間違えた省くならVM
555デフォルトの名無しさん2012/11/29(木) 00:02:45.23
プレゼンテーションにかかわるものはVに書くんじゃないのか
556デフォルトの名無しさん2012/11/30(金) 06:22:26.73
VMは、抽象的な、表示する「ための」データだな
例えば、VでItemsSourceにバインドして表示する一連のデータのコレクションとか
特定のデータを、手段は特定しないからとにかく強調表示しろ、ということを示すプロパティとか
Vは、具体的な、表示「の仕方」だな
同じVMからでも、同じコレクションを表示させる方法はListBoxだったりDataGridだったり単なるテキストだったり
どんな形で表示するのかはVが決めることでVMは手を出せない
また、強調表示の仕方にしても、単なる色変化だったり太字だったり、その部分だけ無意味にアニメーションさせたり
表示の仕方もVに任せられててVMは手を出せない
557デフォルトの名無しさん2012/12/11(火) 16:23:56.96
VBでペタポトプログラミングしか経験ない奴にパターン教えても一向に概念理解してくれない
ましてMVVMなんか到底無理無理
558デフォルトの名無しさん2012/12/11(火) 18:18:42.11
そんな動けばいいという考えの奴に何をいってもダメだ。
平気でModel部分にフォームやコントロール(UI)のインスタンスを食わそうとしたりするからな。
559デフォルトの名無しさん2013/01/16(水) 20:12:33.47
MVVMって従来のASP.NETやWindowsフォームに慣れた人に説明するなら、
V Aspxファイル/フォーム
VM コードビハインドのcs
M 業務ロジック
と対応してて、従来のASP.NETやWindowsフォームとの大きな違いは、
ViewとViewModelがバインディングを介すると言う制約があるので分離しやすい、
と言う理解なんだけど大体合ってるかな？
560デフォルトの名無しさん2013/01/16(水) 22:46:55.45
全然
561デフォルトの名無しさん2013/01/17(木) 23:06:47.49
大体合ってるみたいですね。
VB6脳なPGとJava/Struts脳なPG、どっちがMVVM覚えるのに向いてますかね？
562デフォルトの名無しさん2013/01/18(金) 08:37:02.03
>>561
全然違うと言われてんだろ
概念がそもそも違うがそれが分からない人間でも
・コードビハインドは画面と同一クラスだがVMは別クラス
・コードビハインドとViewは一対一だが、View:VMは1:n
・VSでコントロールをダブルクリックしてもコマンドが作られて自動的にバインドされたりしない
・そもそもコードビハインドはコードビハインドで存在するだろ
と、上げ出したらきりが無い
MVVM使うならちゃんとMVVMの概論くらいは理解させないとあとで自分が地獄行きだぞ 563デフォルトの名無しさん2013/01/18(金) 09:03:18.93
的外れな回答()キター
564デフォルトの名無しさん2013/01/18(金) 14:28:02.15
いまだにVB6脳なんて他のこと何も向いてないだろ
565デフォルトの名無しさん2013/01/18(金) 14:46:29.63
違うって言われてるのに合ってると受け取っちゃうのはどこにも向いてないな。
566デフォルトの名無しさん2013/01/18(金) 17:07:06.64
全然合ってるかもしれない
567デフォルトの名無しさん2013/01/20(日) 07:38:18.01
559は大体あってるよね？
というより562が間違いすぎｗ
・コードビハインド（各種イベントで呼び出される関数）は
手動で設定すれば Viewとは別のクラスにすることは可能だし
・V:VM は 一つのデータを別表現で表示することがあるので V:VM = n:1
・デザイナでダブルクリックしても自動で出来ない
→細かい処理を行いたければデザイナに任せずに手動で操作するのは当たり前。
・そもそもコードビハインドはコードビハインドで存在するだろ
→別にイベントで関数呼び出しても、
CommandやActionのバインディングで関数呼び出してもよくね？
568デフォルトの名無しさん2013/01/20(日) 07:50:01.85
そういえば、データバインディングって
ほんの少し MFCのValue変数とDDX_〜 に似てないか？
569デフォルトの名無しさん2013/01/20(日) 09:40:48.58
570デフォルトの名無しさん2013/01/22(火) 07:57:45.76
@Grabacr07 いままでのオレオレICommandの正しい実装基底クラス
Prismのパクリなのになんでこんなに偉そうなの？
571デフォルトの名無しさん2013/01/22(火) 19:39:17.12
心底どうでもいい
572デフォルトの名無しさん2013/01/22(火) 21:17:29.87
MVVMライブラリはすべてPrismのパクリだからな
いまさらだろ
573デフォルトの名無しさん2013/01/25(金) 10:23:59.51
別に偉そうじゃない件について
どれだけコンプレックス感じてんだよｗ ダッセーやつｗ ぷげら
574デフォルトの名無しさん2013/01/25(金) 23:38:53.69
実際やってみたらMVVMではなくWPFやSilverlight固有の部分でかなり躓いた
初見でXAMLを自由自在に扱える奴とかいるのか？
575デフォルトの名無しさん2013/01/25(金) 23:46:59.77
固有の約束事を理解しないといけないのはWinFormsだってASP.NETだって
PHPとかのWebフレームワークだって一緒だ
576デフォルトの名無しさん2013/01/26(土) 00:00:26.99
パネル使ったレイアウトに慣れてないだけじゃね？
577デフォルトの名無しさん2013/01/26(土) 00:07:18.85
578デフォルトの名無しさん2013/01/26(土) 00:11:58.51
ControlTemplateとか初見でMSDNだけで使いこなせたら神だわ
579デフォルトの名無しさん2013/01/28(月) 10:43:39.37
Templateカスタマイズする時点で折れるな
580デフォルトの名無しさん2013/01/29(火) 02:16:53.83
>>573
別にウガヤが考えたロジックじゃあないのに
まるで自分で考案したような口ぶりが臭いだけじゃろ。
特にcommandのweakeventなんてprismのアイデアそのまんまだし。
++c++やneueと違って.NETやC#(言語)の知識は薄っぺらいのに
ビックマウスだから余計に臭い。 581デフォルトの名無しさん2013/01/29(火) 05:30:37.24
>>580
詳しくは知らんが咀嚼して自分のライブラリとしてまとめ上げて、それを採用してくれてるとこもあるんだから、口だけ番長のお前より遥かにまし。
リアルでフルボッコにされたの？悔しいのぅ悔しいのぅ。 582デフォルトの名無しさん2013/01/29(火) 07:57:35.12
奴が自分で考案したみたいなことを言っているのは見たことないが
どの辺で言ってたのか気になるな
583デフォルトの名無しさん2013/01/29(火) 08:22:09.37
別に好きでも嫌いでもないが、世の中のMVVMフレームワークは全てLivetより下と言ってるように取れる文書ならみた
MVVMが普及しないのは既存のインフラが不十分なせいで、Livetがそれを解決するんだとか
確かアンチMVVMに反論する記事だったかと思う
584デフォルトの名無しさん2013/01/29(火) 08:34:30.68
現場でMVVMゴリ押しして使ったら大失敗したからアホにも使えるように作ったんだっけ？
部下も可哀想だな
585デフォルトの名無しさん2013/01/29(火) 08:50:43.67
まあ既存のが不十分なのはあってるな
ただLivetが必要十分かと言うとそうでもない
586デフォルトの名無しさん2013/01/29(火) 09:18:58.54
Javascriptエンジン組み込んでknockout.jsを逆移植するのがいいと思う
ビューに振る舞いを書けた方がいいのは、それを最初否定してたMVVM自身によって証明されたし
VMも静的言語で書くのは面倒な単純作業すぎる
587デフォルトの名無しさん2013/01/29(火) 09:31:08.32
ReactiveExtensions絡めて作ってるがすこぶる楽だし見通し良くなってイイよ。
まぁ向き不向き有るかもしれんが。まだ試しで作ってるだけなので後でいろいろはまるのかもしれんけど。
内部の状態遷移など含めて綺麗に落とし込みたいんだけどまだそこまで出来とらん。
588デフォルトの名無しさん2013/01/29(火) 10:26:40.09
MVVMとリアクティブプログラミングの相性は非常にいいね。
ただ、ReactiveExtensionsは記述が冗長になるので
人にはお勧めできないな。
async,awaitみたいにコンパイラ支援があればいいんだけど。
589デフォルトの名無しさん2013/01/29(火) 10:36:58.35
>>588
非同期として扱うだけなら冗長になるかもしれんがその以上やるならあんなもんじゃない？どの変が気になる？
F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。 590デフォルトの名無しさん2013/01/29(火) 12:29:20.69
MVVMって何ですか？
591デフォルトの名無しさん2013/01/29(火) 12:40:25.22
wwwwみたいなAAの一種
592デフォルトの名無しさん2013/01/29(火) 12:51:58.26
>>588
俺は非同期についてはasync,awaitを使ってるから気にしてなくて、
リアクティブプログラミング本来の "関係性を記述する" って部分で冗長性が気になる。
例えば、
int A { get { return B ? C : D.E; } }
って単純な関係性を記述するだけでも、それなりの量になる。
> F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
F#の計算式は羨ましいね。
async, awaitがTask<T>を生成するのと同じように、
計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。 593デフォルトの名無しさん2013/01/29(火) 13:51:35.91
>>592
> int A { get { return B ? C : D.E; } }
> って単純な関係性を記述するだけでも、それなりの量になる。
自分もまだそこまで突っ込んで触ってないのでなんだが、自分で用途に合わせた複数要素を取れるZipみたいな物とか作らないと記述が冗長になりそうな気はしてる。
Zip重ねてとかでもいいけど見た目的にも身微妙な気がしなくもない。
> 計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。
その辺でSelectManyとかSwitchで上手く合成出来ると綺麗に書けるんかね( ´Д`)y━･~~ 594デフォルトの名無しさん2013/01/29(火) 15:41:47.19
F#で計算式を使うと言っても、do!やlet!でやるのは
ReactiveProperty<T>からをT型の値を取得すると同時に値の監視を開始するだけだから
C#でも似たようなことはできるけどね。
上の int A { get { return B ? C : D.E; } } の関係性なら
ReactiveProperty<int> A
{
get { return ReactiveProperty.Create(x => x(B) ? x(C) : x(x(D).E)); }
}
と書けるReactiveProperty.Createは実装可能。
逆に言えばF#でも同程度の記述の冗長性は残るという事になる。
595デフォルトの名無しさん2013/01/29(火) 16:11:47.74
596デフォルトの名無しさん2013/01/30(水) 18:31:22.62
従来型のほうがいいだろ
誰かさんにプレゼント
優れた言語より流行ってる言語
優れたフレームワークより使われてるフレームワーク
597デフォルトの名無しさん2013/01/30(水) 18:52:28.14
アプリケーションで、各種バー表示のon/offや配置等の、GUIに関する設定がよくあると思いますが
そういう設定の保存・読み込みロジックはVMでいいんですよね?
MVVMの概念がまだあやふやで確信が持てません。
598デフォルトの名無しさん2013/01/30(水) 18:55:35.45
一番使われてるフレームワークが一番、ってのなら、
一番のラーメンはインスタントラーメンだぜ？
599デフォルトの名無しさん2013/01/30(水) 19:04:13.88
Haskell大流行だもんな
600デフォルトの名無しさん2013/01/30(水) 19:13:05.88
>>598
フレームワークとラーメンとが置換可能であることを証明できれば完璧だな。
イグノーベル賞がんばれよ。 601デフォルトの名無しさん2013/01/30(水) 20:13:22.03
COBOL最高だろうが
602デフォルトの名無しさん2013/01/30(水) 20:49:05.37
>>597
Vでしょ
というかそういう作り込みが必要な画面にMVVMを適用するのは不適切だと思うよ。
大してメリットがなく面倒なだけ。使うならダイアログとかで使う。 603デフォルトの名無しさん2013/01/30(水) 20:55:18.66
メニューとか(共有の)ツールバーとかウィンドウ制御のようなシェル的な部分に
MVVMを適用しようと考えてはいけない
そういうのはインフラとしてMVVMの枠外で実装して、その中で扱うドキュメントには
必要に応じてMVVM適用するのがスマート
604デフォルトの名無しさん2013/01/30(水) 22:12:56.62
あくまでVの都合だしな
MVVMは本体処理とUIの組み合わせ方のパターンでしかないので、ウィンドウのサイズ保存とかはロジックとは無関係
605デフォルトの名無しさん2013/01/30(水) 22:13:53.89
>>602
え？Modelじゃないの？
煽りじゃなくて、真面目な質問です 606デフォルトの名無しさん2013/01/30(水) 22:14:56.02
あぁ、確かにビジネスロジックではないのか
607デフォルトの名無しさん2013/01/30(水) 22:45:08.78
あえてシェルにMVVMを適用するんならMだろうな
どちらにしろGUIに閉じた話であって、ビジネスロジックの世界とは分けて考えるべき
608デフォルトの名無しさん2013/01/30(水) 22:47:03.45
>>597
VMで正しいよ。
ビューモデルというのは、ドメインモデルとビューとのギャップを埋めるラッパーの役割をするもので、
まさに>>597のようなビュー固有のデータを扱うのに適している。
Vに置くのは（少なくともこのスレにおいては）間違いだから>>602は気にしなくていい。 609デフォルトの名無しさん2013/01/30(水) 22:56:21.08
>>608
それこそビジネスロジックとUIがごっちゃになってね?
もともとビジネスロジックから見たらVの実装の詳細にすぎないことで、
それが少々複雑になるからMVVM適用しようってんなら
GUIの設定情報を持つためのMを使うのが適切だと思うよ 610デフォルトの名無しさん2013/01/30(水) 23:00:06.22
アプリケーションモデルというやつですか。
611デフォルトの名無しさん2013/01/30(水) 23:07:07.58
そもそもそんなロジックに直接関係なくてGUIに閉じた混みいった制御と
金,人間,住所,データベース,入力フォーム云々を一緒にして扱うのがおかしい
そこ明確に分けるのが一番大事だろ
612デフォルトの名無しさん2013/01/30(水) 23:19:21.22
そんなめんどくさいことせんでも、VBで画面にぽちぽちボタンとか張って、
ダブルクリックしてイベント追加したら、その中に全部処理書けばええやろww
613デフォルトの名無しさん2013/01/30(水) 23:22:23.10
PrismだとShellに対してVとVMがあって、ShellのVMのプロパティに
入力画面とかのVM渡して、ShellのVの中でその画面開いて、ツールバーなども
Shellが管理するようになってたはず。サンプルではShellに対するMは無かったけど、
ツールバーの細かい設定入れるとしたら当然この設計ではShellのMになるよね。
ShellのVMが本当に必要かどうかはかなり怪しいが。
614デフォルトの名無しさん2013/01/30(水) 23:22:30.14
>>609
ビジネスロジックというのを定形的に捉えすぎてね？
アプリケーションシェルと言った物の実装も対象が違うだけでビジネスロジックの実装と変わらんだろ。
MVVMはロジックとビューをブリッジ介して分離する仕組みでその対象がシェルでも構わんと思うけどね。
他の実装がしやすいなら無理に適応する必要はないけど。 615デフォルトの名無しさん2013/01/30(水) 23:26:54.51
>>609
ドメインモデル（ビジネスモデル）からはビューモデルに対して一切関知することはなく、完全に独立している。
ビューモデルからはドメインモデルを（継承やコンポジションなどの形で）参照することになるが、
当然ながらドメインの詳細には立ち入らないため、ごっちゃになることはない。
> GUIの設定情報を持つためのMを使うのが適切だと思うよ
ここではモデル（M）をドメインモデルとビューモデルとに明確に区別しているわけで、このGUIの設定情報と
いうのがまさに表示のためのモデルであり、ビューモデルだと>>608で書いたつもり。
なんか噛み合ってないかな？ 6166092013/01/30(水) 23:32:29.95
>>614-615
うん。だからシェルの抽象化がVMだしシェルのロジックやデータがMとするなら
Mじゃないかってことが言いたかった。省くならVMを省くべきじゃない?
バインディングもあんまり役に立たなそうだし。 617デフォルトの名無しさん2013/02/04(月) 00:54:01.35
ViewModelHelper.ReadOnlyDispatcherCollectionのソース見てるんだけど
Dispatcher経由でViewModelのDisposeしなくていいの?
618デフォルトの名無しさん2013/02/04(月) 02:17:34.63
WeakReferenceがなんとか
619デフォルトの名無しさん2013/02/12(火) 00:41:05.78
だからコードビハインドのあるなしとMVVMに何の関連もないと何度言ったら。。。最近コードビハインド付のMVVMしかしてない
おがやさん以前は、コードビハインドはMVVMの癌、肯定してる人は糞みたいなニュアンスのこと言ってませんでしたっけ？
この人若年性健忘症なのかな？
620デフォルトの名無しさん2013/02/12(火) 00:45:23.42
そーとー昔じゃないかな？それ
621デフォルトの名無しさん2013/02/12(火) 00:59:57.57
いくら昔でも180度真反対に勘違いするほどの痴呆症を患った高齢の方には見えなかったもので。
622デフォルトの名無しさん2013/02/15(金) 08:39:40.77
>>621
ようするにやせ我慢だったと。そういう事です。
コードビハインドなんて所詮MS界隈でしか使われないローカル技術仕様の用語に過ぎず
モデル云々を語る抽象的な概念にはほど遠い。
単に趣味と程度の問題を高尚っぽく語りたい人が散見されるだけ。 623デフォルトの名無しさん2013/02/16(土) 04:51:33.73
>>622
MS以外でも使われてるだろ
もっと幅広い知識を持たないといかんよ。 624デフォルトの名無しさん2013/02/16(土) 06:51:52.98
例
625デフォルトの名無しさん2013/02/16(土) 10:39:51.16
MS以外のコードビハインドkwsk！
626デフォルトの名無しさん2013/02/16(土) 11:09:58.98
627デフォルトの名無しさん2013/02/16(土) 15:33:08.84
なんかデータバインディング持っているフレームワークなら何でもコードビハインドだとでも
言いたそうな勢いだなw
UIの画面設計の宣言的定義とUIロジックの手続き的記述を分けて書けるフレームワークなんて
MS以外にもいくらでもあるし、データバインディングもそのための定番手法の一つではあるが
knockout.js含めて「コードビハインド」という用語がMS関連以外の文脈で使われることなんて
ほとんどね〜よ。手続き的記述の部分をMSが独自にそう呼んでいるだけの話。
628デフォルトの名無しさん2013/02/16(土) 15:44:41.67
日本語だと分離コードになるのか。
確かにMS関連しかその言葉聞かないし、ぐぐってもMS関連しか出てこない
629デフォルトの名無しさん2013/02/19(火) 01:32:44.57
似たようなものだと、コードビハインドという単語ではないけどJSFの管理ビーンとか似た雰囲気
630デフォルトの名無しさん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にはり付けるのも簡単。
631デフォルトの名無しさん2013/03/03(日) 08:33:04.94
やっぱダイアログや画面遷移はView Serviceにするのが好きだな。
632デフォルトの名無しさん2013/03/03(日) 10:12:08.72
同意
共通に使えるものにメッセージ使うのはアンチパターン
というかメッセージいらない
633デフォルトの名無しさん2013/03/07(木) 11:13:30.47
MVVMの意図するところはこんな認識で合ってる？
・V<->VM の依存関係はバインディングに任せましょ
・VM はデータの加工と操作 (コマンド) の提供に専念しましょ
634デフォルトの名無しさん2013/03/09(土) 07:15:19.68
大雑把にはあってるんじゃないか
635デフォルトの名無しさん2013/03/09(土) 19:14:13.47
MとV&VMを別プロジェクトにして問題ある？
636デフォルトの名無しさん2013/03/09(土) 19:48:12.38
>>635
ないって言うかむしろしろ(´・ω・｀) 637デフォルトの名無しさん2013/03/09(土) 19:48:13.70
よっぽど小規模でない限り分けるだろ
638デフォルトの名無しさん2013/03/22(金) 14:44:16.04
開幕迎える前にグッバイ・モーガンになるんか？
639デフォルトの名無しさん2013/04/01(月) 12:24:22.90
640デフォルトの名無しさん2013/04/01(月) 13:51:12.65
MenuItemに直接アクション持たせてIsEnabled管理も別プロパティでやるか、
CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ
6416392013/04/01(月) 19:20:38.99
せっかく教えてもらったが、いってることがわからんズラ
「MenuItemに直接アクション持たせて」とはどのようすればいいんだろうか？
サンプルのサイトがあったら張ってもらえないだろうか。
「CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ」
これをやるためには、MenuItem の Command にバインディングする必要があるだろうが、ダイアログの表示はコード・ビハインドでやるという理解でよいでしょうか？
質問ばかりですまんです。
642デフォルトの名無しさん2013/04/01(月) 19:58:53.84
MenuItemのIsEnabledにコマンドの可否状態が反映されないって言うからMenuItemにコマンドはバインドした状態で反映されないって言ってるんじゃなかったの？
それともコマンドをMenuItemにバインドせずにMenuItemに反映されないって言ってるの？
ダイアログの表示ならコマンドで叩かれたVMからVへメッセージ飛ばしてやるんだろ
そのために確認用のトリガとアクション書いたんじゃないのか
6436392013/04/01(月) 23:25:33.35
質問の仕方がまずかったかな。
IsEnabled と具体的なプロパティを書くのではなくて、
MenuItem の活性・不活性に CanXXXX が反映されない
と書けばよかった。
コードはリンク先に書いてあるのとほとんど同じ。
"Interaction.Triggers"に設定していあるのであって、
MenuItem の Command にはバインドされてない。
質問をかえれば、リンク先のようなコードを書いたが、
これでは SetDefaultColorCommand の CanSetDefaultColor
が MenuItem の状態（活性・不活性）に反映されません。
どうしたらいいでしょうか？
って感じです。
644デフォルトの名無しさん2013/04/02(火) 01:20:28.31
>>643
MenuItemはLivetのメッセージ機構なんて知らないし
DirectInteractionMessageにもコマンドの状態を反映させる仕組みは無いから
自分でやらなきゃならんだろうな。
VMにプロパティを用意してIsEnabledにバインドするとか
コマンドの状態をIsEnabledに反映させるBehaviorでも書けば? 645デフォルトの名無しさん2013/04/02(火) 13:33:43.91
LivetのCommandにはCanExecuteプロパティあるからIsEnabledにそれをバインドするのがいいだろう
6466392013/04/02(火) 21:29:50.11
>>645
ありがとう。できた。
シンプルな解決策だね。 647デフォルトの名無しさん2013/04/05(金) 08:36:23.77
Livetの0.98辺りの時に書いてたソースコード、
今のバージョンだとそのまま使えないんだな…
DispatcherCollectionとかWindowMessageActionとか、
コンストラクタに渡せるパラメータの型とか順番とか、すっかり変わっちゃってる
648デフォルトの名無しさん2013/04/08(月) 17:23:05.27
Livet .NET4.5で、読み取り専用のスレッドセーフなコレクションをModelに持たせたいんですけど
ObservableSynchronizedCollectionをラップするクラスを自作するしかありませんか?
649デフォルトの名無しさん2013/04/08(月) 19:50:30.83
MVVMだのスレッドセーフだの言う前にマルチスレッドをちゃんと理解しろよ
読み取り専用ならスレッドセーフだからReadOnlyCollection<T>でいい
650デフォルトの名無しさん2013/04/08(月) 20:35:10.02
読取専用のコレクションは変更されないわけじゃないぞ
651デフォルトの名無しさん2013/04/08(月) 20:47:02.14
さすがにそれは無理があるだろ…
それに、随時少しずつ変更されるんじゃなくて時々ゴソっと入れ替わるだけなら
Observable*使わなくてもコレクションごと差し替えてしまえばいい
652デフォルトの名無しさん2013/04/08(月) 21:01:42.99
っていうか作法的には>>651のやり方の方が正しく「スレッドセーフ」だと思う
Observable*使うと、連続してコレクションを変更するときに変更途中の変な状態が晒されちゃうよ
決してObservableSynchronizedCollectionなら解決するという問題ではなく 653デフォルトの名無しさん2013/04/08(月) 21:35:22.96
一括で変化させるのではなく、逐一反映させたいのです。
その為読み取り専用ラッパもINotify〜でないといけません。
654デフォルトの名無しさん2013/04/11(木) 14:22:53.29
Livetプロジェクトを作った時にできるInfrastructureAssembliesフォルダは何のためにあるの?
6556542013/04/11(木) 14:37:04.33
すいません。必要なDLLとクイックヒントのXMLっぽい事は分かりました。
でもLivet.Design.dllが何の役割があるのか分かりません。
656デフォルトの名無しさん2013/04/13(土) 02:18:05.29
>>648
ReadOnlyObservableCollection 657デフォルトの名無しさん2013/04/15(月) 14:41:24.53
昔の0.9xのLivetで開発してたもので、画面描画が完了したタイミングでアニメーション開始させるために
DispatcherHelper.BeginInvoke(action, DispatcherPriority.Render);
みたいに書いてたのがあるんだけど(actionはアニメーション開始させる処理)、
今のLivetだと「BeginInvokeは古い形式です」とかいう警告になってしまう。
まぁ、警告だからコンパイルできるし実行もできるんだけど…
警告出ない、古くない形式ってどう書けばいいんだろう?
658デフォルトの名無しさん2013/04/16(火) 00:44:11.22
UIDispatcherプロパティからBeginInvokeだったと思う。
659デフォルトの名無しさん2013/04/16(火) 07:45:34.55
>>658
それでOKみたいですね どうもでした
0.9xと1.xで、結構変わってるとこ多いですねー 660デフォルトの名無しさん2013/05/02(木) 16:37:49.02
MVVMでの非同期処理をする場合について質問なんですが
MはUIスレッドを意識せずプロパティやコレクションを変更し
それを監視してるVMが適宜UIスレッドにディスパッチする
という感じでするのでしょうか?
661デフォルトの名無しさん2013/05/02(木) 17:18:30.55
UIスレッドというものはView側の都合だからそんな感じだな
VかVMあたりだろう
662デフォルトの名無しさん2013/05/08(水) 13:29:53.61
Livetの公式ページが404 File Not Foundになってる…
663デフォルトの名無しさん2013/05/08(水) 14:57:34.62
よくあること
664デフォルトの名無しさん2013/05/10(金) 06:05:27.27
よくあるのか
たまにしか見に行かないから、この1年半くらいで初めてだった
そのうち直るのかな
665デフォルトの名無しさん2013/05/14(火) 17:27:08.94
@merancronと@ugaya40のサイレントバトルがかなり面白い
666デフォルトの名無しさん2013/05/17(金) 06:09:53.49
Livetのページ、1週間以上経ってもまだ404 File Not Foundなんだが閉鎖しちゃった?
それとも移転したのか?
閉鎖にしても移転にしても何かその旨書いといて欲しい
しかしユーザー困るな
667デフォルトの名無しさん2013/05/17(金) 14:40:36.69
668デフォルトの名無しさん2013/05/17(金) 15:27:29.29
MVPなんだからAzureの無料枠ぐらいもらってるだろうに……
669デフォルトの名無しさん2013/05/17(金) 19:00:21.91
や ら な い か
671デフォルトの名無しさん2013/06/24(月) 11:30:16.12
Uにリムーブされていることに気がついたｗ
まあ、ちょくちょく揉めてたからなｗ
672デフォルトの名無しさん2013/10/03(木) 15:35:02.10
Vにバインドしたコマンドの内部で非同期操作を呼び出したときのお作法ってあるんですかね？
673デフォルトの名無しさん2013/10/03(木) 16:40:34.53
俺は気にしてないが、VMでは特に気にしなくていいんでね？
674デフォルトの名無しさん2013/10/10(木) 22:24:40.50
>>672
同じコマンドを複数回読んだ場合、場合によっては順序が変わる可能性あるからその辺に注意ぐらいかのー 675デフォルトの名無しさん2013/10/10(木) 23:00:23.03
いい加減日本語の書籍を出してほしい。
676デフォルトの名無しさん2013/10/14(月) 23:43:00.78
ModelがINotifyPropertyChangedを実装する理由は
Mを操作した結果、プロパティが変化したことを通知する
という理解でいいですか?
677デフォルトの名無しさん2013/10/15(火) 12:36:49.83
OK
678デフォルトの名無しさん2013/10/16(水) 15:35:26.82
>>676
OnPropertyChanged で渡すプロパティ名が間違っていると View への通知が
正しく行われない。当たり前の話だけど、この種のつまらないトラブルが
多いから注意してね。 679デフォルトの名無しさん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 680デフォルトの名無しさん2013/11/15(金) 07:23:33.44
俺も最初に参考にしたサンプルが
View/ViewModel/Model みたいにフォルダ作ってたので
それに倣ってそんな感じにしたけど、サンプル程度のクラス数ならいいんだけど
数が2桁くらいになってくるといまいちだよね。サブフォルダまで作っても。
むしろ、特定の機能のフォルダ作っちゃって、そこに
それに関連したView/ViewModel/Modelをセットで入れる、みたいなのも
逆にそこだけで完結しないで複数にまたがるのが分類しにくかったり。
681デフォルトの名無しさん2013/11/15(金) 13:19:46.47
682デフォルトの名無しさん2013/11/15(金) 14:20:43.75
少なくともView内は分けない方がいいと思う
683デフォルトの名無しさん2013/11/15(金) 14:31:37.31
昔はフォルダで分けてたけど、今はこんな感じ↓
ソリューション
- ModelLayerプロジェクト
- ViewModelLayerプロジェクト
- ViewLayerプロジェクト
- UnitTestプロジェクト
- Commonプロジェクト
684デフォルトの名無しさん2013/11/15(金) 14:38:30.55
書き忘れたけどもう一つ、ソリューション名と同名のプロジェクトが有るな
（仮にMainプロジェクト）
MainプロジェクトとUnitTestプロジェクトは、アプリケーションプロジェクトで
V/VM/M及びCommonプロジェクトは、クラスライブラリプロジェクト
685デフォルトの名無しさん2013/11/15(金) 18:56:17.04
C#の場合自動生成される名前空間にフォルダ階層が付加される仕様がこういう場合鬱陶しい
686デフォルトの名無しさん2013/11/15(金) 19:45:58.66
複数の機能(サブシステム)から構成されるようなアプリなら、俺も680派。
「レイヤ」よりも「機能」の方が凝集度高いんだし。
1機能内でもまだ画面が多いようなら、/機能/の下にView/ViewModelとかを作っても良いけど。
そこまででなければ、少なくともViewとViewModelはセットで。
Modelは、機能固有のものならセットにしても良いけど、だいたいはアプリケーションレベルで
考えるものな気もするので、別配置。
687デフォルトの名無しさん2013/11/15(金) 23:49:30.50
ModelはともかくViewとVMは一対一で対応してること多いからなあ
688デフォルトの名無しさん2013/11/16(土) 04:31:20.31
Modelはフォルダどころか別プロジェクトだろ
6896792013/11/17(日) 16:07:31.49
>>680,686
機能ごとに分けて、そのフォルダの中にV/VMを突っ込むのよさそうだね。
VとVMは一緒にいじること多くて、近くに置いておきたいし。
ありがとう!!
すごく参考になった。 690デフォルトの名無しさん2013/11/17(日) 16:51:12.93
VMが扱うモデルは１つとは限らないわけで、そういうのは無理があると思うけどね
691デフォルトの名無しさん2013/11/18(月) 10:21:42.10
ん？
692デフォルトの名無しさん2013/11/19(火) 23:38:23.24
>>690
機能単位でまとめるのはVとVMまでにして、モデルは別フォルダとか別プロジェクトにまとめる、でいいんんじゃないかな？ 693デフォルトの名無しさん2014/01/13(月) 13:39:58.61
Mの設計にいまいち確信が持てないんだけど
例えばChromeみたいなタブブラウザを作る場合、開いてるページのコレクションはMで持つの?
694デフォルトの名無しさん2014/01/13(月) 18:47:34.47
>>693
MVVMはそんなに厳密に考えんでいいと思うけどね。
VMをVIEWを軽くするためのロジック移し場所ぐらいに考えてモデルを分ける必要あるなら作ると。そのモデルは一つでも複数でもいい。
Chromeの例なら自分なら開いてるタブやその他の状態を持つアクター一個作るかな。 695デフォルトの名無しさん2014/01/14(火) 13:13:51.65
MVVMの設計に関しては、
まずアプリケーションをVとMに分ける。
次にVをVとVMに分ける
くらいの考えでいいと思う
696デフォルトの名無しさん2014/01/15(水) 10:21:03.85
今はMVVMPCEARELS
697デフォルトの名無しさん2014/03/05(水) 07:59:10.50
test
698デフォルトの名無しさん2014/03/05(水) 16:17:16.97
普及している感じがしない
ModelがViewを意識しなきゃいけないとか言ってるアホの事は無視して良いですか？
それは単に、本来Modelの責務だったものっていうだけじゃないのかよ。
>>699のような手合いは一度ふぁうらー先生の本でも読んだらいいよ
関心事の分離とフレームワーク依存がわかってない PoEAAは読んでるけど、どこがわかってないのかわからないので、教えてくれ。
>>699
今迄一度もViewでこのデータが必要だからここに持たそうとかやったことのないものだけが石を投げなさい(｡-_-｡) >>700
マジでなにがどうわかってないんだか教えて欲しいんだがな。 toroのログが欠落しちゃってるのか。
で、ごめんなさい、読み返してみて、自分の言い方が完全に悪かったと思いました。
toroの705の言っていることに対する認識の相違はないです。
自分がアホだと思ったのは[ModelがViewを意識]と[Modelの責務]をごっちゃにして、
[Modelの責務]として適切だった例を論拠に[ModelがViewを意識]を都合良く解釈して、
短絡的に、なんでもModelに実装して良いんだというような発言をしている人の事です。
派遣で行った先がひどかった
VMで、いろんな処理に使われるプロパティAが
VMのコンストラクタとかで初期化されるわけでもなく、
一体どこで初期化されてるんだ? と思ったら、
そのVMの、全く別のプロパティBがVにバインドされてて、
そのプロパティBが読みだされる時に
初めてプロパティAが初期化される、というとんでもない仕組み。
当然、VとバインドしてBが呼び出されない限りAは永遠に初期化されないので
Aを使ういろんな処理も一切できないという、
Vなしでは成り立たないVM
正気の沙汰とは思えなかった
MVVMのM/VM/Vの各要素はなんとなく分かったけど、全体でどんな形になるかいまいち確信が持てないんだけど
何かいいサンプルコードないかな。
特にModelの設計で参考になるようなのが欲しい。
Prism5.0が出たそうなんだけど、画面遷移とかで標準になりそうな新しい切り口出てた？
MSがこれ使えっていう決定版出してほしいな。
プロジェクト形式でもいいから。
ReactiveProperty良さげなんだけど使ってる人います？
週末にでも遊んでみよう。
WPF MVVMでアプリ作ってる人いるんだろうかと思えるくらい過疎っぷりだな
ほんと情報少なくて困ってる
こんなスレあったのか。今まで気が付かなかった。
MVVMは机上の空論っていうか筋が悪いの一言に尽きると思う。
これは過去にオブジェクト指向が攻撃されたような批判者の理解不足に基づく誤解では必ずしもない。
とオブジェクト指向の時にも同じようなことを言っていた人はいた。
>>713
具体的にはMVVMのどこらへんが実情に即していない机上の空論で、筋の悪さなの？
可能であれば、古典的MVCやMVPとの比較も交えながら論じてみてほしい。 結局どんな設計がいいの？
Rxに傾倒したけど、上手く使いこなせてない
匿名通信（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的に分散され、特定のサーバーに依存しません
・ >>717
fluxとかかな。まだよく分かっていないけど。
状態を一箇所に集約する fluxのデータフロー見てたらApache Strutsを再発明したかったのかなって思た
MVVMって保守性が悪いよね。
WPF自体がそういう傾向が強いけど、MVVM使うと輪を掛けてそうなる。
他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。
MVVMで保守性が高くなるんだ！って喧伝してる人がいるのは知ってるけど、
正直裸の王様を褒めてるようにしか思えない。
結局正解はなくて最適解があるだけなんだけどさ
よくある失敗はMVC、それも頭でっかちなコントローラーをVMに置き換えているだけパターン
この場合ビューモデルが主役で、テンプレートエンジンのビューと1:1の対となる入れ物の箱モデル
を量産することになる
ちょこっとイベントハンドラーをコードビハインドに書いたら、あとは全部ビューモデルにお任せ
という中央集権国家が誕生、疎結合どこいったって話だな
>>721
>他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
>ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。
これって単に慣れてないからってだけじゃなくて？ やっぱりrails系は偉大だったってことかなー。
どこにどんなコードを置くのかフレームワークとして強制するって大事だね。
iOSとかUIKitってだけだから特にファイル構成に対する強制がなくて悩む。
お前らがMVVM頑張っても
画面設計者がMVVM理解者とは限らないから
どこかは破綻するんやで
データを格納したdatatableをdatagridにバインドして表示させてます。
この場合、datatableはVMですか？Vですか？
他のフレームワークに比べてMVVMが有用なケースって、WPF以外だとどんなのがありますか？
>>729
Xamarin.Forms
vue.js UWPみたいな大きい画面から小さい画面までサポートする奴。
UIとロジック分けられないと死ねる。
modelからViewModelに通信の結果を返すときに、
Rxとか使わずに、interfaceを渡してコールバックを返すようにするのは何かマズいんでしょうか
modelは状態の公開と戻り値のないメソッドの提供のみするそうですが、
状態の公開っていうのは要はpublicなfieldってことなんでしょうか
getterで提供したらなんで駄目なんでしょうか
c#のことはよくわかりませんandroid javaを想定しています
>>734
メソッドの戻り値をvoidにする、setterを提供しないのはMVVM由来ではなく、非同期な作りをしたい場合に起因します。
これは非同期な作りの場合、メソッドを呼び出しても直ちに状態が変更されるとは限らないから。
なので、状態の変更が完了した時点でMが通知し、受信側がgetterを介して状態を取得することを推奨しているに過ぎない。
逆に同期的な呼び出ししかしないのであれば、setterやメソッドの戻り値も好きにすればいいと思います。 がや氏の戻り値返すなとかはCQRSやReactみたいに処理の流れを固定しろってのが本質と思うが本人もアーキによって返しますよとかいってるからじゃああの煽りはなんだったの感もありよくわかんね
本人の中では色々な蓄積もあってその上で言ってんだろうけど、間を飛ばすから外から見たらよくわからん事になってるという印象
とりあえず御大の言うことはスルーしておいて、Flux、Reduxなんかについて調べてから、自分で答えを出せばよろし
C#で状態の公開というとプロパティを使うわけだけど、
javaにはプロパティがないからgetter使うしかないだろうし…
そもそもMVVMではgetter使っちゃダメなんて話があるの…？
状態の公開が何でpublicなfieldになんのか分からん
オブジェクト指向もっかい勉強した方がいい
いや返り値のないメソッドしかテイギシタラ駄目っていう縛りがあると思ってたから、
getterも駄目なのかと
MVVMの提唱がMSからだし、MSが作った言語にはプロパティがあるから…
…javaのgetterが駄目ならプロパティ使うのも駄目になるはず
ゲッターかプロパティかは本質じゃないだろう。
ゲッターをフィールドっぽく見せてるのがプロパティなだけなんだし。
AndroidでMVVMやりたいだけなのに
C#でのMVVMとFluxとReduxとクリーンアーキテクチャと
databindingとRxとretrolamdaと全部学ばないといけないわけ？
敷居高杉ませんか
MVVM含めアーキテクチャごっこをやること自体が目的なら全部学べよ。
Androidで開発しやすくしたいというのであれば、まずはData Bindingを使うことと、
APIの戻り/公開メンバとしてObservableを使ってみるところから始めろ。
DroidKaigiのアプリあたりを参考にしながら。
droid kaigiですね。ありがとうございます。
他にMVVMの参考になる小規模なソースコードのgithubリンクとかないっすか
Android java MVVMで検索したら色々出てくるけど…
画面遷移の処理とか結局viewでしかできないから、
view -> viewModel -> view
で行ったり来たりしてるのとかみると糞だなあと思う
Presentation Coordinator
Navigation Service
なお、画面遷移の話とは別に、Androidの場合どうしてもActivity/Fragmentに
依存してしまう部分は出てくるから、その辺はあまり厳密に考えない方がいい。
VMとMの分割についてきちんと説明してくれてるサイトってあまりないけど、
基本的には全部Mに入れてVMはプロパティとしてMだけを持ってそれをVにバインドするってことでいいの？
大抵のサイトでは全部VMに入ってるけど
サイトは知らんが、一番しっくりくるなーと思う考えの一つは
MはDBなどのデータを格納する何か、もしくはデータそのもの。
VMはMからのデータを加工するものとVewとの橋渡しを分けてVMへ。
VはVewそのもの。
ってのが個人的に一番しっくりくる。
viewそのものだとactivityがviewになるのは違和感がないか
MVCだろ
M はDB以外のことは出来るだけしない
V は表示するだけ
C(VM) で色々する
概ね >>752 さんに同意 VMがactivityの参照を持ったらだめだと聞いたが。。
Xamarinだとpageか
イメージとしてはCより広い範囲のものをぶち込んでMやVに余計な物置かないのがVMって思ってる。
基本MVCと変わらん。
Cじゃないのはどこに置くとか名前から混乱してる人多かったから、VでもMでも無いのは全部VMってした方が混乱は少ない。
MVVMのVはMVCのV+Cだよ
MVPのVとかと同じ
MVVMってMVCより明確にしたもの
VMはCという漠然とした者じゃなくて
Viewに対応するオブジェクトそのもの。
だからVMのプロパティを変更することでViewに反映されるし
Viewで何か変更するとVMのプロパティに反映される。
双方向バインディングを使って実現する。
>>762
効率求めたらガチガチにVewと結びつくからな。
Vewが固定ならMVCもMVVMも要らない。
デスクトップやモバイルで中身同じだけどVewだけ違うとかだからMVCやMVVMが必要になる。
デスクトップとモバイルで同じ処理を別々に書くよりは全体では効率が良くなる。
特にモバイルが画面の大きさや画面比率が多様化してる昨今では。 >>764
強いて進化と言ったらMVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したままで、updateで更新しないと値を更新しなかった。
MVVM独自かは不明だが、MSでは相互に値の更新を自動通知し合う仕組みが出来た。
>>763が言ってるのはそういう事。 MVVMにおいてactivityはviewでいいんだよな？
更にいうとMVVMをさらに発展と言うか破綻しづらいようにしたのが
flux。MVVMのVMは双方向バインディングだけど
fluxの場合は、Viewの変更は直接VMに反映しない方針。つまり片方向バインディングに限定した。
その代わりVMへの変更関連をActionに集約して
Action -> State(VMに対応) -> View ->Action
と片方向への情報の流れに限定したのがflux
>MVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したまま
糞Windowsだけだろω
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
USCRF
Livetは使った事ないから知らんがWPF開発には色々便利なものあったらしいしPrismも便利なとこあるんじゃないの
自分は使わんけど
評判は聞いてたからその範囲で教えてあげてんだけど？
無知すぎるボンクラは逝ってどうぞ
Prism.Unityは、UWP版のほうがシンプルでかつ十分な機能で良いんだけど
wpf版もあっち基準に改善したら良いのにな
>>777
知らないなら答えなくていいんじゃね？
ぼんくらは死ね >>777
知らんなら答えなくて良いんじゃね？
過疎スレで無駄に煽るボンクラ >>783
無知が顔真っ赤にしてテラワロスっておまｗ
そんなんがほんとに面白い人とかいるのかね
MVVMはどこいったのｗ
スレタイと何も関係ない書き込みしちゃって頭おかしくないのボンクラｗｗｗｗ いやテラワロスってのはMVVMなんだろうな
無知なのでわからんわ
>>779
＞INotifyPropertyChanged はバインド専門ではありません。
これって詭弁だよね
MVVM使う時点で通常のモデルにすると不便だからINotifyPropertyChanged使うだけ MVVMじゃない設計で作られた モデル、ビジネスロジックがあってそれをMVVMで使う場合どうすんの？ってことなんだろうけど
もう一層外からくるんだだけじゃうまくいかないからほとんどを作り直しすることになるんじゃないかな？
>>784
何日も前のに突然どうしたw
>>786
MMV間は好きにすればいいかと
自分はわざわざMでINotifyPChangedなんか使わんけど 俺なんかMVCすらよくわかんないな
Webは兎も角、それ以外はMVCだと言われてるアプリを見てもCからVを書き換えてるのだらけに見えちゃうんだな
これでいいんか？それとも世の大半が間違えてるのか？どっちなんだ
Cからvだけでしかないってのはダメだと思うが、結局その場合にちょうどいい程度に疎結合になってればいいと思うけどね
自分はMVにロジックも詰め込んで、でかくなってきたらMにする程度でやってる
いつも疑問なんだけどMVVMでダイアログ表示するときなんでVMでShowDialog()しちゃいかんの？
MessengerでViewに送ってコールバックでってやるよりもVMをDataContextにぶっこんで直接操作したほうがわかりやすくない？
>>791
MVVMのVMは、UIへの依存を排除することを試みるパターン。
なので、直接呼んで良いかと問われればNo
UIの知識に起因する処理を行いたいのであれば、UIから提供されたインターフェースを介してUI操作を行うMVPの採用を検討する。
結局のところ、MV*の違いは責任範囲の違いだけであり、MVPがMVVMよりV寄りに広いパターンなので、MVVMをベースにMVPにしても構わない。
ただしその場合、混乱の元なのでMVVMとは呼称すべきではない。 >>791
ぶっ込んで直接操作が何を指してるのかわからん。
そのダイアログを表示がらみだと思うけどもうちっと具体的に言ってくれ。
元のViewと対応したVMがあったとして、そこからダイアログ表示させる場合でいいんだよね？ >>793
すまん、説明が悪かったかも
あと無意識にWPFを前提に話してしまっていた
MainWindow
MainWindowViewModel
MainWindowModel
DialogWindow
DialogWindowViewModel
があったとしてMainWindowのボタン押下をトリガーにDialogWindowを表示したいとする
でWPFの昨日でVMにコマンドバインディングしていたボタンの処理の中で
DialogWindowのDataContextにDialogWindowViewModelを入れる
→MainWindowViewModelの中でDialogWindowのインスタンスを生成する
みたいな感じ VMからVを直接生成するのは禁じ手かと
てスタビリティーが担保できない
自分は自分で作るちょいアプリでも使ってるけどな
といってもVM膨らませてMもそこでやってて、ややこしくなったら分離させてるだけだけど
WPF+MVVMはテストがつらい
M、VMでテストが出来てても実際にVでうまく動くかは全然わからない
>>799
ん？それほかのUIフレームなら出来るん？ アプリケーションのテストとしてはVM-M間で十分だと思うがな。
V-VM間はデータバインディングが意図通りか確認する程度だし。
少なくともFormsよりだいぶUIに近いところまで自動テストできるようになった。
>>799
ViewはMVの状態をそのまま表示するだけってのが理想だからね
セレニウムだっけ？WEBでのUIテスト出来る奴とかあるかもだけど、自動テストでそこまでの工数かけるのちときつくね？
VMのテストならプログラム的にしやすいからまだわかる >>698
バカには使えないありがたいアーキテクチャなので
普及とかはどうでもいい話だった VisualWorksのPluggable MVCとどう違うのだろうか？
Pluggable MVCとはだいぶちがうだろう
Application Modelの間違い？
>>805
ValueHolder、AspectAdaptor、PluggaleAdaptorとか 結局、ビュー寄りのモデルを作るという発想は90年代初頭にVisualWorksで提唱されていたんじゃないかと。
もともとMVCとかでごちゃごちゃしてきたところにMVVMってことなんだろうな
デスクトップアプリに当てはめるのは微妙だったよ
デスクトップに当てはめるのが微妙ってのは何だ？仮想Dom的なものがあればおさまる話？
あとMVVMはMVCを改良したってよりもXAMLのバインディング気候に合わせたって側面の方が強いと思うがな
それを改良と言えばそうだけど
実装者の能力不足が問題になるということは設計パターンが悪いんだろ
本当に理解してるか確認するが難しいようなのもダメだ
>>815
楽できるかどうかじゃなくて、
画面を直接触らずに済むかどうかの問題だろ。 暇だから数年ぶりにWPFでも触ってみようかなと思ってるけど、
乱立してた結局MVVMライブラリって結局何かに統一された？
Livetは死んでしまったみたいだねw
個人的には応援してだけど
>>819
typo
x MVVVCross
o MVVMCross むっちゃ初歩的なところの質問になってしまうのですが、
WPF + Prismの環境で、画像ファイル(png)をウインドウ内にタイル状に並べたいのですが、
単体でパスをSourceに指定して、Converterを通して表示、までは出来たのですが、
これをListView上でおこなおうとすると、ListviewにBindingしているObservableCollectionにAddしても、
画像が表示されません。
何かわかりやすいサンプルや、チュートリアルなどありませんでしょうか？
>>822
チュートリアルは知らんが、リストにテキストやボタンは表示できるの？
出来るなら今単体でコレクションの要素とビューテワやってる関係を同じようにするだけだけど >>822
ListViewのTemplateをGridViewとしDataTemplate使うんじゃなかった？ よく知らんけど。 
ブックマークへ