12/06/06 11:03:33.21 .net
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
2:デフォルトの名無しさん
12/06/06 11:09:54.07 .net
関連記事
Model View ViewModel
URLﾘﾝｸ(ja.wikipedia.org)
Model-View-ViewModel デザイン パターンによる WPF アプリケーション
URLﾘﾝｸ(msdn.microsoft.com)
MVVMパターンの常識 ― 「M」「V」「VM」の役割とは？
URLﾘﾝｸ(www.atmarkit.co.jp)
MVVMパターンとイベント駆動開発、そしてMVC/MVP/PMパターンとの関係 ? 何故MVVMなのか
URLﾘﾝｸ(ugaya40.net)
「MVVMパターンが必要な理由」啓蒙用資料公開
URLﾘﾝｸ(ugaya40.net)
3:デフォルトの名無しさん
12/06/06 12:06:49.93 .net
語れるほどニーズあんのか？
4:デフォルトの名無しさん
12/06/06 12:30:27.30 .net
MVCよりはまし。
でも、MVCすら理解できないのが大半だからなー
5:デフォルトの名無しさん
12/06/06 12:40:59.59 .net
MVPとMVC混同してる人けっこういるよね
6:デフォルトの名無しさん
12/06/06 12:50:21.81 .net
UIパターン知らんでMVVM知ろうとしても無理ゲー
7:デフォルトの名無しさん
12/06/06 13:04:32.71 .net
>>5
実装上の違いだけで本質的には同じもの
そこにこだわるってことは、たぶん本質が分かってないんだろうな
8:デフォルトの名無しさん
12/06/06 14:22:00.43 .net
語ることあるのか知らんが期待しとく
9:デフォルトの名無しさん
12/06/06 14:34:22.26 .net
要するにXAMLで開発してれば自動的にMVVMなんでしょ？
開発環境を作ってるのでも無ければ、あんまり純粋主義主義者になる意味は無いと思う。
10:デフォルトの名無しさん
12/06/06 14:36:36.66 .net
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
11:デフォルトの名無しさん
12/06/06 15:10:32.26 .net
MVVMツールがVSに標準装備されてないことか推測するに、MVVMがXAMLUIに必須でないことが判る
12:デフォルトの名無しさん
12/06/06 15:41:03.54 .net
>>9 自動的にMVVMではない。
>>11 必須ではないが有用。
13:デフォルトの名無しさん
12/06/06 16:24:21.12 .net
デザインパターンと同じで、フレームワークの名称じゃないからね
自分でフルスクラッチしてもいいんじゃよ？ 別にむずかしくないし
でも「mstest？ なにそれおいしいの？」って子は
本来のメリットの半分もえられないからこれまで通りにかけばいいんじゃないの
14:デフォルトの名無しさん
12/06/06 19:44:35.03 .net
MVVMで実際のDBに繋いでCRUDのサンプルってないね。
DBのあたりはEntity Frameworkでいいの？
15:デフォルトの名無しさん
12/06/06 19:53:11.38 .net
つか語呂悪い。なんで最後だけ二文字なんだよ。
16:デフォルトの名無しさん
12/06/06 19:56:31.71 .net
>14
プレゼンテーション層以外はすべてModelなのでどうでもいい話
>15
回文
17:デフォルトの名無しさん
12/06/06 19:59:28.53 .net
>>15
じゃあ何て略したらいいんだよｗ
18:デフォルトの名無しさん
12/06/06 20:01:18.77 .net
Mのぶぶんは別になんでもいいお。
そもそもMの部分はVMとのセパレーションさえできていればいわゆるModel的なものですらなくていいと思う。
なんというかViewに関連しないものでありさえするなら、ステートを持つ実体的なものでもサービスとのやり取りをするProxi的なものでもなんでも。
実際のアプリではVMとMが一体化してるようなものもあると思われ。
19:デフォルトの名無しさん
12/06/06 20:13:26.93 .net
アプリケーションや実装固有の話だからといって、MVVMにおけるMやMVCにおけるMのパターンを語る気が無いなら
「V-VM-VとVM以外パターン」とか「V-C-VとC以外パターン」とか言っておくべきだな。
20:デフォルトの名無しさん
12/06/06 20:42:38.20 .net
Mはドメインロジックなのでモデルといって問題ない
21:デフォルトの名無しさん
12/06/06 20:47:41.09 .net
つうか、むしろ話としては、VVMな部分の話よりも、MVVMにおけるMの話の方が語ることは多いと思うが。
VMとして責務を分離する話に、スレを立てるほどの広がりがあるのかなあ？
22:デフォルトの名無しさん
12/06/06 20:48:35.99 .net
ドメインロジックという言葉が何に対してでも都合良く使われる問題。
23:デフォルトの名無しさん
12/06/06 20:48:37.04 .net
実装の話とか？
24:デフォルトの名無しさん
12/06/06 20:51:59.61 .net
>>22
それはすげー思うｗ
25:デフォルトの名無しさん
12/06/06 20:54:32.74 .net
Mについてはそれなりに構築できるけど、
そこにVを被せるときに毎回苦労するんだなー
26:デフォルトの名無しさん
12/06/06 20:58:39.14 .net
対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。
MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、
ひいては状態を持っているるからドメインモデルです(｀・ω・´)ｷﾘｯ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。
27:デフォルトの名無しさん
12/06/06 22:10:29.54 .net
いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな
28:デフォルトの名無しさん
12/06/06 23:41:43.34 .net
だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある？、っていう。
まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。
DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、
サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。
29:デフォルトの名無しさん
12/06/07 00:03:55.68 .net
それはアプリケーション（Model）の役目だろうよ
V＆VMはむしろ生成される側だと思われ
30:デフォルトの名無しさん
12/06/07 00:13:47.89 .net
簡単に言えば
V 見た目
M 本処理
VM 接着剤
だろ
MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで
UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな
Modelって名前なんだから何々であるべきなんだ！！１なんて話はナンセンス
31:デフォルトの名無しさん
12/06/07 00:14:54.65 .net
その「アプリケーション（Model）」っていう言い方も微妙だが…。
生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。
でも、その話すらしないのだとしたら、本当に何の話をするんだ？
32:デフォルトの名無しさん
12/06/07 00:15:55.19 .net
ザックリ分けると
・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
・MVVMとしての各画面の作り方の部分
・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分
って感じかね。
33:デフォルトの名無しさん
12/06/07 00:16:50.09 .net
>>30で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの？
34:デフォルトの名無しさん
12/06/07 00:23:50.25 .net
>>33
>>30の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの？
35:デフォルトの名無しさん
12/06/07 00:36:57.38 .net
MVVMの実装に関する話ならいくらでもできるんじゃね
36:デフォルトの名無しさん
12/06/07 01:12:27.18 .net
むしろそちらの方を知りたいという人間多いんじゃね？
MVVM的に考えるとコマンドはVMに置くべきか否か
コードビハインドとイベントハンドラとVMの関係
コードビハインドはいわゆるプレゼンターか否か
バインディングとMVVMは切り離して考えるべきか否か
MVVMとしてふさわしいVMの実装は
もっと高速にVMを実装する方法はないかとかね
37:デフォルトの名無しさん
12/06/07 01:13:45.85 .net
あとMVVMツールの良し悪しや使用方法についてとか
38:デフォルトの名無しさん
12/06/07 01:19:01.75 .net
ビヘイビアってよく聞くけどVMに入るの？
39:デフォルトの名無しさん
12/06/07 06:11:20.38 .net
>>32みたいな、アプリケーション構造の話をするのはこのスレではあり？、なし？
MVVMフレームワークの実装比較の話は俺も聞きたいな。
40:デフォルトの名無しさん
12/06/07 06:16:05.12 .net
定義論にまた脱線しない限りまあいいんじゃね
41:デフォルトの名無しさん
12/06/07 08:14:29.03 .net
>>39
むしろそのためのスレだろ
42:デフォルトの名無しさん
12/06/07 09:30:27.00 .net
Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。
その境界がどこかの確認。
43:デフォルトの名無しさん
12/06/07 09:57:41.92 .net
>>42
新参者だが、荒れるん？
むしろMVVM作る上で重要なファクターだと思うんだが。
44:デフォルトの名無しさん
12/06/07 10:11:41.27 .net
Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです！、な発言が出てくるから。
その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。
45:デフォルトの名無しさん
12/06/07 10:16:56.33 .net
何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか
MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ
46:デフォルトの名無しさん
12/06/07 10:28:50.09 .net
本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。
そこでV～M間に仲介者を設け、V(XAML)、VM（C#）の二層構造とし、VMにViewの状態とModelのデータを保持させて
V～VM間をバインディングで通信するのがMVVM。
47:デフォルトの名無しさん
12/06/07 10:30:41.00 .net
ほらｗ
>>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途
WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。
48:デフォルトの名無しさん
12/06/07 10:35:21.73 .net
>>45
それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには１も３も必要だろ。
49:デフォルトの名無しさん
12/06/07 10:58:40.42 .net
＞DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
ってMVVMとどう関係あるの？
洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがｗ
50:デフォルトの名無しさん
12/06/07 11:00:01.66 .net
>>48
VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ
51:デフォルトの名無しさん
12/06/07 11:04:12.67 .net
>>49,50
M内の構造はMVVMとは関係ないよ。
でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ？
MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。
52:デフォルトの名無しさん
12/06/07 11:07:44.33 .net
>>51
ああ、ごめん。IDが出ないから流れがわかりにくいなこのスレ
>>49は>>47への反論です
>>50も俺だけど>>51と全く同意
53:デフォルトの名無しさん
12/06/07 11:16:28.31 .net
>>46
そもそもVMはV層でしっかりVとMの分離になってるんじゃないか
Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし
54:デフォルトの名無しさん
12/06/07 11:18:42.66 .net
やっぱり、VVM内に閉じた話だけを扱うスレなのか？、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか？、っていう最初に戻るじゃん。
VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。
55:デフォルトの名無しさん
12/06/07 11:26:13.73 .net
定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる
定義知りたきゃMVVMでぐぐってろ
56:デフォルトの名無しさん
12/06/07 11:27:07.00 .net
そもそもMVVMってなに？
57:デフォルトの名無しさん
12/06/07 11:27:49.63 .net
>>56
>>2
58:wikiから抜粋
12/06/07 11:33:08.35 .net
Model
アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、
サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。
MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる
一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。
たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。
アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。
Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。
59:デフォルトの名無しさん
12/06/07 11:34:10.24 .net
MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。
それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね？
60:デフォルトの名無しさん
12/06/07 11:36:30.09 .net
>>58
それってU氏の記述だろ？
61:デフォルトの名無しさん
12/06/07 11:40:56.25 .net
わかりにくいからMVVMをガンダムでたとえて
62:デフォルトの名無しさん
12/06/07 11:47:53.91 .net
>>54
そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・｀)
63:デフォルトの名無しさん
12/06/07 11:49:55.46 .net
>>61
M=ララァ
VM=サイコミュ
V=ビット
64:デフォルトの名無しさん
12/06/07 11:58:29.11 .net
>>63
なんとなくこれ思い出した
URLﾘﾝｸ(d.hatena.ne.jp)
65:デフォルトの名無しさん
12/06/07 12:54:35.30 .net
スレのあり方を議論するだけで終わりそうだｗ
66:デフォルトの名無しさん
12/06/07 13:03:38.18 .net
おまえが勝手に思ってるだけだろ
67:デフォルトの名無しさん
12/06/07 13:17:43.48 .net
質問です。
ButtonクリックしてViewModelからWindowクローズしたいんだけど、ViewModel側にはどう書いたらいいのでしょうか？
68:デフォルトの名無しさん
12/06/07 13:21:47.51 .net
ウィンドウを閉じる動作はViewで完結しているものなんじゃないでしょうか
69:デフォルトの名無しさん
12/06/07 13:57:19.39 .net
ウィンドウサイズ保存したい
70:デフォルトの名無しさん
12/06/07 13:57:28.88 .net
>68
そうなんですか？わかりました...(´･ω･`)
71:デフォルトの名無しさん
12/06/07 14:36:34.99 .net
>>69
コードビハインドで実装すればいいよ
72:デフォルトの名無しさん
12/06/07 14:36:56.58 .net
>>68
未保存のデータがあるときだけ確認メッセージを表示とか、Viewだけじゃ完結しないだろ。
73:デフォルトの名無しさん
12/06/07 16:02:42.75 .net
LivetのMessengerクラス使えば、ViewModelからWindow閉じたり最大化・最小化を操作できる
URLﾘﾝｸ(d.hatena.ne.jp)
74:デフォルトの名無しさん
12/06/07 16:10:07.46 .net
よし分かった、俺がこれがコードビハインドだって
お手本のプログラムを作って見せてやるよ。
75:デフォルトの名無しさん
12/06/07 16:21:57.25 .net
>>73
他のMVVMツールにも同様の機能はありますか？
76:デフォルトの名無しさん
12/06/07 17:01:49.59 .net
>>75
その部分だけパチってくればいいじゃん。
77:デフォルトの名無しさん
12/06/07 19:40:33.37 .net
ugaya40さん、MVVMの本書いてよ。
78:デフォルトの名無しさん
12/06/07 20:19:01.71 .net
彼は文書よりもLivetのチュートリアルの優先度をあげるべきだろ。
79:デフォルトの名無しさん
12/06/07 20:39:57.25 .net
チュートリアルないと使えないか？
サンプルなら探せばそれなりにあると思うけど
80:デフォルトの名無しさん
12/06/07 20:47:05.63 .net
使える使えないという話ではなく、広くアピールしたいならそういう地味な作業の優先度の方が高いんじゃないの、という話。
81:デフォルトの名無しさん
12/06/07 20:47:06.97 .net
ugaya40さんって誰？と思ってこれを読んだけど
URLﾘﾝｸ(ugaya40.net)
MVPとPresentation Modelの認識がおかしいな
まぁ全体として意味は通じるけど…
82:デフォルトの名無しさん
12/06/07 20:52:17.02 .net
ところで、これってMVCとどう違うの？
MVCのときとMとVも当然違うと思うんだけど。
83:デフォルトの名無しさん
12/06/07 20:52:18.22 .net
u氏の言っていることは、VVMや実装の話についてはほぼ同意だしすごいとも思っているけど。
ただ、そこからMよりの話やもっと大きな構造の話になってくると、言っていることが微妙というか、
言おうとしていることはわかるけど、他の人の同意は得られないだろうな、っと思うことが多いかな。
84:デフォルトの名無しさん
12/06/07 21:28:22.45 .net
Livet使ってるけど2chの名無しに返信しないで欲しい、とだけ言っておきたい
85:デフォルトの名無しさん
12/06/07 22:11:46.33 .net
Livetネタは荒れるからやめろ。
本人に直接聞け。
86:デフォルトの名無しさん
12/06/07 22:23:47.65 .net
>>77
そんなニッチ層向けの本書いても売れないだろ
87:デフォルトの名無しさん
12/06/07 22:59:32.63 .net
MVVMってどれがええの？
Livetがオススメ？
88:デフォルトの名無しさん
12/06/07 23:01:51.98 .net
mvvmlight
89:デフォルトの名無しさん
12/06/08 00:29:17.99 .net
それはプログラミングにどの言語がいいのかと聞くようなもので
PrismもLivetもMVVMLightもどれも一長一短だからな
人に聞けばたぶんバラバラに返ってくるだろうから
一度使ってみて使いやすいのを判断したほうが早い
90:デフォルトの名無しさん
12/06/08 01:33:55.43 .net
>>81
どの辺が認識おかしいの？
91:デフォルトの名無しさん
12/06/08 08:13:09.32 .net
>>89
そういうんでは、その一長一短を聞きたいんだろ。
ぜんぶ試すってのはなかなか難しい。
92:デフォルトの名無しさん
12/06/08 10:23:56.69 .net
>>86
いや、結構売れるかも知れんぞ。
93:デフォルトの名無しさん
12/06/08 11:41:06.72 .net
VMへのサービス層のDIってどうやるべきものなの？
それ以前に、VMとMを繋ぐ方法として、VMにサービス層をインジェクションする、っていう考え方はあってる？
94:デフォルトの名無しさん
12/06/08 11:59:23.74 .net
>>93
時と場合によるんだろうけど、そうするとMでやるべきのがぜんぶVMに来ない？
95:デフォルトの名無しさん
12/06/08 12:38:59.57 .net
>>94
自分が想定したのは以下の様なサービスファサードがあったとして。
interface HogeServeiceFacade
{
IE<Foo> GetFooList();
}
HogeServeiceFacadeの実装の中では、外部サービスにアクセスしたり、ドメインモデルによる処理をしたり。
HogeServeiceFacade自体はバッチやWebでも使うものだとして。
ここがファサードになるので、それ以上Mの処理がVMに来ることは無いと思っているんだけど。
っで、このHogeServeiceFacadeとVMを接続する方法にコンテナ/サービスロケータを使う場合に
どうするのかとか？、それって考え方としてそもそもあっているの？、っていうのを聞きたかった。
96:デフォルトの名無しさん
12/06/08 12:44:10.40 .net
>>95
そういうんではありなんじゃない？
そもそもMVVMは大本はViewとMの分離があって、それにさらに薄いVMいれると更にセパレーションで来て良いよねって話だから。
で、ロケータ使う場合色々あるけど既存の使うか自前で作るかじゃない。
薄いやつなら実質ただのKeyValueで出来るだろうし、それで結構まかなえると思われ。Prismとかはその辺も実装されてる。DIがより良くインテグレートされてる。他は知らん。
97:デフォルトの名無しさん
12/06/08 13:03:47.05 .net
コンバータ(IValueConverterを実装したクラス)はMVVMのどの層に属するものなの？
98:デフォルトの名無しさん
12/06/08 13:07:30.90 .net
>>97
View
99:デフォルトの名無しさん
12/06/08 13:20:41.29 .net
コンバータ自体簡易VMみたいなもんじゃね？
100:デフォルトの名無しさん
12/06/08 13:32:59.19 .net
>>97
それを分類することに何か意味があるの？
101:デフォルトの名無しさん
12/06/08 13:47:18.95 .net
コンバータ、StringFormat、VMでの詰め替え等が混在していると保守性が悪くな�
102:閧ｻうだ
103:デフォルトの名無しさん
12/06/08 13:55:44.00 .net
VMでなんでも出来はするるが、責務としてVMでやるのはデータ構造の変換までにして、色だの文字だのの修飾はコンバーターでやるべきだろう。
104:デフォルトの名無しさん
12/06/08 13:57:35.24 .net
自分はコンバータも形式の変換で、修飾なりなんなりはViewにやらせるな
105:デフォルトの名無しさん
12/06/08 14:47:38.34 .net
おまえらユニットテストには何使ってるの
106:デフォルトの名無しさん
12/06/08 14:53:47.65 .net
>>96
Thx
考え方としてはありか。
Prismにはその辺の仕組みもあるのね。
じゃあ、各フレームワークでそういう機構を持っているものについて、該当クラス名とかを知っている人がいたら教えて下さい(*・ω・)*_ _)ﾍﾟｺﾘ
後は自分で調べるので。
107:デフォルトの名無しさん
12/06/08 15:13:12.05 .net
>>104
NUnit
108:デフォルトの名無しさん
12/06/08 15:14:23.05 .net
MVCとかMVPとかのパターンを判りやすく解説してる本あったら教えて
109:デフォルトの名無しさん
12/06/08 15:24:26.98 .net
>>104
俺もNUnit。
110:デフォルトの名無しさん
12/06/08 15:27:32.55 .net
上のご神託を読んでこい。
111:デフォルトの名無しさん
12/06/08 15:36:30.90 .net
>>109
いや、MVVMの前提となるMVCやMVPについて知りたいんだが
やっぱファウラー先生あたりの本になるのかな？
112:デフォルトの名無しさん
12/06/08 15:57:52.51 .net
偉い先生が書いたものとか読んだことないわー
MVCとかなにかのパターン本に乗ってたけどネットで探れるのと大差ない。
MSDNでMVPVMの説明してるやつでMVC,MVP説明してるのあったお
113:デフォルトの名無しさん
12/06/08 16:02:11.72 .net
MVCではクライアントはC(イベントハンドラ、リスナー、コールバック)に
アクセスしてVがレスポンスとして帰ってくるのに対し、
MVVMはクライアントがVにアクセスしてVが帰ってくる感じだな。
HTMLならステートレスなMVCが、Viewがクライアント内にある
ステートフルなappletとかsilverlight、デスクトップGUIならMVVMが良さそうだ。
114:デフォルトの名無しさん
12/06/08 16:12:29.99 .net
MVCについて知りたいならSmalltalkを調べろ。
WebのMVC(2)ならむしろRESTってキーワードで調べろ。
MVVM自体に関する本は知らん。
そしてそれとは関係無しに、PoEAAなんかも読んでおくべき。
PoEAAだけ読んで、ドメインモデルvsトランザクションスクリプト厨になったりする奴も多いけどな。
115:デフォルトの名無しさん
12/06/08 16:18:06.91 .net
そろそろ電子書籍で売ってくれ
116:デフォルトの名無しさん
12/06/08 17:40:37.50 .net
>>113
MVCってSmalltalkコミュニティから提唱されたのか
117:デフォルトの名無しさん
12/06/08 18:47:52.68 .net
たしか。
オブジェクト指向の元祖たるSmalktalkで発展したものだと効いた希ガス
118:デフォルトの名無しさん
12/06/08 19:10:59.99 .net
良スレの予感。
119:デフォルトの名無しさん
12/06/08 20:31:39.36 .net
やっぱりVMのライフサイクル管理やVMへのインジェクションを行うサービスロケータはあっても良いよな。
アプリケーションの構造によっては別にいらないだろうけど。
120:デフォルトの名無しさん
12/06/09 10:42:20.11 .net
複数ViewModel間の呼び出しってどうすべき？
121:デフォルトの名無しさん
12/06/09 11:28:54.73 .net
public string Name
{
get { return Model.Name; }
set { Model.Name = value; }
}
こういう感じで VM で M のプロパティを V に伝えるためだけの
プロパティってなんていうの？
122:デフォルトの名無しさん
12/06/09 11:41:10.30 .net
ごめん、knockout.js の話題はここで良い？
123:デフォルトの名無しさん
12/06/09 11:45:02.52 .net
>>120
NotifyPropertyChanged使わないなら直接Modelのプロパティにバインドしてよくね
124:デフォルトの名無しさん
12/06/09 14:57:44.75 .net
>>122
難読化でいちばん隠したい部分がまる見えになるからオススメできない
プロパティ多すぎて書きたくねぇ！ってならＴ４
125:デフォルトの名無しさん
12/06/09 16:03:19.03 .net
難読化か。難読化なら確かにラッピングは必要かもしれんが
internalなViewModelじゃだめなん？
126:デフォルトの名無しさん
12/06/09 22:58:26.63 .net
ラムダ式からプロパティ名を取り出す方法なら難読化できるよ
127:125
12/06/09 23:02:50.05 .net
ああXAMLには影響が出るから無理か
インターフェイスが曝されるだけなら別によくない?
VMでラップしまくるのも大差ないと思うが
128:デフォルトの名無しさん
12/06/10 02:20:40.65 .net
まあ全部ラッピングしたらしたでやっぱり中身の名前はそのまま出てくるわけだしな
それなら直接Model繋げた方がいい
129:デフォルトの名無しさん
12/06/10 19:31:10.74 .net
ふむ。
URLﾘﾝｸ(www.mnow.jp)
確かにナビゲーションなんかは、MessengerやBehaivorで解決できはするんだけど、
VVMの責務としてどうなのかとか、MVVMというよりもBlend至上主義になりすぎているのではと思うことはあって。
何かしら別の層があっても良いと感じてはいたが。
それをPと呼ぶかどうかはともかく。
130:デフォルトの名無しさん
12/06/10 19:42:58.13 .net
世の中にはコードビハインドというものがあってだな
131:デフォルトの名無しさん
12/06/10 20:08:46.96 .net
コードで書くかと、コードをどこに書くかは全然違う話であってだな
132:デフォルトの名無しさん
12/06/10 20:22:58.07 .net
ところでVS2012のデザイナはBlendベースで刷新されて前と比べ物にならないくらい良くなってるぞ
アニメーションやテンプレートやリソースの編集にはBlendがまだ必要だけど
MVVMのV作るときにはそろそろBlendいらないと思う
133:デフォルトの名無しさん
12/06/11 07:53:21.15 .net
>>121 のやつ
URLﾘﾝｸ(en.m.wikipedia.org)
URLﾘﾝｸ(knockoutjs.com)
SilverlightとKnockoutJSの比較
URLﾘﾝｸ(www.codeproject.com)
134:デフォルトの名無しさん
12/06/11 09:04:31.43 .net
コマンドもバインディングできて、シンプルなテンプレートも付いてるのはいいな。
なかなか使いやすそうな感じだね。これは確かにMVVMだ。
質問とかだったらWeb制作板のライブラリ質問スレが適当かな。
135:デフォルトの名無しさん
12/06/11 09:12:27.73 .net
WebはWebでもJSはクライアント側でUIを扱うからMVVMなんだな
136:デフォルトの名無しさん
12/06/12 01:28:10.49 .net
VS2012になると ビュー モデルは Portable Library でサポートされるそうだ、VM と M は可能な限り Portable Library に押し込んでマルチプラットフォーム化を目指せるのか。
137:デフォルトの名無しさん
12/06/12 02:06:46.27 .net
VMが厚くなるな
138:デフォルトの名無しさん
12/06/12 02:23:38.61 .net
MetroとWPFでVM使い回しはきついだろ
ギャップが大きすぎるから、大量のコードビハインドでVMを相当抽象化することになるか
互換性のためにどっちつかずでプラットフォームの空気を読まない不自然なUIになりそう
139:デフォルトの名無しさん
12/06/12 07:04:36.86 .net
Portable Libraryは別に良いんだけど、別にVMのマルチプラットフォーム対応を目指す必要は無いと思うんだよね。
使用するビューのテクノロジーやデバイスが異なればVMに求められる構造だって変わってくるし。
WebのMVCでPCサイトとモバイルサイトで同じControllerを使う、程度には面倒で制約が多い気がする。
むしろマルチプラットフォーム化できるんならしたいのはMじゃね？
140:デフォルトの名無しさん
12/06/12 12:49:34.16 .net
Livet で、Winodws.Loaded 時にコマンド発行させたいんだが、どうすればいいの？
WindowAction みたいなので、コマンドを発行するだけの Action があればいいだんけど、
見つからなかった。
自分で作るしかない？
141:デフォルトの名無しさん
12/06/12 13:12:31.77 .net
>>139
i:EventTrigger
i:InvokeCommandAction
142:デフォルトの名無しさん
12/06/12 16:51:30.23 .net
Portable Library に Model を押し込む努力はするべきだ。
Portable Library に押し込むには ViewModel は View にプロパティを提供するだけにせざる負えない。
と書いてどっかで聞いたなと思ったら。 MVPVMパターンあった。
Portable Library に ViewModel と Model を押し込んで View と Presennter をプラットフォーム依存にするのか。
143:デフォルトの名無しさん
12/06/12 17:21:46.72 .net
で、そのPresenterってコードビハインドじゃん、ってなった
144:デフォルトの名無しさん
12/06/12 18:36:18.33 .net
状況によってはPresenter設けてもいいと思う
Viewのサイズや表示位置、グリッドのソート順や列の表示・非表示等を構成ファイルに保存/読み込みさせるのに独立したPresenter設けても可
145:デフォルトの名無しさん
12/06/12 20:43:19.56 .net
Presenterの役割定義が昔に比べて広いものを指すようになってきている気がするのは俺だけ？
IHogeViewを実装しているビューなら、それがWPFだろうがWindows FormsだろうがConsoleアプリだろうが、
HogePresenterから操作できる、みたいなのがMVPのイメージだったんだけど、
コードを書く = Presenterな使われ方が増えている気がするんだけど、MVPってそういうものだったの？
ビュー間にまたがるものやアプリケーション横断的な処理の記述箇所については、
Presenterといわずに別の定義をした方が良いんじゃねと思ったんだけど。
146:139
12/06/12 22:17:28.41 .net
>>140
ありがとう。
Livet 関係なくできたのか、
ぐぐっても出ないわけだ・・・。
147:デフォルトの名無しさん
12/06/13 02:37:56.25 .net
>>142
V->VMが密結合にならないのがコードビハインドとは違うところ
実際やるかどうかは別にしてVMの差し替えが可能
148:デフォルトの名無しさん
12/06/13 10:57:45.00 .net
NVPVMはあくまでMVVMの派生パターン
特殊なコンポーネント使っててViewの負荷が異常に高い場合、有効なパターンだよ
149:デフォルトの名無しさん
12/06/13 12:44:02.37 .net
じゃぁViewにプロパティを提供する入力検証の一部をする以外の、
VMでやっていることを考えてみよう。
非常にめんどくさいコーディングスタイルのコントローラじゃないのか？
150:デフォルトの名無しさん
12/06/13 13:12:22.81 .net
それでいいんだろ
一つのViewを異なる使い方で使いまわすときに
VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
151:デフォルトの名無しさん
12/06/13 13:19:04.84 .net
>>149
> 一つのViewを異なる使い方で使いまわすときに
> VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
え？
一つのViewModelを異なるアーキテクチャで使いまわすときに
Viewごと入れ替えるのは無駄が多いから
の間違いじゃね？
152:デフォルトの名無しさん
12/06/13 13:21:02.28 .net
MVPVMのサンプルも、VM－Mのコンビは汎用性持たせ、Pで差分吸収するサンプルに思えたが
153:デフォルトの名無しさん
12/06/13 13:26:43.72 .net
両方だろ
VがVM、VMとビジネスロジックがそれぞれ密結合しないことでVとVMの再利用性を高めるのがねらい
154:デフォルトの名無しさん
12/06/13 13:30:43.53 .net
こういう意見もありますが
URLﾘﾝｸ(gist.github.com)
155:デフォルトの名無しさん
12/06/13 13:37:22.90 .net
2chの煽りと変わらんだろw
ugayaはこういう説明の仕方を見習うべき
www.global-webnet.net/blogengine/post/2010/02/05/MVPVM-Model-View-Presenter-View-Model-the-natural-evolution.aspx
156:デフォルトの名無しさん
12/06/13 13:40:07.82 .net
VがVMに密結合してしまってるのが問題だといってたぞ。
U氏も遷移を切り離すならしっくりくると書いてある。
VMから遷移を切り離したら何が残るの？
Viewにプロパティを提供する入力検証の一部をする位じゃないの？
157:デフォルトの名無しさん
12/06/13 13:46:36.47 .net
>>155
VがVMに密結合するのはコードビハインドな
それをPに切り出してPを差し替え可能にしてるから密結合しない
158:デフォルトの名無しさん
12/06/13 13:47:19.86 .net
Viewで相互運用使うならMVPVM有りとの話もあるが、実際作業するとコードビハインドしか逃げようがないんだよなぁ～
159:デフォルトの名無しさん
12/06/13 13:49:10.29 .net
コードビハインドってPじゃねえの？
160:デフォルトの名無しさん
12/06/13 15:20:15.29 .net
質問。
VMの第一の目的って、Mの構造をVでバインディングしやすい形に変換した形で持つ事っていうのであってる？
例えば、DBの2次元表の構造を、複雑なViewにバインディングするためLINQで変換する、とか。
なので、Mの構造そのままを表示するようなVだと、VMは単純なラッパに見えてしまう。
161:デフォルトの名無しさん
12/06/13 15:27:06.16 .net
Mの構造そのまま表示できる場合においてはVMは不要
162:デフォルトの名無しさん
12/06/13 15:45:57.26 .net
実際に作ってみりゃわかるけど
純粋にＭのプロパティだけでインターフェースは作れない
タブやエキスパンダの状態とか環境設定とかの話ね
めんどくせぇから全部詰め込むってのもありだけど
無駄に一緒にするのは保守性を悪くする
どうせそこらへんはほとんどラッパなんだから
書くのがめんどくさい部分は全部Ｔ４使えとＴ４
163:デフォルトの名無しさん
12/06/13 15:51:40.10 .net
T4使いづらいって印象しかないんだが、なんか間違ってる？
164:デフォルトの名無しさん
12/06/13 15:57:40.49 .net
外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ
複数ファイルの処理が面倒なのはわかるが
165:デフォルトの名無しさん
12/06/13 16:36:31.97 .net
>>162
俺も同じ印象だ。
結局MsBuildタスクで、
URLﾘﾝｸ(d.hatena.ne.jp)
の様な属性からコードを生成するようにしたよ。
166:デフォルトの名無しさん
12/06/13 17:01:14.95 .net
どうもこうも
ViewModelBase<T>から派生してたら
partialでTのプロパティを全部ラップしてやればいいのさ
簡単だろ？
Ｔ４で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら
調べろとしかいいようがないが
167:デフォルトの名無しさん
12/06/13 17:10:39.16 .net
リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね
168:デフォルトの名無しさん
12/06/13 17:23:42.40 .net
> Ｔ４で自分のプロジェクトからリフレクション
このあたりは、みんなどの方法を採用してる気か聞いてみたいね。
俺はWPFのコンパイルプロセスを見習って、
自分自身を一度ビルドしてからCecilでアセンブリにアクセスしてる。
他にも
Cecilではなく普通のリフレクションAPIを使ったり、
ビルドせずにRoslynやNRefactoryを使ったりという方法もあるけど
こっちを使ってる人もいるのかな？
169:デフォルトの名無しさん
12/06/13 17:36:11.05 .net
>>166
アセンブリがアンロードできない・・・と来れば、あとはわかるな？
そう、AppDomainの出番だ。
170:デフォルトの名無しさん
12/06/13 17:39:54.72 .net
>>168
おい、やめろ
AppDomain芸をよりにもよってT4でとか地獄過ぎる
RoslynはまだCTPだしT4上で現実的なところで言えばCecilだろうな
コード生成じゃなくてポストプロセスでのIL書き換えでよければPostSharpなんかも選択肢に入るが
171:デフォルトの名無しさん
12/06/13 18:07:49.37 .net
うん、AppDomainは無い
まだ別プロセスを起動した方がマシ
172:デフォルトの名無しさん
12/06/13 20:42:48.42 .net
PostSharpとか使ってやるのがお手軽？
自前でTaskを作ってビルドプロセスに追加する方が良い？
173:デフォルトの名無しさん
12/06/13 21:09:57.27 .net
一番手軽なのは某氏のDSL
174:デフォルトの名無しさん
12/06/13 21:11:07.57 .net
Castle.DynamicProxyでいいわ
コード生成だるい
175:デフォルトの名無しさん
12/06/13 23:33:29.53 .net
>>172
えむなうさんの？あれってC#専用だよね？
176:デフォルトの名無しさん
12/06/13 23:47:53.09 .net
T4使ったら、少なくともテンプレートのコードが
コンパイルされた結果のアセンブリはロードされるはずだろ
だからもともと別AppDomainで実行されるようになってるから
普通にロードして問題ないんじゃないの?
177:デフォルトの名無しさん
12/06/13 23:50:14.79 .net
>>174 VB.NETやF#とか茨の道だし、C#で普通に使えれば問題ないだろ？
179:デフォルトの名無しさん
12/06/13 23:51:37.83 .net
必要ならVB作れってCodePlexかBlogでリクエストすればいい。
まさかJavaScriptやF#じゃないよな。
180:デフォルトの名無しさん
12/06/14 00:07:25.99 .net
リフレクションでやるんならわかるけど、いちいちDSLでプロパティ定義するんだったら
public virtual int Hoge { get; set; }
としといてCastleのDynamicProxyで変更通知を自動実装させればいいと思うよ
181:デフォルトの名無しさん
12/06/14 00:14:39.91 .net
>>176
VB.NETは茨の道でもなんでもないんだが？
182:デフォルトの名無しさん
12/06/14 00:16:41.28 .net
>>178
プロパティ追加・Hoge・int の3ステップでできる。
赤シャツの嫌いなAOPで実装することもあるまい。
183:デフォルトの名無しさん
12/06/14 01:42:25.17 .net
VB続けたい奴がXAMLに手を付けるのが不思議だわ
184:デフォルトの名無しさん
12/06/14 08:06:59.93 .net
>>181
それは偏見。いまのVBはC#と比べて大差ない程機能強化されとる
185:デフォルトの名無しさん
12/06/14 09:14:33.85 .net
>>176
むしろすべてF#で作りたいんだが。
VMまではF#でやってる。
186:デフォルトの名無しさん
12/06/14 13:20:58.33 .net
MS自身はVBにも力を入れてるけど、周りが付いてきていない。
サンプルがC#でのみ提供ってのもよく見るし、
MonoはVBコンパイラを非サポートにしつつあるし。
187:デフォルトの名無しさん
12/06/14 13:24:58.84 .net
F#は面白そうだね。
計算式で上手くリアクティブプログラミングができたら
相当VMが作りやすくなりそうな予感がする。
けど、茨の道には違いないだろう。
IDEの支援は弱いし、ライブラリの中にはC#の文法で使うことが前提のようなものもあるし。
188:デフォルトの名無しさん
12/06/14 20:01:18.03 .net
VBにいくら機能を追加しても言語仕様が腐ってるから駄目だよ
それにどうせ新機能が増えるたびに「冗長な予約語導入→C#より利便性が下がる」って悪循環でしょ
189:デフォルトの名無しさん
12/06/15 01:35:08.89 .net
VBのラムダ式とか狂った文法だし、機能面だけはC#と対等にしてるけど、もはやボロボロでしょ
190:デフォルトの名無しさん
12/06/15 10:44:01.68 .net
言語がどうの以前に、MVVM的インフラとして
他人のコードが重要になるから少数派は厳しい
191:デフォルトの名無しさん
12/06/15 11:55:14.41 .net
>>186
予約語増えるたびIDEが支援強化するからあまり不便に感じないのも事実
XAML開発の場合、IDEがどれだけその言語をサポートしているかが最重要
そういう意味でF#は終わってるとしかいいようがない
192:デフォルトの名無しさん
12/06/15 13:19:16.42 .net
VBはVB2005のように、厨言語と呼ばれてもいいから
VBらしさを重視していた頃のほうが健全だった
C#のクローンに成り下がったVBに存在意義はもう無い
193:デフォルトの名無しさん
12/06/15 13:53:34.63 .net
>C#のクローンに成り下がったVBに存在意義はもう無い
そんなことばかり言うからC#厨は嫌われるんだよ
おまえが存在意義感じなくても俺には必要なの！引っこんでろタコ！
194:デフォルトの名無しさん
12/06/15 13:55:47.35 .net
VBはクラシックVBとの互換性を維持したいのかしたくないのかよくわからないはじまり方をしたのが最大の失敗だったな
せっかくのしがらみを捨てる最大のチャンスを逃してしまった
195:デフォルトの名無しさん
12/06/15 13:56:55.90 .net
>>191
でもまぁ今から.Net始める場合はVB.NetじゃなくてC#選ぶんちゃう？
196:デフォルトの名無しさん
12/06/15 13:59:50.60 .net
>>192
言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい
とはいえVB６との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない
197:デフォルトの名無しさん
12/06/15 14:00:50.13 .net
>>193 VB.NETに移行する案件、山ほどあるんだが
199:デフォルトの名無しさん
12/06/15 14:37:26.30 .net
VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな
200:デフォルトの名無しさん
12/06/15 14:51:15.90 .net
>>196
でしょｗ でも変にForms覚えてる奴より
「こ れ が .NET じ ゃ 定 番 だ か ら」
と言えば、素直に話を聞いてくれるのから嬉しい
201:デフォルトの名無しさん
12/06/15 14:59:21.72 .net
Forms直に行ってデフォルトインスタンス触られるよりいいのか
202:デフォルトの名無しさん
12/06/15 15:15:25.52 .net
>>194
開発に使う分には問題ないが、言語チームがかなり苦労してそうなのが構文とかからにじみ出てくるぜ・・・
203:デフォルトの名無しさん
12/06/16 04:16:43.61 .net
VB（.NETじゃない方）も未だに元気だからなぁ
PHPがじわじわ下がってきてVBと逆転してしまった。
今はまだ一時的な物だけど今後数ヵ月かけて順位が入れ替わりそうだとか何とか。
URLﾘﾝｸ(www.tiobe.com)
204:デフォルトの名無しさん
12/06/16 12:32:05.90 .net
実はMVVMってしっくりこないんです！
わたしはこれまで、C/C++、Visual Basic、最近になって Java、C# などの言語を使ってきた。
「自分でViewModelを作ってMVVMっぽいことをしている」なんてことはまったくない。
特に「Visual Studioでポトペタ開発ができる」ということ知ってからは、従来のVB6のように開発している。
共有変数も、pubulic staticで宣言する。したがってプロパティなんて作らない。
自称上級者のコードを見ると、いちいちM・V・VMのクラス分けをしているので笑ってしまう。
データベースにアクセスするアプリケーションをを書いているのだが、Visual Studioが供給している
機能を使えばMVVMなど使わなくてもできてしまうのだから。
205:デフォルトの名無しさん
12/06/16 12:40:31.71 .net
なにおじさん？
206:デフォルトの名無しさん
12/06/16 13:20:33.52 .net
何のコピペだっけそれ
207:デフォルトの名無しさん
12/06/16 14:14:46.22 .net
懐かしいなｗ
208:デフォルトの名無しさん
12/06/16 17:03:22.48 .net
オブジェクト指向か
209:デフォルトの名無しさん
12/06/16 17:52:59.93 .net
VMのコストが高いのは事実
210:デフォルトの名無しさん
12/06/16 23:27:28.75 .net
Livet で Drag and Drop やりたいんだけど、どこかにサンプルないですか？
211:デフォルトの名無しさん
12/06/17 11:27:52.39 .net
時間の無駄だと思わないの?
お前がMVVM教の修験者か何かでないならコードビハインドを使え
212:デフォルトの名無しさん
12/06/17 14:45:06.19 .net
Dropイベントを処理したいだけなら>>139-140
213:デフォルトの名無しさん
12/06/17 16:08:05.74 .net
イベントだけ拾っても仕方ないでしょ
素直にコードビハインドを書くか、
Dropイベントを受け取って引数にデータ入れてバインドしたVMのコマンドを呼ぶ
ビヘイビアを作りましょう
214:デフォルトの名無しさん
12/06/21 18:57:52.75 .net
MVVMって誰が提唱しだしたの？
215:デフォルトの名無しさん
12/06/21 19:34:30.00 .net
MSの中の人
216:デフォルトの名無しさん
12/06/21 19:36:38.56 .net
ビヘイビアに書くと再利用性が上がるってだけで中身はコードビハインドと大して変わらんしな
まあD&Dはどっちにしても面倒だが
217:デフォルトの名無しさん
12/06/21 22:54:05.30 .net
コードビハインド書くと、VからVMアクセスするでしょ？
それがかっこ悪いのよね～
218:デフォルトの名無しさん
12/06/22 23:26:34.40 .net
VからVMにアクセスするのはコマンドも一緒だと思うが…
219:デフォルトの名無しさん
12/06/23 07:54:12.87 .net
つーかほぼすべてVからVMへのアクセスだろが。
220:デフォルトの名無しさん
12/06/23 09:25:51.09 .net
VMはVを知らないがVはVMを知っている
221:デフォルトの名無しさん
12/06/23 11:10:17.65 .net
こんにちは！VMさん。
あなたは、Vさんにフォローされてます。
Vさんをフォローしますか？
する
→しない
222:デフォルトの名無しさん
12/06/23 11:29:14.41 .net
MVCのCとMVVMのVMって何が違うの？
データを扱うMと画面を扱うVがいて、それらを制御するCでしょ？
VMもCもいっしょじゃん。
223:デフォルトの名無しさん
12/06/23 15:06:23.66 .net
>>219
ASP.NET MVCを想像してみろよ
あれはCとVMの両方を持つが、どう見ても同じものじゃないだろ
224:デフォルトの名無しさん
12/06/23 15:13:22.96 .net
>>220
それが理解できていれば聞かずに済んでいるんだ、無能ですまん。
225:デフォルトの名無しさん
12/06/23 15:30:26.15 .net
VMってのは、Vから扱いやすいインターフェイスを備えたMのラッパーだよ
Vを制御したりなんかしない
226:デフォルトの名無しさん
12/06/23 15:57:05.63 .net
Vを制御するのは誰？
簡単な話、Viewにある文字をModelでなんかした結果で変えたいみたいな。
227:デフォルトの名無しさん
12/06/23 16:02:41.88 .net
V自身がバインディングで変える
228:デフォルトの名無しさん
12/06/23 19:19:17.03 .net
MVCだとVは入力を扱わない
229:デフォルトの名無しさん
12/06/24 17:03:07.28 .net
Mの状態でフォーカス位置を変えたりするのがめんどい
230:デフォルトの名無しさん
12/06/24 17:04:30.15 .net
SとMの関係を一言で言うと？
231:デフォルトの名無しさん
12/06/24 18:36:15.75 .net
rot(M, -π) = S
232:デフォルトの名無しさん
12/06/24 21:45:32.65 .net
Vを制御するのはVMだろ
Vの状態を持つためのMなんだから
233:デフォルトの名無しさん
12/06/25 14:05:28.44 .net
VMがVを制御しないんならVを制御する別のオブジェクトが必要だな
そうだなープレゼンターとかいう名前にするといいんじゃね？
234:デフォルトの名無しさん
12/06/25 15:04:10.95 .net
「MVVMパターンで学ぶGUIアーキテクチャパターン」? .NETラボ勉強会で話してきました！
URLﾘﾝｸ(ugaya40.net)
235:デフォルトの名無しさん
12/06/25 18:19:46.52 .net
Mのプロパティをラップすることがあるのは、MVVM関係なく、隣人とだけ話せっていうOOPの作法だよな
MVVM的には別にどっちでもよくて、やっぱりVMの本質はVの状態を持つことだよ
236:デフォルトの名無しさん
12/06/25 22:39:40.76 .net
従来のウェブアプリ（Ajaxアプリ除く）、
ウェブフレームワークといったらいいかな？
で、MVVMを使うメリットある？
237:デフォルトの名無しさん
12/06/25 22:50:54.35 .net
JSのか？
238:デフォルトの名無しさん
12/06/25 22:54:54.79 .net
JS関係なくて、普通のフォーム使った
ウェブアプリ。
239:デフォルトの名無しさん
12/06/26 00:01:38.39 .net
数ある既存の素晴らしいMVC系フレームワーク(あくまでWebでいうMVCね)
に乗せられるというメリットを捨ててまで使うほどのメリットは無いと思う
240:デフォルトの名無しさん
12/06/26 00:15:01.78 .net
ASP.NET MVCにはViewModelと呼ばれるものがあるけど
ステートレスでただVと1対1なだけのデータの入れ物だからMVVMとは別物だと思う
241:デフォルトの名無しさん
12/06/26 00:17:39.51 .net
MVVMはVが入力を扱う場合において威力を発揮する
WebのサーバサイドだとVは入力を扱わないし、MVCはVではなくCが入力を扱う
242:デフォルトの名無しさん
12/06/26 00:20:17.19 .net
あと選択状態とかだろ
ステートレスなVMはただのMだ
243:デフォルトの名無しさん
12/06/26 00:41:58.72 .net
そもそもウェブアプリってMVCじゃないだろ？
データとってきてテンプレートに入れるだけじゃん。
244:デフォルトの名無しさん
12/06/26 19:38:03.37 .net
何を突然スレ違いなことを
245:デフォルトの名無しさん
12/06/26 20:46:48.60 .net
>>233でウェブアプリの話してるじゃん。
ちゃんと読まないでレスするの良くないよ。
246:デフォルトの名無しさん
12/06/26 20:53:00.50 .net
ここはMVCのスレではないし、クライアントとWebのMVCが同一だと言ってる奴も居ないけど
247:デフォルトの名無しさん
12/06/26 20:57:02.48 .net
このスレの1/10には
MVCという単語が含まれているが？
MVCのスレじゃなくても
MVCと比較するのだからなんの問題もないだろ。
248:デフォルトの名無しさん
12/06/28 18:23:25.38 .net
コミュ障って生きていくの大変そうだな。
249:デフォルトの名無しさん
12/06/29 00:08:52.57 .net
そうだな。そういうことにしておけば？
250:デフォルトの名無しさん
12/06/29 14:32:07.81 .net
そこはもちょっと親身に相談に乗ってあげなきゃ
245が自殺でもしたら大変だろ
251:デフォルトの名無しさん
12/06/29 15:32:22.10 .net
ちょっと死にたい
252:デフォルトの名無しさん
12/06/29 16:26:05.86 .net
コードビハインドさえ書かなければ死なない
253:デフォルトの名無しさん
12/06/29 17:17:54.12 .net
いや、別に責務さえはっきりしていれば、別にコードビハインド書いてもいいんだよ。
MVVM≠コードビハインドはよくある誤解なので、ご注意を。
254:デフォルトの名無しさん
12/06/29 20:05:40.23 .net
>>250が≠の意味を誤解しているのは分かった
256:デフォルトの名無しさん
12/07/01 09:58:01.85 .net
LivetってPrismにあるようなナビゲーションスタイルのアプリケーションには対応してないよね
アホみたいに時間かかってる割には全体的に…
257:デフォルトの名無しさん
12/07/01 10:29:40.96 .net
お前は何を言っているんだ
258:デフォルトの名無しさん
12/07/01 10:44:49.81 .net
>>253
ウインドウ内で画面遷移するやつ(PrismのRegionみたいなの)
できるなら教えてほしい
259:デフォルトの名無しさん
12/07/02 02:00:05.07 .net
個人製作のフレームワークがごく限られたケースにしか対応してないのはよくあること
配慮してくれないと
260:デフォルトの名無しさん
12/07/02 17:16:37.30 .net
ContentControlでも使ってろ
261:デフォルトの名無しさん
12/07/04 01:06:26.25 .net
Livetの中の人、ついったーがキモい・・・
262:デフォルトの名無しさん
12/07/04 01:21:34.90 .net
WebMVC
URLﾘﾝｸ(d.hatena.ne.jp)
263:デフォルトの名無しさん
12/07/04 10:36:51.30 .net
>>153みたいなことしちゃうアレな人だからな
264:デフォルトの名無しさん
12/07/04 15:31:22.65 .net
いやなら反論してみればいいんじゃね
265:デフォルトの名無しさん
12/07/04 15:43:14.21 .net
例の人は目先の細かい実装に囚われすぎなんだよ
>>154で説明されているような
・VMをビジネスロジックに依存させないことによるVMの再利用性の向上
・VをVMに依存させない(つまりVMを直接触るようなコードビハインドを書かない)ことによるVの再利用性の向上
・Pは差し替え可能
・DIとの相性
と言ったことに全く触れられていない
266:デフォルトの名無しさん
12/07/04 15:56:30.88 .net
直接言って来いよ
ここでやんな
267:デフォルトの名無しさん
12/07/04 18:25:12.71 .net
技術的な話はここでいいだろ。
性格批判は向こうでどうぞ。
268:デフォルトの名無しさん
12/07/04 18:36:48.98 .net
そうそう、そのためのスレなんだから
MVPVMのサンプル見ると、三つのプラットホームでVMを共通化してる
VとVMの疎結合のためにPを設けてるわけだが、
現実的に考えると、VMの共通化を図る要件って実際あり得るのだろうか？
269:デフォルトの名無しさん
12/07/04 18:44:57.68 .net
>>154のリンク先の例にあるような、同じV-VMペアを別の用途で使いまわすっていうのは
割とあるんじゃないかと思う
270:デフォルトの名無しさん
12/07/04 19:12:57.94 .net
VMの共通化は無い派。
デバイスが変われば見た目も変えたくなるし、全てのデバイスで使えるスーパーセットのVMもどうかと思う。
Mが可能な限り共有できればそれでよいと思う。
271:デフォルトの名無しさん
12/07/04 19:25:18.53 .net
要件によるけど、スーパーセットのVM使えるところも多々あるんじゃない？
使えないところだけVMを個別作るとかが望ましいなぁ
272:デフォルトの名無しさん
12/07/04 19:42:38.71 .net
最近客に「文字大きくしてくれ」って言われてVだけコピペしたよ
273:デフォルトの名無しさん
12/07/04 22:00:23.71 .net
ねぇ。これがどうウェブアプリに使えるの？
274:デフォルトの名無しさん
12/07/04 22:17:08.46 .net
ステートフルなGUIを作るためのものだからサーバーがHTML吐くだけのアプリには無意味
SilverlightやAjaxなら普通に使える
275:デフォルトの名無しさん
12/07/04 23:22:11.82 .net
うがやって彼女いるの？
24時間キモイことつぶやいてるよね 。
さっきも、アスペルガー丸出しだった。
彼女どころか友達いなそう。
276:デフォルトの名無しさん
12/07/04 23:38:25.94 .net
個人攻撃に走るのはいかがなものか。
277:デフォルトの名無しさん
12/07/05 00:22:46.48 .net
>>272
今Twitter見てみ？
完全にアスペだぜ？
278:デフォルトの名無しさん
12/07/05 01:34:01.44 .net
何言ってるのかはみてないが24/7ではなかったな
日付が飛んでたから
279:デフォルトの名無しさん
12/07/05 01:42:41.83 .net
技術的な突込みならともかく、スレに関係ない話で個人攻撃はいくない
280:デフォルトの名無しさん
12/07/05 07:05:45.91 .net
個人の話がしたければヲチ板へ。
アスペの話がしたければメンヘラ板へ。
281:デフォルトの名無しさん
12/07/05 07:37:21.07 .net
ウガヤ氏に罵倒された勘違いMVVMerなんですね。わかります(´・ω・｀)
282:デフォルトの名無しさん
12/07/05 15:11:50.
283:77 .net
284:デフォルトの名無しさん
12/07/05 19:40:28.20 .net
煽り耐性ゼロだから2ch無理とか言ってたけど
正直あのエントリに比べたらここやWPFスレの方がマイルドw
285:デフォルトの名無しさん
12/07/05 20:43:53.52 .net
いやさすがにそれはない
286:デフォルトの名無しさん
12/07/05 20:46:14.32 .net
ム板は煽られても他人の振りが出来るからなあ
287:デフォルトの名無しさん
12/07/05 21:23:08.74 .net
ここってJavaFXの話題もあり？
288:デフォルトの名無しさん
12/07/05 22:08:33.80 .net
ありじゃね
289:デフォルトの名無しさん
12/07/05 22:53:24.29 .net
JavaFXが最初に世に出た当時はなんでXMLじゃなくてわざわざ独自スクリプトなんだ
ボケカスと言われてたが、デザイナとプログラマの分業なんて幻想であって
ある程度ビューに振る舞い書けた方が便利だということを見越した判断だったんだな
XAMLのビヘイビア地獄よりははるかにマシだわ
290:デフォルトの名無しさん
12/07/05 22:57:52.73 .net
今FXやるぐらいならSLでいいわ
291:デフォルトの名無しさん
12/07/05 23:14:34.76 .net
ビヘイビア地獄ってなんだよ
そんなに地獄に感じるならコードビハインドにコード書いたっていいんだぞ
292:デフォルトの名無しさん
12/07/06 00:55:22.61 .net
.triggerを手で書くのはうぜぇっていうのは同意するが
あれはblendで書く物だろ
293:デフォルトの名無しさん
12/07/06 01:54:31.30 .net
ビヘイビアもトリガーもｲﾝﾌﾗが整った環境じゃないとまともに使えん
自力で整えようとすると相応の労力が強いられる
遊びや自己学習でする分には良いけど、サクッと作りたいときや仕事だと２の足を踏むなー
Blendみたいな環境が無いと本気で使おうとは思わない
コードビハインドでもMVVM自体は可能だから手っ取り早く作りたいときはコードビハインドで良いだろ
294:デフォルトの名無しさん
12/07/12 00:19:31.36 .net
MVVMってプラガブルMVC劣化させたのと同じじゃねぇの？
プラガブルMVC劣化版と何が違うの？
295:デフォルトの名無しさん
12/07/12 00:36:47.13 .net
XAMLのこと知らないなら黙ってろ
296:デフォルトの名無しさん
12/07/12 10:06:32.25 .net
非同期処理ってモデルでSynchronizationContextとか使って面倒見たほうがいい?
それともやっぱりモデルの状態が複雑になるのは避けてVMでスレッド動かす?
297:デフォルトの名無しさん
12/07/12 10:13:46.36 .net
ポリシー次第じゃない？
モデルまではそのへんを気にせずガンガン使う→VMで考慮
VMはシンプルに作りたい→上で考慮
自分は前者だな。
298:デフォルトの名無しさん
12/07/12 18:25:57.29 .net
モデルで非同期してVMではメインスレッドが普通じゃない？
ViewからVM呼ぶんだし
299:デフォルトの名無しさん
12/07/12 18:51:53.23 .net
UIにアクセスするとことか内部の状態を変えるとかだけVMでContextで同期取ればいいやん
300:デフォルトの名無しさん
12/07/19 21:22:47.22 .net
DIコンテナは何がいい?
UnityとNinjectとAutofac試してAutofacが気に入ったんだけど
301:デフォルトの名無しさん
12/07/21 17:29:43.89 .net
>>290
なんの関係が？
302:デフォルトの名無しさん
12/07/24 05:21:39.59 .net
Livetの新しいの公開されたけど、これ、
旧バージョンインストールして作ってたアプリある場合、
新しいLivet入れても問題ないのかな?
旧バージョンのままじゃないと動かなくなるとかだと困る
303:デフォルトの名無しさん
12/07/24 06:12:23.43 .net
Livetのプロジェクトテンプレート使ったんならLivet.dllのローカルコピーがあるべ。
304:デフォルトの名無しさん
12/07/24 06:28:21.45 .net
それだと古い方のdllも残しておかないといけないってこと?
新しい方に差し替えたらそのまま動かないのかな…
新しいPCにVisualStudioとLivetの新しいのだけ入れたら、
旧バージョンで作ったアプリの修正とかはできなくなる?
上書きインストールしていいのかとか、
そこら辺、公式サイトに何も書いてないから怖くて入れられない
305:デフォルトの名無しさん
12/07/24 08:16:05.78 .net
>>299
ここに書くよりも直接連絡しろよｗ
306:デフォルトの名無しさん
12/07/24 08:39:50.00 .net
Livetのテンプレート使って作ったプロジェクトならInfrastructureAssembliesフォルダにいままでのLivet.dllはそのままあるし
参照設定もそれを参照しているから自分で明示的に置き換えない限り新しいバージョンのLivetを入れてもそいつのバージョンはそのまま
自分でProgram FilesにあるLivet.dllに参照設定してたらアップデートしたらアップデートしたバージョンのものになる
また新しいものに差し替えたとしても破壊的変更があるものはそのままでは動かないし、特定バージョン参照してたらたとえ破壊的変更がなくともリビルドが必要
Livetに限らずライブラリ使うときの基本的なことだと思うが
307:デフォルトの名無しさん
12/07/24 10:53:05.83 .net
>>300
諸般の事情で直接連絡したくない場合もあるんだよ
そのための2chだろうが
308:デフォルトの名無しさん
12/07/24 13:52:17.88 .net
んなわけねーだろ
捨てアカで報告してこい
309:デフォルトの名無しさん
12/08/08 10:33:09.91 .net
MVVMerなら即VS2012にするよな？
310:デフォルトの名無しさん
12/08/08 10:47:52.07 .net
それはあんまり関係ないな
311:デフォルトの名無しさん
12/08/08 19:08:07.03 .net
MVVMerとかフルMVVMとか、日本だけの造語が目立つな
312:デフォルトの名無しさん
12/08/08 19:16:36.34 .net
2012というか.NET4.5だとXP切り捨てになるのが
313:デフォルトの名無しさん
12/08/08 19:20:24.35 .net
>>307
です。
VB6ランタイムはWin8でも動くと言うのに酷い話だ。
314:デフォルトの名無しさん
12/08/08 19:33:31.78 .net
MVVMはWindows7以降用技術です
315:デフォルトの名無しさん
12/08/08 23:10:28.72 .net
いいえ、ウェブ技術(JavaScript)です。
URLﾘﾝｸ(ameblo.jp)
knockout.js (URLﾘﾝｸ(knockoutjs.com))
knockout.jsはMVVM（Model-View-ViewModel）パターンのフレームワークです。
双方向データバインディングやアイテムテンプレート等の機能があり、SilverlightやWPF開発者にはかなりとっつきやすいフレームワークだと思います。
316:デフォルトの名無しさん
12/08/10 00:03:20.35 .net
Win8でも動作するし、VB6でのMVVMまだ？
317:デフォルトの名無しさん
12/08/10 00:29:56.78 .net
パターンにまだ？って言われても
自分でやることじゃねーのか
318:デフォルトの名無しさん
12/08/10 00:44:36.96 .net
vb6でも普通にMVVMできるだろう
Observerやビヘイビア作るのが難儀な気がするからコードビハインド主体になりそうだけど
319:デフォルトの名無しさん
12/08/10 10:33:45.16 .net
おまいら、なにか根本的に勘違いしてるだろ
320:デフォルトの名無しさん
12/08/10 12:38:35.91 .net
誰に言ってんの
何を言ってんの
321:デフォルトの名無しさん
12/08/10 13:57:56.40 .net
MVVMの定義に相当するものはVB6ではできんだろ。
MVPも厳しい。
おとなしく、モジュール分割をちゃんとした昔ながらのC/Sシステムっぽくやっていろ。
…っという話かな？
322:デフォルトの名無しさん
12/08/10 22:33:15.87 .net
クラスをちゃんと定義すりゃできるだろ
ライブラリで用意されてるインフラ全部自分で作らにゃならんけど
323:デフォルトの名無しさん
12/08/10 22:48:20.32 .net
VB6の仕様だけでインフラ作るのは厳しくないかね？
いや、API使ってフックレベルからやれば、そりゃ出来るだろうけど
324:デフォルトの名無しさん
12/08/10 22:52:44.04 .net
MVVMのどういう場面だ？
325:デフォルトの名無しさん
12/08/11 01:28:16.52 .net
VBだとクラスモジュールから
イベント送信できるんだから
MVVMは実装しやすい方法言語だよ。
326:デフォルトの名無しさん
12/09/08 12:02:20.04 .net
可能性とかで語られてもな。
実際にそれを VB6 でやる気になるかい？ って話も重要だろ
327:デフォルトの名無しさん
12/09/08 12:30:15.15 .net
「VB6 を やる気にならない」が正解
328:デフォルトの名無しさん
12/09/08 12:58:28.48 .net
VBってまだ絶滅してないのか
何のためにMSはC#出したんだ
329:デフォルトの名無しさん
12/09/08 23:34:49.46 .net
MSほど多様な製品を長期に渡ってサポートしてくれるとこは他にない。
VB6が世に出てから14年経つがWin8でも公式にサポートされた。
リプレースするにも金がかかるから動く限りは保守しながら使いたいって客は案�
330:O多いよ。
331:デフォルトの名無しさん
12/09/10 11:25:40.15 .net
そういう用途ならhost側で動かなくてもVMで動いてくれりゃ充分なんだが
332:デフォルトの名無しさん
12/09/21 19:02:26.84 .net
VB早く消えてなくならないかなー
MSもサクッと切ればいいのに
333:デフォルトの名無しさん
12/09/21 19:03:37.99 .net
リプレースに金がかかるかもしれないが保守にも金がかかる
334:デフォルトの名無しさん
12/09/21 20:02:31.93 .net
案外金が掛かった方が良いのかも知れない
払ってくれる相手なら
335:デフォルトの名無しさん
12/09/21 21:11:01.59 .net
VB6からC#へのリプレースおいしいです
336:デフォルトの名無しさん
12/10/06 11:05:26.15 .net
んで MVVMでアプリつくってるやついるの？？？
まじでいらねぇんだが．
337:デフォルトの名無しさん
12/10/08 09:21:35.40 .net
一つの画面でいろいろやるタイプのアプリには向かないのは事実
338:デフォルトの名無しさん
12/10/08 19:09:14.56 .net
一つの画面で色々やるというか、Vの作り込みの比重が多いアプリだとあんま活躍しないわな。
339:デフォルトの名無しさん
12/10/08 20:43:24.80 .net
ツール類には向かんわな
せいぜい複雑なダイアログがあればそこに使う程度
340:デフォルトの名無しさん
12/10/08 21:26:12.25 .net
複雑なウィンドウなら複数のコントロールに分割すればいい話じゃね
341:デフォルトの名無しさん
12/10/13 17:02:29.65 .net
メモリリークする原因がわからない
342:デフォルトの名無しさん
12/10/13 17:08:27.07 .net
イベント
343:デフォルトの名無しさん
12/10/13 19:31:26.75 .net
>>335
メモリを使っている人がいるんじゃないかな
344:デフォルトの名無しさん
12/10/14 16:54:03.98 .net
徐々にウェブの世界でも
MVVMが浸透してきたな。
MVCだけじゃ、いろいろ足りない。
345:デフォルトの名無しさん
12/10/14 17:05:03.26 .net
>>335
こういうのでは？
URLﾘﾝｸ(www.google.co.jp)メモリーリーク&ie=UTF-8&oe=UTF-8&hl=ja
346:デフォルトの名無しさん
12/10/14 20:38:40.26 .net
>>338
Ajaxとかだるすぎ
WebはサーバーでHTMLを垂れ流すだけという低脳さが良いのに
347:デフォルトの名無しさん
12/10/16 00:33:06.45 .net
>>340
テンプレート使ったこと無いの？
サーバーでテンプレートに渡す値を
値そのまま渡せばそれがAjaxになる。
サーバーサイドアプリ - テンプレート処理
なのだから、確実にAjaxの方が簡単になってる。；
348:デフォルトの名無しさん
12/10/16 01:04:33.51 .net
意味がわからない
テンプレートって普通サーバーで使うもんだろ? クライアント側でテンプレート使うってこと?
それがサーバーでやるより簡単だと言える根拠は?
349:デフォルトの名無しさん
12/10/16 01:11:23.92 .net
どっちも簡単だろ。
jQueryみたいなライブラリが充実してきて笑えるぐらい簡単になった。
これが難しいってム板に居られる資質がないとしか思えん。
350:デフォルトの名無しさん
12/10/16 18:10:03.69 .net
>>342
サーバの負荷の関係上、サーバでテンプレートエンジン使わない方がいいとかもあるんだけど、
最近は、サーバから戻ってくるのはJSONオブジェクトとテンプレートで、クライアントでテンプレート
エンジンかましてページを生成する方が良いような気がしてるよ。基本Ajaxで。
受けとったJSONオブジェクトを元に、自力でDOMを書き換えても良いし。
351:デフォルトの名無しさん
12/10/16 20:40:35.72 .net
クライアントが以前より負荷が高くなるという問題もあるけれど、
以前というのはもう十数年前だったら問題になるというレベルで
今はクライアントは十分な性能を持ってるしね。
ブラウザ自体も速くなった。
それに比べるとネットワークはまだまだ遅いわけで、
テンプレートはローカルにキャッシュしておいて
データ量を減らすほうが得策かな。
サーバー負荷も低くなるし。
これぐらいだれでも思っていることで、
普通サーバーでやるもんだろで終わってる人ってのは
何も考えてないとしか思えないけどｗ
352:デフォルトの名無しさん
12/10/16 20:43:20.12 .net
一方Twitterは以前API直接たたいてJSONからDOM生成してたのが最近生成済みのhtml片を鯖から受け取るようになった
353:デフォルトの名無しさん
12/10/16 21:07:29.77 .net
完全なAjaxができるならいいが、
普通そうはいかないもんな
どうせサーバーで生成しなきゃいけないならなるべくサーバーにまとめちゃった方が楽
354:デフォルトの名無しさん
12/10/16 21:18:45.66 .net
どっちみちAjaxは使わないといけないんだから
クライアントにまとめちゃったほうが楽
355:デフォルトの名無しさん
12/10/16 21:24:48.64 .net
Ajaxはオプションだろ
利便性のためにクライアントでAjax使ってバリデーションしたとしても、
どのみちサーバーでもやらないといけない
356:デフォルトの名無しさん
12/10/16 21:30:02.30 .net
Ajaxはバリデーション以外で使うものって
わからないのか？ｗ
バリデーションなら単なるJavaScriptで良い
357:デフォルトの名無しさん
12/10/16 21:31:42.33 .net
>>350
JavaScriptでもいちいちバリデーションするの？
バカ？
358:デフォルトの名無しさん
12/10/16 21:32:50.76 .net
JavaScriptでバリデーションが通ったら
サーバーでは検証せずにそのままDBに入れちゃうの?
やばくねそれ
359:デフォルトの名無しさん
12/10/16 21:34:43.44 .net
話し理解できてないの？ｗ
バリデーションをAjaxで行う＝サーバーで通信して行うから、
そのバリデーションはサーバーでやってる事になるだろうって話だ。
あと、サーバーでやらないなんて一言も言ってない。
なんでこんなに文章読めないの？馬鹿なの？
360:デフォルトの名無しさん
12/10/16 21:36:01.79 .net
サーバとJavaScript両方でバリデーションするの？
マジキチ？
361:デフォルトの名無しさん
12/10/16 21:36:16.18 .net
>Ajaxはバリデーション以外で使うもの
>バリデーションなら単なるJavaScriptで良い
さっきと言ってることが180度違うけど
362:デフォルトの名無しさん
12/10/16 21:38:07.68 .net
うーん？
> Ajaxはオプションだろ
>>349が
オプションでやるって書いてあるじゃん。
みんな最初っから、両方でやるという前提で話してるんだが。
両方でやるのは、レスポンスを早くしてユーザビリティを上げ
無駄な通信を削減するため。言わなくても常識だと思っているが。
363:デフォルトの名無しさん
12/10/16 21:38:54.60 .net
>>355
そりゃ、さっき言った人俺は別人だからねｗ
364:デフォルトの名無しさん
12/10/16 21:40:19.92 .net
みんなって誰？
マジキチは一人で十分なんだがｗ
365:デフォルトの名無しさん
12/10/16 21:40:51.87 .net
>>358
みんな＝お前以外
366:デフォルトの名無しさん
12/10/16 21:41:02.38 .net
ああ、別人という設定なんですね、わかります
367:デフォルトの名無しさん
12/10/16 21:41:14.80 .net
鯖とJS両方で検証するだろうよ
検証はカスタム属性から自動生成でもしたらいいってかそういうのすでにある
368:デフォルトの名無しさん
12/10/16 21:43:13.41 .net
一人だけ、程度の低い人が居ますね
369:デフォルトの名無しさん
12/10/16 21:45:12.56 .net
>>362
自己紹介は結構です
370:デフォルトの名無しさん
12/10/16 21:58:42.34 .net
今時Ajaxだるいと言って済ませられるような、簡単なお仕事をしているぬるま湯な環境うらやましす
コストをかけずにAjaxやJSでのMVVMをどう実現するか試行錯誤している人が多い中で
371:デフォルトの名無しさん
12/10/16 21:59:49.81 .net
×今時Ajax
○いまさらAjax
372:デフォルトの名無しさん
12/10/16 22:12:49.60 .net
クライアントにまとめるとか言って鯖から全件投げつけてクライアント側で検索やらせる奴とかが現れませんように
373:デフォルトの名無しさん
12/10/16 22:16:13.83 .net
>>366
それはさすがに見た事ないけど
ページングせずに数万件の検索結果のレコードを送り付けてくるやつなら見た事がある。
374:デフォルトの名無しさん
12/10/16 22:16:48.57 .net
そのうちJavaScriptでクラサバやるわけですね
375:デフォルトの名無しさん
12/10/16 22:17:15.76 .net
node.js最強
376:デフォルトの名無しさん
12/10/16 22:20:02.67 .net
>>366
ASP.NET素人だとクライアント側にViewStateで全データを保管して、サーバー側でページングとか日常茶飯事だぜ？
377:デフォルトの名無しさん
12/10/16 22:22:07.06 .net
まーた、なんか低レベルの流れになってんなー
378:デフォルトの名無しさん
12/10/16 22:30:55.59 .net
下見てもつまらないよ
379:デフォルトの名無しさん
12/10/17 01:35:57.07 .net
Random Ravings of a Red Headed Code Monkey: Knockout.js Added to the F#/C# MVC 4 Single Page Application Template
URLﾘﾝｸ(bloggemdano.blogspot.jp)
380:デフォルトの名無しさん
12/10/21 22:42:39.1
381:4 .net
382:デフォルトの名無しさん
12/10/21 22:56:05.22 .net
コードビハインドを無理に排除しようとすると、どうしても
特定のビュー専用のビヘイビアがしばしば出てくる。
その場合無駄に煩雑になるだけで実質何のメリットもない。
彼も気付いちゃったんだよ。
383:デフォルトの名無しさん
12/10/22 06:04:37.89 .net
単に自分の考えが甘かった、自分の見える世界だけしか見ていなかった事に気がついただけだろ。
ああいうキャラの人間はだいたいそんなもん。
384:デフォルトの名無しさん
12/10/22 08:48:01.98 .net
MVVMやっててWPFの仕組みがわかってくると、
意外とWPFのコードビハインドってよくできてることに気付くよね
正直、ビヘイビアは再利用できるものだけに限定して積極的にコードビハインド使うのがベストだと思う
385:デフォルトの名無しさん
12/10/22 09:20:38.69 .net
メッセージも多くの場合Vがインターフェイスを実装すれば十分
ﾒﾓﾘﾘｰｸｶﾞｰとか言うけど、そんな大したことじゃないだろ。
参照管理の問題なんてどうせWPF関係ないところでも常に付きまとうのに、
それをコードビハインドの問題であるかのように大袈裟に騒いで、
WPFがまだよくわかってない人に変な先入観を植え付けている。
386:デフォルトの名無しさん
12/10/22 09:41:07.23 .net
MVVMというより、Blend至上主義みたいな話になっちゃってるような所があったからな。
387:デフォルトの名無しさん
12/10/22 12:14:52.36 .net
本人はBlendを第一に考えてるようだしその辺だろうな
388:デフォルトの名無しさん
12/10/24 00:05:27.67 .net
Blend 2012まだかよ
389:デフォルトの名無しさん
12/11/02 12:07:46.01 .net
ViewModelのインターフェイスって意味ある？
390:デフォルトの名無しさん
12/11/02 14:00:24.51 .net
Mや各種サービスからのコールバックに使うとか
コードビハインドでVからVMのメソッドを呼ぶときにV->VMを密結合させたくないとか
そういうときには意味ある
391:デフォルトの名無しさん
12/11/02 14:32:57.66 .net
まあ通常は継承ベースでいいと思う
392:デフォルトの名無しさん
12/11/04 22:35:06.98 .net
>>383
コードビハインドってViewって認識なの？
否定じゃなくて単純に質問。
393:デフォルトの名無しさん
12/11/04 22:49:04.80 .net
Viewとみなすのがふつう
ビヘイビアもコードビハインドの一形態なので同じくView
394:デフォルトの名無しさん
12/11/05 20:21:18.14 .net
結局
vmに置かれるviewに強く関係するけど
共通ロジックの置き場がない
395:デフォルトの名無しさん
12/11/05 23:16:15.79 .net
共通ロジックならUTILとかに置けばいいだろ？
396:デフォルトの名無しさん
12/11/05 23:36:53.45 .net
>>386
Viewとみなすのは分かったんだけど
VMじゃななくてVとみなす理由はなんなのかな？
397:デフォルトの名無しさん
12/11/05 23:38:49.26 .net
>>389
ビューと不可分だから
398:デフォルトの名無しさん
12/11/05 23:45:04.35 .net
>>390
WinFormsのコードビハインドなら不可分といえなくもないけど
WPFはそうともいえないんじゃね？
399:デフォルトの名無しさん
12/11/05 23:51:07.82 .net
>>391
この場合の不可分は「単体テスト可能かどうか」な。
ユーザーコントロールやウィンドウのクラスに対してXAMLを差し替えることは普通はできないし
無理矢理読み込むファイルを変えたとしてもコードビハインドからコントロールを直接触ってるから
結局ビューを表示して実際に操作してみないとテストできないわけ。
だからコードをビューから分離してビューなしでテストできるようにしましょうっていうのがVM。
400:デフォルトの名無しさん
12/11/06 00:03:14.09 .net
>>392
なる
401:ほどねー
402:デフォルトの名無しさん
12/11/06 00:05:46.84 .net
>>387
ViewModelsってフォルダにそういう機能のクラスを作ればええんや
まーそもそも、Views、ViewModels、Modelsってフォルダ群もなんだかなーって気もするが
そのほかのフォルダ構成でやってるやつおる？
403:デフォルトの名無しさん
12/11/06 03:50:39.94 .net
フォルダ分けない方が楽な気はするがその3つにしてるな
404:デフォルトの名無しさん
12/11/06 15:16:09.04 .net
М氏も「MVVM＝コードビハインド無し」みたいな誤解撒き散らしてたし
「フルMVVM」って造語が誤解生んだのも事実
でもだからなんなの？勝手に誤解してずっこけたの本人のせいじゃん
お前が元信者だから裏切られた感強いだけだろ
405:デフォルトの名無しさん
12/11/06 16:34:58.61 .net
dynamicを積極的に使うのはどうだろう
VMがdynamic型でVへの参照を保持して動的にVのメソッドを呼ぶようにすれば、
メッセージやインターフェイスを介さなくてもVM->Vの密結合が避けられる。
dynamicなら完全に透過的なプロキシが使えるから、たとえばメモリリークの恐れがある箇所は
WeakReferenceでビューへの参照を持ち、ビューがGCされたらnullオブジェクトとして振る舞う
ようなプロキシを利用すれば、メモリリークの問題もコードの見た目を全く汚さずに解決。
型無しがダメだというならメッセージだって同じようなもんだよね。
(Vが当該メッセージをサポートしているかどうかはコンパイル時にチェックされないという意味で)
406:デフォルトの名無しさん
12/11/06 17:03:56.14 .net
マルチキャストが必要な場合(メモリリークを避けるためにイベントを置き換えるとき)もこんな感じで
class HogeModel {
//弱参照で複数のリスナへの参照を持つ複合プロキシ
private WeakCompositeProxy listeners;
public void AddListener(dynamic listener) { listeners.Add(listener); }
private void RaiseSomethingHappened() {
//登録された全てのリスナのOnSomethingHappenedメソッドを呼び出す
//リスナがOnSomethingHappenedメソッドを持たない場合は何もしない
((dynamic)listeners).OnSomethingHappened();
}
}
407:デフォルトの名無しさん
12/11/09 04:16:24.83 .net
MVVMってメトロになってもやること変わらんの？
技術的にはあっちが本流だと思うんだけど
408:デフォルトの名無しさん
12/11/09 09:11:57.38 .net
どうしてデザパタが環境によって変化すると思うんだｗ 技術じゃないぜ。概念だろ。
409:デフォルトの名無しさん
12/11/09 10:13:41.46 .net
この手の概念って「ある一定の規則とか法則に名前をつける」
だけの話だからね。
410:デフォルトの名無しさん
12/11/09 11:31:24.11 .net
コーディング段階は結構変わるがな
411:デフォルトの名無しさん
12/11/09 22:45:20.26 .net
>>401
概念の話と
概念に名前をつけるって
話がごっちゃになってるよ。
概念に名前をつけるのは重要なことだが、
もちろん概念そのものも重要なことだぞ。
412:デフォルトの名無しさん
12/11/11 00:32:37.19 .net
すいません、よかったら教えてください
MVVM Light Toolkitで遊んでるんですが、テンプレートから作成されるModelの
IDataServiceのメソッドがActionを渡して結果をコールバックさせる形になっています
普通に戻り値や例外を返せばいいと思うのですが、あえてコールバックさせているのはなぜなんでしょう？
考えても理由がちっとも思いつかないので、もしわかったらお教えください
よろしくお願いします
413:デフォルトの名無しさん
12/11/11 00:36:08.24 .net
>>401
MVVM以前からMVVM的な物が存在していたということ？
414:デフォルトの名無しさん
12/11/11 00:40:40.06 .net
>>404
処理に時間がかかる場合にGUIが固まるのを防ぐためだろ
Webからデータを取ってくるような場合は言うまでもないが、
ローカルなファイルやデータベースからちょっと取ってくるくらいでも結構固まる
415:デフォルトの名無しさん
12/11/11 00:53:11.62 .net
>>406
それはasync、awaitの非同期処理はModel内部で行ってServiceのメソッドをasync宣言しない方がよい
ということでしょうか？
Serviceのメソッド自体が非同期メソッドであれば画面が固まったりしないですよね？
そこら辺も初めてさわったのでトンチンカンなこと言ってたらすいません
416:406
12/11/11 00:56:51.28 .net
あ、MVVM Light Toolkitは別にasync、awaitのサポート環境を限定してないからかな？
逆にいうとasync、awaitが使える環境ならば別にコールバックさせる必要はないってことでいいんでしょうか？？
417:デフォルトの名無しさん
12/11/11 00:57:16.17 .net
>>407
いやMVVM Light Toolkitは結構昔からあって、当時はasyncが無かっただけ
U氏はasyncは内部で使うものであってインターフェイスに使うなとか
思い込みだけで頓珍漢なことを言ってたが
今からasync前提で作るなら普通に使っていいよ
418:406
12/11/11 01:01:22.02 .net
>>409
なるほど、納得しました
サービスレベルでasyncにしてコールバックは利用しない方法でいってみます
いろいろありがとうございました
419:デフォルトの名無しさん
12/11/12 00:22:58.42 .net
>>409
うがやは、C#というか言語や.NETに関して知識なさすぎだからな。
ライブラリ設計者としてのセンスもない。
420:デフォルトの名無しさん
12/11/12 20:04:14.60 .net
MVVMでユーザコントロール使う場合のお作法？で質問があります
Page内に異なるユーザコントロールが2種類AとBがあります
Aはリストを表示するコントロールでBはその明細を表示するコントロールです
AとBにはそれぞれ専用のVMを作ってバインドしています
この時、A内のリストで選択されたものをBに渡したいのですがどう実装するのがスマートなんでしょうか？
現在は、PageのVMの中にAVMとBVMを保持していて、AVMのPropertyChangedイベント
をPageのVMの中で拾ってBVMのプロパティに設定しています
が・・・なんかいまいち感が
他にいいアイディアってあるのでしょうか？
421:デフォルトの名無しさん
12/11/12 20:12:25.87 .net
ListBoxのItemsSourceにVMたくさん入ったコレクションセットして
ContentControlのContentか任意のViewコントロールのDataContextにListBoxのSelectedItemをバインドするのが楽じゃね
422:デフォルトの名無しさん
12/11/12 21:01:20.01 .net
あぁそっか、そういうやり方があるんですね
勉強になります
ありがとうございました
もしよかったらもう一つ教えてください
実はAで選択されたItemをまた別のコントロールに今度は単一を設定するのではなくて
どんどん追加もしたいんですが・・・
そういう場合はどうするのが良いのでしょうか？
一つ一つの機能は徐々にわかってきたんですが、合わせ技になると発想がついてこないっす
423:デフォルトの名無しさん
12/11/12 21:01:56.33 .net
SelectedItemは同意だけど、VM自体はPage用1つだけでいいと思う
「AB両方の表示用を子プロパティとして持つクラス」のコレクションを
VMがプロパティとして公開して、Aがそれにバインド、
BがAのSelectedItemにバインド、が一番すっきりかな
424:デフォルトの名無しさん
12/11/12 21:14:21.92 .net
>>415
なるほど、そういうやり方もあるのか
そこで一つ疑問が出てきてしまったんですが・・・
WebでMVVMのユーザコントロールのサンプルをいくつか見たところ
たまたま？すべてのサンプルがユーザコントロール毎に定義されていて
それを鵜呑みにしてたんですが・・・
親になるビューだけがVMを持つのとコントロールも独自にVMを持つケース
どういった感じで使い分けたらいいのでしょうか？
ちなみに今回の場合、AもBも表示するだけではなくて、それなりに個々の
コントロールに機能を持っています
Aはソート順を変えたり絞り込んだり、Bは詳細を編集したりなどです
425:デフォルトの名無しさん
12/11/12 23:25:58.38 .net
426:>>416 俺は複数のWindowでControl使いまわしてるから、Controlに専用のViewModel持たせてるよ
427:デフォルトの名無しさん
12/11/13 00:54:12.58 .net
Model側でコレクションを持つ場合、そのVMも子ModelのVMのコレクションを持つようにしてるかな
この場合Model側もObservableCollection的な通知機能付コレクションを使うことになるが
子ModelがVM持つほどの意義がない場合は親Modelのコレクションそのまま使ったりもする
428:デフォルトの名無しさん
12/11/13 04:42:27.67 .net
414は単純に、「別のコントロール」側のItemsSourceになってるコレクションに
Addしてやればいいだけだと思う…
単純過ぎるので質問の意味取り違えてるかも知れないけど
416についてはケースバイケース
どうするのが、開発や保守しやすいか。それ次第でしょう
429:414
12/11/13 20:36:52.73 .net
昨日はレスいただいたのに返事できずにすみません
>>417-418
コントロールは再利用するつもりなので、今回はコントロールにVM持たせてみます
子もVMに入れてみようと思います
430:デフォルトの名無しさん
12/11/13 20:43:05.86 .net
>>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)の部分が特にしっくりこなくて気持ち悪いというのが、質問させていただいた経緯です
431:デフォルトの名無しさん
12/11/13 21:27:06.52 .net
>>421
あまり参考にならないかもですけど、
もし俺が、そういうPage,A,Bの3つのVMでやるとしたら
Aのコンストラクタの引数で、デリゲートを受け取れるようにしておく
AではPropertyChangedのハンドラで、その受け取ったデリゲート呼ぶようにしておく
PageからA,Bをインスタンス化する際に、
BのAddItemを呼び出す処理や、Pageでやるべき処理もあればまとめて、
Aのコンストラクタに全部、ラムダ式で渡す
これで後は、AのPropertyChanged内だけで、PageやBの処理も全て完結
って感じにするかな…。
432:デフォルトの名無しさん
12/11/13 21:40:19.58 .net
>>422
ふむふむ、なるほど
レス読ませてもらって考えているうちに思ったんですが、AVMにItemが選択された
ことを通知するイベントを定義して、そこにラムダ式突っ込んであげれば良いのかな？
って気がしてきました
何が気持ち悪かったって、AVMにはほかにプロパティもあるわけで、PropertyChangedを
ハンドルしていると、別にPageには興味がないプロパティも飛んでくるわ
プロパティの名前をAVMで定数定義してAVMからもPageVMからも参照しようとすると、
MVVM Light ToolkitでVMのインスタンスを生成するときにエラーで落ちちゃって
プロパティ名をAとPageの双方に文字列で指定してた所なんで、一番キモイ所は解決された気がします
ただなんか手法が古臭いような気がしないでもないですがｗ
XAMLでこう書いてああ書いてすればサクっとできちゃうよ！的な解決策はさすがにないですよね？ｗ
433:デフォルトの名無しさん
12/11/13 23:15:36.04 .net
@ugaya40: 難しいとかいってる人はコードビハインドでMVVMしましょ
コイツ、MVVMでコードビハインド使うのはMVVMを理解していない無能のすること とか散々ほざいてたくせしてなに言っちゃってんのって感じなんだが。
「難しいとか言ってる人」とかつけ加えてて誤魔化してんじゃねーよ。
難しいとか難度の問題じゃないってわかんねーのかな？
434:デフォルトの名無しさん
12/11/13 23:18:09.19 .net
コードビハインドを使用したものは神の怒りに触れ
永久にメモリリークの責め苦を受けるんじゃなかったのかw
435:デフォルトの名無しさん
12/11/13 23:23:22.77 .net
テンプレートにハンドラつけた場合じゃねそれ
436:デフォルトの名無しさん
12/11/13 23:28:45.74 .net
自作のライブラリーをコードビハインドに対応させるって言ってたし完全に方向転換したんじゃないのかな？
それ自体はいい事だとは思うけどね
ただ、間違った持論でMVVMの概念をめちゃくちゃにした罪は大きいよね
きちんと間違ってたことを認めればいいけど、あの歪んだ性格じゃ無理だろうな…
437:デフォルトの名無しさん
12/11/13 23:33:30.98 .net
必死にPSDって略語を流行らせようとしてるのに誰も使ってないのが泣ける、というか笑えるｗ
438:デフォルトの名無しさん
12/11/13 23:39:32.37 .net
PDS言ってるのは知ってるがPSDは知らんな
439:デフォルトの名無しさん
12/11/13 23:40:55.84 .net
DPSならしってる。全部知ってる。DPS全部
440:デフォルトの名無しさん
12/11/13 23:43:51.07 .net
社内ではよく使うがネットで使う機会が無い
441:デフォルトの名無しさん
12/11/13 23:45:32.47 .net
本人もあれだけど最近はアンチのがウザいな
直接煽られたことある人はそうなるのか
442:デフォルトの名無しさん
12/11/13 23:50:31.04 .net
面白がってアンチに乗じてアンチごっこしてるやつが一番うざいし役に立たない
443:デフォルトの名無しさん
12/11/14 00:37:00.22 .net
MSの将来が不安なのでAndroidのMVVM環境教えてください
444:デフォルトの名無しさん
12/11/14 00:42:27.62 .net
JavaScriptでよければ
KnockoutがMVVMのフレームワークだよ
445:デフォルトの名無しさん
12/11/14 00:47:11.25 .net
Androidでバインディングは無理だと思う
コントロールがそれぞれ独自にXML読むクソ設計なんだぜ?w
446:デフォルトの名無しさん
12/11/14 00:59:28.17 .net
AndroidのフレームワークでバインディングやるならActivityのコード側でsetBindingみたいなメソッド呼んで
実装はリフレクションで頑張るしかないだろうけど
そんなことするくらいならPassive Viewの方がいいと思う
447:デフォルトの名無しさん
12/11/14 01:13:42.40 .net
さすがに今年中にBlend出してくれんとしんどいわMSさん
448:デフォルトの名無しさん
12/11/14 01:24:18.30 .net
Expression Studio 5まだー？
449:デフォルトの名無しさん
12/11/14 02:03:13.02 .net
android binding があるでしょ
450:デフォルトの名無しさん
12/11/14 21:26:33.41 .net
@ugaya40: 俺はWin8デスクトップにはスタートメニューが必要だと思うけど、シノフスキーさんの辞任と現時点で結びつけたりするわけもなく。ただその反対意見もまた極端なのが散見してるな。どっちもアホじゃないですか。
散々、極端なことを言ってたのはお前だろ？ｗ
自分で自分がアホって自覚がちゃんとあるんだな。
451:デフォルトの名無しさん
12/11/14 21:27:50.23 .net
>>426
メモリーリークするの？
メンドクサイからテンプレートから呼ぶようにしたんだけど・・・
452:デフォルトの名無しさん
12/11/14 21:49:40.33 .net
>>441
お前さん､うがやのこと大好きなんだな
453:デフォルトの名無しさん
12/11/14 22:08:23.42 .net
そのうちVSスレのキチみたいに発狂しちゃうんだろうな
454:デフォルトの名無しさん
12/11/14 22:12:55.52 .net
さすがに粘着が過ぎる
455:デフォルトの名無しさん
12/11/14 23:17:24.64 .net
まぁ、こういう個人攻撃はネットウォッチ板でやるもんだな
456:デフォルトの名無しさん
12/11/15 10:53:44.15 .net
>>442
そんなことでリークするわけない。動的に生成された要素は、XAMLでイベントハンドラが登録されたままでも
ツリーから外れた時点でGC対象になる。XAMLではなくコードビハインドなどから追加した場合は当然
WPF管理外のため、イベントハンドラによる強参照が当然残るのでそれがマズい場合があるだけ。
つまりWPF自身の問題などでは決してなく、あくまで愚かな人間によるミス。
例の宗教はあえてそのあたりをぼかす(信者の多くはそもそも理解してないまま復唱�
457:ｵてるだけだろうが) ことによって恣意的なイメージ操作を行っている。
458:デフォルトの名無しさん
12/11/15 10:57:08.02 .net
そもそもWindow自体を解放する手段ないだろ
459:447
12/11/15 11:01:14.57 .net
ItemsTemplate/DataTemplateの中のコントロールのイベントに対して
コードビハインドのイベントハンドラを登録したときの話な
試してみたら分かるが、要素を削除した後にGCが走れば
ちゃんとコントロールのファイナライザが呼び出される。
460:デフォルトの名無しさん
12/11/15 11:25:23.41 .net
メッセージに応答してダイアログを開いたりする汎用的なビヘイビアって本当に必要?
VMからダイアログ開きたいんだったら、IoCでVMからIOpenFileDialogServiceのような
インターフェイスを通してメソッドを呼び出せばいいだけの話だと思うんだけど。
わざわざメッセージ投げてVで処理するなんて複雑だしXAMLも無駄に汚れるしタイプセーフじゃないし。
特定のビューでしか使わないようなサービスにするまでもない処理ならメッセージもアリだと思うけど
その場合ビヘイビアにする意味はなく(再利用しないんだから)、コードビハインドで受けて処理すればいい話だよな。
461:デフォルトの名無しさん
12/11/15 17:05:54.35 .net
テスト
462:デフォルトの名無しさん
12/11/15 20:05:32.67 .net
行き過ぎたBlend主義。
俺もサービスにするかな。
463:デフォルトの名無しさん
12/11/15 22:36:46.09 .net
VMからのメッセージでアニメーションを開始させたいときなんかにはビヘイビアが便利かも
と思ったけどそんなビューの細かいことをVMで意識するのも本末転倒な気がするな
そこはメッセージとXAMLは直接繋がないと割り切った方がいいのかも
464:デフォルトの名無しさん
12/11/15 22:46:23.39 .net
俺はビヘイビアで済ませたほうが楽かな
465:デフォルトの名無しさん
12/11/15 22:52:24.24 .net
Livet教のMVVM…ドカタMVVM
IoC使うPrism系のMVVM…JavaっぽいMVVM
466:デフォルトの名無しさん
12/11/15 23:15:07.41 .net
MVVM Light…光のMVVM
467:デフォルトの名無しさん
12/11/17 00:05:50.69 .net
よく話にでるlivetってライブラリ落としてみたけどクラス名にまでlivetって入ってんのね。
ダサすぎる。
468:デフォルトの名無しさん
12/11/17 00:08:09.15 .net
てゆーか、9割以上がPrismとMVVM light toolkitのパクリコードってのはどうなの？
Ugayaはずいぶんえらそーなことを言ってたがただのパクリライブラリじゃんか。
469:デフォルトの名無しさん
12/11/17 06:32:58.08 .net
そうだなC#はJavaのパクリだもんな
つーかソース見たことはないが本当にパクリなら大問題だしそれならここで言ってないで大々的に批判すればいいんじゃないか
470:デフォルトの名無しさん
12/11/17 09:52:41.30 .net
>>459
見ればわかるがおおざっぱに言えばLivetの独自部分でメソッドキャッシュとT4コンバーターぐらいじゃね？
C#っつーか.NET Frameworkだろ
1.0のころはパクリだったんじゃないの？
実際Javaがなければ今と同じ1.0は生まれてなかった
471:デフォルトの名無しさん
12/11/17 10:11:39.47 .net
なんだコード盗用とかじゃなくて概念の話だったのか
472:デフォルトの名無しさん
12/11/17 11:07:14.48 .net
>>461
>>458はコードと言ってるな
473:デフォルトの名無しさん
12/11/17 12:09:36.74 .net
>>461
綺麗に言えば、車輪の再発明？
ぱくりライブラリと言われても仕方がない代物ではある
何を目的にやってるのか分からないところもあるし
インフラを乱立させたって混乱するだけだし
ドキュメントやサンプル充実させて裾野を広げるってわけでもないし
尾上が自身の狂った思想から少しでもずれてる意見を発見すると
死ぬまで粘着されるしな
尾上は自分が日本での唯一のMVVM啓蒙者になるために
他人がおいそれと語れないようにしてるだけ
完全に癌でしかない
474:デフォルトの名無しさん
12/11/17 12:14:26.42 .net
MVVMの土台として画面遷移は極めて重要だと思うが、そこがいい加減なのはいただけない
同期ダイアログによる遷移のみってWinFormsかよw WinRTじゃそんなもん使えないぞ?
475:デフォルトの名無しさん
12/11/17 12:30:02.96 .net
>>464
MVVMはMSが本気で取り組まない限り無理。
言語、.NET Framework、IDEが三位一体で対応しないと今はまだ欠陥が多すぎる。
476:デフォルトの名無しさん
12/11/17 12:38:05.90 .net
>>465
WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
IDEでどうするもんでもないだろう
Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
477:デフォルトの名無しさん
12/11/17 13:33:39.79 .net
U氏に親殺されたやつ多すぎだろ
478:デフォルトの名無しさん
12/11/17 14:04:28.46 .net
>>467
叩かれてる奴に「氏」付けるのは本人だけ
ってだいぶ前に小学生の妹が言ってたよ。
479:デフォルトの名無しさん
12/11/17 14:08:17.71 .net
画面遷移についてはMVVMと絡めてもっと真剣に議論されるべきだと思うぞ?
U氏関係なく。自称MVVMインフラではたいてい完全スルーされてるが(Livetでもおまけ程度)
どうしてもインフラ的なコードを書くことになる部分だし、MVVM使ってるなら画面遷移の設計も
それに強く影響されることになる。