MVVMについて語ろう
1 :デフォルトの名無しさん :2012/06/06(水) 11:03:33.21 .net WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか!
2 :デフォルトの名無しさん :2012/06/06(水) 11:09:54.07 .net 関連記事 Model View ViewModel http://ja.wikipedia.org/wiki/Model_View_ViewModel Model-View-ViewModel デザイン パターンによる WPF アプリケーション http://msdn.microsoft.com/ja-jp/magazine/dd419663.aspx MVVMパターンの常識 ― 「M」「V」「VM」の役割とは? http://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_02/greatblogentry_02_01.html MVVMパターンとイベント駆動開発、そしてMVC/MVP/PMパターンとの関係 ? 何故MVVMなのか http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html 「MVVMパターンが必要な理由」啓蒙用資料公開 http://ugaya40.net/mvvm/mvvm_document.html
3 :デフォルトの名無しさん :2012/06/06(水) 12:06:49.93 .net 語れるほどニーズあんのか?
4 :デフォルトの名無しさん :2012/06/06(水) 12:30:27.30 .net MVCよりはまし。 でも、MVCすら理解できないのが大半だからなー
5 :デフォルトの名無しさん :2012/06/06(水) 12:40:59.59 .net MVPとMVC混同してる人けっこういるよね
6 :デフォルトの名無しさん :2012/06/06(水) 12:50:21.81 .net UIパターン知らんでMVVM知ろうとしても無理ゲー
7 :デフォルトの名無しさん :2012/06/06(水) 13:04:32.71 .net >>5 実装上の違いだけで本質的には同じもの そこにこだわるってことは、たぶん本質が分かってないんだろうな
8 :デフォルトの名無しさん :2012/06/06(水) 14:22:00.43 .net 語ることあるのか知らんが期待しとく
9 :デフォルトの名無しさん :2012/06/06(水) 14:34:22.26 .net 要するにXAMLで開発してれば自動的にMVVMなんでしょ? 開発環境を作ってるのでも無ければ、あんまり純粋主義主義者になる意味は無いと思う。
10 :デフォルトの名無しさん :2012/06/06(水) 14:36:36.66 .net このスレッドは天才チンパンジー「アイちゃん」が 言語訓練のために立てたものです。 アイと研究員とのやり取りに利用するスレッドなので、 関係者以外は書きこまないで下さい。 京都大学霊長類研究所
11 :デフォルトの名無しさん :2012/06/06(水) 15:10:32.26 .net MVVMツールがVSに標準装備されてないことか推測するに、MVVMがXAMLUIに必須でないことが判る
12 :デフォルトの名無しさん :2012/06/06(水) 15:41:03.54 .net >>9 自動的にMVVMではない。 >>11 必須ではないが有用。
13 :デフォルトの名無しさん :2012/06/06(水) 16:24:21.12 .net デザインパターンと同じで、フレームワークの名称じゃないからね 自分でフルスクラッチしてもいいんじゃよ? 別にむずかしくないし でも「mstest? なにそれおいしいの?」って子は 本来のメリットの半分もえられないからこれまで通りにかけばいいんじゃないの
14 :デフォルトの名無しさん :2012/06/06(水) 19:44:35.03 .net MVVMで実際のDBに繋いでCRUDのサンプルってないね。 DBのあたりはEntity Frameworkでいいの?
15 :デフォルトの名無しさん :2012/06/06(水) 19:53:11.38 .net つか語呂悪い。なんで最後だけ二文字なんだよ。
16 :デフォルトの名無しさん :2012/06/06(水) 19:56:31.71 .net >14 プレゼンテーション層以外はすべてModelなのでどうでもいい話 >15 回文
17 :デフォルトの名無しさん :2012/06/06(水) 19:59:28.53 .net >>15 じゃあ何て略したらいいんだよw
18 :デフォルトの名無しさん :2012/06/06(水) 20:01:18.77 .net Mのぶぶんは別になんでもいいお。 そもそもMの部分はVMとのセパレーションさえできていればいわゆるModel的なものですらなくていいと思う。 なんというかViewに関連しないものでありさえするなら、ステートを持つ実体的なものでもサービスとのやり取りをするProxi的なものでもなんでも。 実際のアプリではVMとMが一体化してるようなものもあると思われ。
19 :デフォルトの名無しさん :2012/06/06(水) 20:13:26.93 .net アプリケーションや実装固有の話だからといって、MVVMにおけるMやMVCにおけるMのパターンを語る気が無いなら 「V-VM-VとVM以外パターン」とか「V-C-VとC以外パターン」とか言っておくべきだな。
20 :デフォルトの名無しさん :2012/06/06(水) 20:42:38.20 .net Mはドメインロジックなのでモデルといって問題ない
21 :デフォルトの名無しさん :2012/06/06(水) 20:47:41.09 .net つうか、むしろ話としては、VVMな部分の話よりも、MVVMにおけるMの話の方が語ることは多いと思うが。 VMとして責務を分離する話に、スレを立てるほどの広がりがあるのかなあ?
22 :デフォルトの名無しさん :2012/06/06(水) 20:48:35.99 .net ドメインロジックという言葉が何に対してでも都合良く使われる問題。
23 :デフォルトの名無しさん :2012/06/06(水) 20:48:37.04 .net 実装の話とか?
24 :デフォルトの名無しさん :2012/06/06(水) 20:51:59.61 .net >>22 それはすげー思うw
25 :デフォルトの名無しさん :2012/06/06(水) 20:54:32.74 .net Mについてはそれなりに構築できるけど、 そこにVを被せるときに毎回苦労するんだなー
26 :デフォルトの名無しさん :2012/06/06(水) 20:58:39.14 .net 対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。 MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、 ひいては状態を持っているるからドメインモデルです(`・ω・´)キリッ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。
27 :デフォルトの名無しさん :2012/06/06(水) 22:10:29.54 .net いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな
28 :デフォルトの名無しさん :2012/06/06(水) 23:41:43.34 .net だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある?、っていう。 まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。 DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、 サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。
29 :デフォルトの名無しさん :2012/06/07(木) 00:03:55.68 .net それはアプリケーション(Model)の役目だろうよ V&VMはむしろ生成される側だと思われ
30 :デフォルトの名無しさん :2012/06/07(木) 00:13:47.89 .net 簡単に言えば V 見た目 M 本処理 VM 接着剤 だろ MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな Modelって名前なんだから何々であるべきなんだ!!1なんて話はナンセンス
31 :デフォルトの名無しさん :2012/06/07(木) 00:14:54.65 .net その「アプリケーション(Model)」っていう言い方も微妙だが…。 生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。 でも、その話すらしないのだとしたら、本当に何の話をするんだ?
32 :デフォルトの名無しさん :2012/06/07(木) 00:15:55.19 .net ザックリ分けると ・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。 ・MVVMとしての各画面の作り方の部分 ・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分 って感じかね。
33 :デフォルトの名無しさん :2012/06/07(木) 00:16:50.09 .net >>30 で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの?
34 :デフォルトの名無しさん :2012/06/07(木) 00:23:50.25 .net >>33 >>30 の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの?
35 :デフォルトの名無しさん :2012/06/07(木) 00:36:57.38 .net MVVMの実装に関する話ならいくらでもできるんじゃね
36 :デフォルトの名無しさん :2012/06/07(木) 01:12:27.18 .net むしろそちらの方を知りたいという人間多いんじゃね? MVVM的に考えるとコマンドはVMに置くべきか否か コードビハインドとイベントハンドラとVMの関係 コードビハインドはいわゆるプレゼンターか否か バインディングとMVVMは切り離して考えるべきか否か MVVMとしてふさわしいVMの実装は もっと高速にVMを実装する方法はないかとかね
37 :デフォルトの名無しさん :2012/06/07(木) 01:13:45.85 .net あとMVVMツールの良し悪しや使用方法についてとか
38 :デフォルトの名無しさん :2012/06/07(木) 01:19:01.75 .net ビヘイビアってよく聞くけどVMに入るの?
39 :デフォルトの名無しさん :2012/06/07(木) 06:11:20.38 .net >>32 みたいな、アプリケーション構造の話をするのはこのスレではあり?、なし? MVVMフレームワークの実装比較の話は俺も聞きたいな。
40 :デフォルトの名無しさん :2012/06/07(木) 06:16:05.12 .net 定義論にまた脱線しない限りまあいいんじゃね
41 :デフォルトの名無しさん :2012/06/07(木) 08:14:29.03 .net >>39 むしろそのためのスレだろ
42 :デフォルトの名無しさん :2012/06/07(木) 09:30:27.00 .net Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。 その境界がどこかの確認。
43 :デフォルトの名無しさん :2012/06/07(木) 09:57:41.92 .net >>42 新参者だが、荒れるん? むしろMVVM作る上で重要なファクターだと思うんだが。
44 :デフォルトの名無しさん :2012/06/07(木) 10:11:41.27 .net Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです!、な発言が出てくるから。 その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。
45 :デフォルトの名無しさん :2012/06/07(木) 10:16:56.33 .net 何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ
46 :デフォルトの名無しさん :2012/06/07(木) 10:28:50.09 .net 本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。 そこでV〜M間に仲介者を設け、V(XAML)、VM(C#)の二層構造とし、VMにViewの状態とModelのデータを保持させて V〜VM間をバインディングで通信するのがMVVM。
47 :デフォルトの名無しさん :2012/06/07(木) 10:30:41.00 .net ほらw >>45 の意見なら、このスレですべきは>>36 みたいな話であって、>>32 みたいな話は別途 WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。
48 :デフォルトの名無しさん :2012/06/07(木) 10:35:21.73 .net >>45 それは>>32 でいう2つめを見てるだけであって、実際のアプリを作るには1も3も必要だろ。
49 :デフォルトの名無しさん :2012/06/07(木) 10:58:40.42 .net >DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。 ってMVVMとどう関係あるの? 洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがw
50 :デフォルトの名無しさん :2012/06/07(木) 11:00:01.66 .net >>48 VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ
51 :デフォルトの名無しさん :2012/06/07(木) 11:04:12.67 .net >>49 ,50 M内の構造はMVVMとは関係ないよ。 でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ? MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。
52 :デフォルトの名無しさん :2012/06/07(木) 11:07:44.33 .net >>51 ああ、ごめん。IDが出ないから流れがわかりにくいなこのスレ >>49 は>>47 への反論です >>50 も俺だけど>>51 と全く同意
53 :デフォルトの名無しさん :2012/06/07(木) 11:16:28.31 .net >>46 そもそもVMはV層でしっかりVとMの分離になってるんじゃないか Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし
54 :デフォルトの名無しさん :2012/06/07(木) 11:18:42.66 .net やっぱり、VVM内に閉じた話だけを扱うスレなのか?、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか?、っていう最初に戻るじゃん。 VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。
55 :デフォルトの名無しさん :2012/06/07(木) 11:26:13.73 .net 定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる 定義知りたきゃMVVMでぐぐってろ
56 :デフォルトの名無しさん :2012/06/07(木) 11:27:07.00 .net そもそもMVVMってなに?
57 :デフォルトの名無しさん :2012/06/07(木) 11:27:49.63 .net >>56 >>2
58 :wikiから抜粋 :2012/06/07(木) 11:33:08.35 .net Model アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き(ビジネスロジック - ショッピングの合計額や送料を計算するなど)を表現する要素である。 多くのアプリケーションではデータの格納に永続的な記憶の仕組み(データベースなど)が使われていたり、 サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。 MVVMの概念ではMVCの概念と同様に、データの(UI以外の)入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる 一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。 たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。 アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。 Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。
59 :デフォルトの名無しさん :2012/06/07(木) 11:34:10.24 .net MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。 それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね?
60 :デフォルトの名無しさん :2012/06/07(木) 11:36:30.09 .net >>58 それってU氏の記述だろ?
61 :デフォルトの名無しさん :2012/06/07(木) 11:40:56.25 .net わかりにくいからMVVMをガンダムでたとえて
62 :デフォルトの名無しさん :2012/06/07(木) 11:47:53.91 .net >>54 そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・`)
63 :デフォルトの名無しさん :2012/06/07(木) 11:49:55.46 .net >>61 M=ララァ VM=サイコミュ V=ビット
64 :デフォルトの名無しさん :2012/06/07(木) 11:58:29.11 .net >>63 なんとなくこれ思い出した http://d.hatena.ne.jp/hilapon/20120426/1335411488
65 :デフォルトの名無しさん :2012/06/07(木) 12:54:35.30 .net スレのあり方を議論するだけで終わりそうだw
66 :デフォルトの名無しさん :2012/06/07(木) 13:03:38.18 .net おまえが勝手に思ってるだけだろ
67 :デフォルトの名無しさん :2012/06/07(木) 13:17:43.48 .net 質問です。 ButtonクリックしてViewModelからWindowクローズしたいんだけど、ViewModel側にはどう書いたらいいのでしょうか?
68 :デフォルトの名無しさん :2012/06/07(木) 13:21:47.51 .net ウィンドウを閉じる動作はViewで完結しているものなんじゃないでしょうか
69 :デフォルトの名無しさん :2012/06/07(木) 13:57:19.39 .net ウィンドウサイズ保存したい
70 :デフォルトの名無しさん :2012/06/07(木) 13:57:28.88 .net >68 そうなんですか?わかりました...(´・ω・`)
71 :デフォルトの名無しさん :2012/06/07(木) 14:36:34.99 .net >>69 コードビハインドで実装すればいいよ
72 :デフォルトの名無しさん :2012/06/07(木) 14:36:56.58 .net >>68 未保存のデータがあるときだけ確認メッセージを表示とか、Viewだけじゃ完結しないだろ。
73 :デフォルトの名無しさん :2012/06/07(木) 16:02:42.75 .net LivetのMessengerクラス使えば、ViewModelからWindow閉じたり最大化・最小化を操作できる http://d.hatena.ne.jp/hilapon/20111108/1320728308
74 :デフォルトの名無しさん :2012/06/07(木) 16:10:07.46 .net よし分かった、俺がこれがコードビハインドだって お手本のプログラムを作って見せてやるよ。
75 :デフォルトの名無しさん :2012/06/07(木) 16:21:57.25 .net >>73 他のMVVMツールにも同様の機能はありますか?
76 :デフォルトの名無しさん :2012/06/07(木) 17:01:49.59 .net >>75 その部分だけパチってくればいいじゃん。
77 :デフォルトの名無しさん :2012/06/07(木) 19:40:33.37 .net ugaya40さん、MVVMの本書いてよ。
78 :デフォルトの名無しさん :2012/06/07(木) 20:19:01.71 .net 彼は文書よりもLivetのチュートリアルの優先度をあげるべきだろ。
79 :デフォルトの名無しさん :2012/06/07(木) 20:39:57.25 .net チュートリアルないと使えないか? サンプルなら探せばそれなりにあると思うけど
80 :デフォルトの名無しさん :2012/06/07(木) 20:47:05.63 .net 使える使えないという話ではなく、広くアピールしたいならそういう地味な作業の優先度の方が高いんじゃないの、という話。
81 :デフォルトの名無しさん :2012/06/07(木) 20:47:06.97 .net ugaya40さんって誰?と思ってこれを読んだけど http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html MVPとPresentation Modelの認識がおかしいな まぁ全体として意味は通じるけど…
82 :デフォルトの名無しさん :2012/06/07(木) 20:52:17.02 .net ところで、これってMVCとどう違うの? MVCのときとMとVも当然違うと思うんだけど。
83 :デフォルトの名無しさん :2012/06/07(木) 20:52:18.22 .net u氏の言っていることは、VVMや実装の話についてはほぼ同意だしすごいとも思っているけど。 ただ、そこからMよりの話やもっと大きな構造の話になってくると、言っていることが微妙というか、 言おうとしていることはわかるけど、他の人の同意は得られないだろうな、っと思うことが多いかな。
84 :デフォルトの名無しさん :2012/06/07(木) 21:28:22.45 .net Livet使ってるけど2chの名無しに返信しないで欲しい、とだけ言っておきたい
85 :デフォルトの名無しさん :2012/06/07(木) 22:11:46.33 .net Livetネタは荒れるからやめろ。 本人に直接聞け。
86 :デフォルトの名無しさん :2012/06/07(木) 22:23:47.65 .net >>77 そんなニッチ層向けの本書いても売れないだろ
87 :デフォルトの名無しさん :2012/06/07(木) 22:59:32.63 .net MVVMってどれがええの? Livetがオススメ?
88 :デフォルトの名無しさん :2012/06/07(木) 23:01:51.98 .net mvvmlight
89 :デフォルトの名無しさん :2012/06/08(金) 00:29:17.99 .net それはプログラミングにどの言語がいいのかと聞くようなもので PrismもLivetもMVVMLightもどれも一長一短だからな 人に聞けばたぶんバラバラに返ってくるだろうから 一度使ってみて使いやすいのを判断したほうが早い
90 :デフォルトの名無しさん :2012/06/08(金) 01:33:55.43 .net >>81 どの辺が認識おかしいの?
91 :デフォルトの名無しさん :2012/06/08(金) 08:13:09.32 .net >>89 そういうんでは、その一長一短を聞きたいんだろ。 ぜんぶ試すってのはなかなか難しい。
92 :デフォルトの名無しさん :2012/06/08(金) 10:23:56.69 .net >>86 いや、結構売れるかも知れんぞ。
93 :デフォルトの名無しさん :2012/06/08(金) 11:41:06.72 .net VMへのサービス層のDIってどうやるべきものなの? それ以前に、VMとMを繋ぐ方法として、VMにサービス層をインジェクションする、っていう考え方はあってる?
94 :デフォルトの名無しさん :2012/06/08(金) 11:59:23.74 .net >>93 時と場合によるんだろうけど、そうするとMでやるべきのがぜんぶVMに来ない?
95 :デフォルトの名無しさん :2012/06/08(金) 12:38:59.57 .net >>94 自分が想定したのは以下の様なサービスファサードがあったとして。 interface HogeServeiceFacade { IE<Foo> GetFooList(); } HogeServeiceFacadeの実装の中では、外部サービスにアクセスしたり、ドメインモデルによる処理をしたり。 HogeServeiceFacade自体はバッチやWebでも使うものだとして。 ここがファサードになるので、それ以上Mの処理がVMに来ることは無いと思っているんだけど。 っで、このHogeServeiceFacadeとVMを接続する方法にコンテナ/サービスロケータを使う場合に どうするのかとか?、それって考え方としてそもそもあっているの?、っていうのを聞きたかった。
96 :デフォルトの名無しさん :2012/06/08(金) 12:44:10.40 .net >>95 そういうんではありなんじゃない? そもそもMVVMは大本はViewとMの分離があって、それにさらに薄いVMいれると更にセパレーションで来て良いよねって話だから。 で、ロケータ使う場合色々あるけど既存の使うか自前で作るかじゃない。 薄いやつなら実質ただのKeyValueで出来るだろうし、それで結構まかなえると思われ。Prismとかはその辺も実装されてる。DIがより良くインテグレートされてる。他は知らん。
97 :デフォルトの名無しさん :2012/06/08(金) 13:03:47.05 .net コンバータ(IValueConverterを実装したクラス)はMVVMのどの層に属するものなの?
98 :デフォルトの名無しさん :2012/06/08(金) 13:07:30.90 .net >>97 View
99 :デフォルトの名無しさん :2012/06/08(金) 13:20:41.29 .net コンバータ自体簡易VMみたいなもんじゃね?
100 :デフォルトの名無しさん :2012/06/08(金) 13:32:59.19 .net >>97 それを分類することに何か意味があるの?
101 :デフォルトの名無しさん :2012/06/08(金) 13:47:18.95 .net コンバータ、StringFormat、VMでの詰め替え等が混在していると保守性が悪くなりそうだ
102 :デフォルトの名無しさん :2012/06/08(金) 13:55:44.00 .net VMでなんでも出来はするるが、責務としてVMでやるのはデータ構造の変換までにして、色だの文字だのの修飾はコンバーターでやるべきだろう。
103 :デフォルトの名無しさん :2012/06/08(金) 13:57:35.24 .net 自分はコンバータも形式の変換で、修飾なりなんなりはViewにやらせるな
104 :デフォルトの名無しさん :2012/06/08(金) 14:47:38.34 .net おまえらユニットテストには何使ってるの
105 :デフォルトの名無しさん :2012/06/08(金) 14:53:47.65 .net >>96 Thx 考え方としてはありか。 Prismにはその辺の仕組みもあるのね。 じゃあ、各フレームワークでそういう機構を持っているものについて、該当クラス名とかを知っている人がいたら教えて下さい(*・ω・)*_ _)ペコリ 後は自分で調べるので。
106 :デフォルトの名無しさん :2012/06/08(金) 15:13:12.05 .net >>104 NUnit
107 :デフォルトの名無しさん :2012/06/08(金) 15:14:23.05 .net MVCとかMVPとかのパターンを判りやすく解説してる本あったら教えて
108 :デフォルトの名無しさん :2012/06/08(金) 15:24:26.98 .net >>104 俺もNUnit。
109 :デフォルトの名無しさん :2012/06/08(金) 15:27:32.55 .net 上のご神託を読んでこい。
110 :デフォルトの名無しさん :2012/06/08(金) 15:36:30.90 .net >>109 いや、MVVMの前提となるMVCやMVPについて知りたいんだが やっぱファウラー先生あたりの本になるのかな?
111 :デフォルトの名無しさん :2012/06/08(金) 15:57:52.51 .net 偉い先生が書いたものとか読んだことないわー MVCとかなにかのパターン本に乗ってたけどネットで探れるのと大差ない。 MSDNでMVPVMの説明してるやつでMVC,MVP説明してるのあったお
112 :デフォルトの名無しさん :2012/06/08(金) 16:02:11.72 .net MVCではクライアントはC(イベントハンドラ、リスナー、コールバック)に アクセスしてVがレスポンスとして帰ってくるのに対し、 MVVMはクライアントがVにアクセスしてVが帰ってくる感じだな。 HTMLならステートレスなMVCが、Viewがクライアント内にある ステートフルなappletとかsilverlight、デスクトップGUIならMVVMが良さそうだ。
113 :デフォルトの名無しさん :2012/06/08(金) 16:12:29.99 .net MVCについて知りたいならSmalltalkを調べろ。 WebのMVC(2)ならむしろRESTってキーワードで調べろ。 MVVM自体に関する本は知らん。 そしてそれとは関係無しに、PoEAAなんかも読んでおくべき。 PoEAAだけ読んで、ドメインモデルvsトランザクションスクリプト厨になったりする奴も多いけどな。
114 :デフォルトの名無しさん :2012/06/08(金) 16:18:06.91 .net そろそろ電子書籍で売ってくれ
115 :デフォルトの名無しさん :2012/06/08(金) 17:40:37.50 .net >>113 MVCってSmalltalkコミュニティから提唱されたのか
116 :デフォルトの名無しさん :2012/06/08(金) 18:47:52.68 .net たしか。 オブジェクト指向の元祖たるSmalktalkで発展したものだと効いた希ガス
117 :デフォルトの名無しさん :2012/06/08(金) 19:10:59.99 .net 良スレの予感。
118 :デフォルトの名無しさん :2012/06/08(金) 20:31:39.36 .net やっぱりVMのライフサイクル管理やVMへのインジェクションを行うサービスロケータはあっても良いよな。 アプリケーションの構造によっては別にいらないだろうけど。
119 :デフォルトの名無しさん :2012/06/09(土) 10:42:20.11 .net 複数ViewModel間の呼び出しってどうすべき?
120 :デフォルトの名無しさん :2012/06/09(土) 11:28:54.73 .net public string Name { get { return Model.Name; } set { Model.Name = value; } } こういう感じで VM で M のプロパティを V に伝えるためだけの プロパティってなんていうの?
121 :デフォルトの名無しさん :2012/06/09(土) 11:41:10.30 .net ごめん、knockout.js の話題はここで良い?
122 :デフォルトの名無しさん :2012/06/09(土) 11:45:02.52 .net >>120 NotifyPropertyChanged使わないなら直接Modelのプロパティにバインドしてよくね
123 :デフォルトの名無しさん :2012/06/09(土) 14:57:44.75 .net >>122 難読化でいちばん隠したい部分がまる見えになるからオススメできない プロパティ多すぎて書きたくねぇ!ってならT4
124 :デフォルトの名無しさん :2012/06/09(土) 16:03:19.03 .net 難読化か。難読化なら確かにラッピングは必要かもしれんが internalなViewModelじゃだめなん?
125 :デフォルトの名無しさん :2012/06/09(土) 22:58:26.63 .net ラムダ式からプロパティ名を取り出す方法なら難読化できるよ
126 :125 :2012/06/09(土) 23:02:50.05 .net ああXAMLには影響が出るから無理か インターフェイスが曝されるだけなら別によくない? VMでラップしまくるのも大差ないと思うが
127 :デフォルトの名無しさん :2012/06/10(日) 02:20:40.65 .net まあ全部ラッピングしたらしたでやっぱり中身の名前はそのまま出てくるわけだしな それなら直接Model繋げた方がいい
128 :デフォルトの名無しさん :2012/06/10(日) 19:31:10.74 .net ふむ。 ttp://www.mnow.jp/LinkClick.aspx?fileticket=U%2b2U8DNLxfs%3d&tabid=220&mid=867 確かにナビゲーションなんかは、MessengerやBehaivorで解決できはするんだけど、 VVMの責務としてどうなのかとか、MVVMというよりもBlend至上主義になりすぎているのではと思うことはあって。 何かしら別の層があっても良いと感じてはいたが。 それをPと呼ぶかどうかはともかく。
129 :デフォルトの名無しさん :2012/06/10(日) 19:42:58.13 .net 世の中にはコードビハインドというものがあってだな
130 :デフォルトの名無しさん :2012/06/10(日) 20:08:46.96 .net コードで書くかと、コードをどこに書くかは全然違う話であってだな
131 :デフォルトの名無しさん :2012/06/10(日) 20:22:58.07 .net ところでVS2012のデザイナはBlendベースで刷新されて前と比べ物にならないくらい良くなってるぞ アニメーションやテンプレートやリソースの編集にはBlendがまだ必要だけど MVVMのV作るときにはそろそろBlendいらないと思う
132 :デフォルトの名無しさん :2012/06/11(月) 07:53:21.15 .net >>121 のやつ http://en.m.wikipedia.org/wiki/KnockoutJS http://knockoutjs.com/ SilverlightとKnockoutJSの比較 http://www.codeproject.com/Articles/365120/KnockoutJS-vs-Silverlight
133 :デフォルトの名無しさん :2012/06/11(月) 09:04:31.43 .net コマンドもバインディングできて、シンプルなテンプレートも付いてるのはいいな。 なかなか使いやすそうな感じだね。これは確かにMVVMだ。 質問とかだったらWeb制作板のライブラリ質問スレが適当かな。
134 :デフォルトの名無しさん :2012/06/11(月) 09:12:27.73 .net WebはWebでもJSはクライアント側でUIを扱うからMVVMなんだな
135 :デフォルトの名無しさん :2012/06/12(火) 01:28:10.49 .net VS2012になると ビュー モデルは Portable Library でサポートされるそうだ、VM と M は可能な限り Portable Library に押し込んでマルチプラットフォーム化を目指せるのか。
136 :デフォルトの名無しさん :2012/06/12(火) 02:06:46.27 .net VMが厚くなるな
137 :デフォルトの名無しさん :2012/06/12(火) 02:23:38.61 .net MetroとWPFでVM使い回しはきついだろ ギャップが大きすぎるから、大量のコードビハインドでVMを相当抽象化することになるか 互換性のためにどっちつかずでプラットフォームの空気を読まない不自然なUIになりそう
138 :デフォルトの名無しさん :2012/06/12(火) 07:04:36.86 .net Portable Libraryは別に良いんだけど、別にVMのマルチプラットフォーム対応を目指す必要は無いと思うんだよね。 使用するビューのテクノロジーやデバイスが異なればVMに求められる構造だって変わってくるし。 WebのMVCでPCサイトとモバイルサイトで同じControllerを使う、程度には面倒で制約が多い気がする。 むしろマルチプラットフォーム化できるんならしたいのはMじゃね?
139 :デフォルトの名無しさん :2012/06/12(火) 12:49:34.16 .net Livet で、Winodws.Loaded 時にコマンド発行させたいんだが、どうすればいいの? WindowAction みたいなので、コマンドを発行するだけの Action があればいいだんけど、 見つからなかった。 自分で作るしかない?
140 :デフォルトの名無しさん :2012/06/12(火) 13:12:31.77 .net >>139 i:EventTrigger i:InvokeCommandAction
141 :デフォルトの名無しさん :2012/06/12(火) 16:51:30.23 .net Portable Library に Model を押し込む努力はするべきだ。 Portable Library に押し込むには ViewModel は View にプロパティを提供するだけにせざる負えない。 と書いてどっかで聞いたなと思ったら。 MVPVMパターンあった。 Portable Library に ViewModel と Model を押し込んで View と Presennter をプラットフォーム依存にするのか。
142 :デフォルトの名無しさん :2012/06/12(火) 17:21:46.72 .net で、そのPresenterってコードビハインドじゃん、ってなった
143 :デフォルトの名無しさん :2012/06/12(火) 18:36:18.33 .net 状況によってはPresenter設けてもいいと思う Viewのサイズや表示位置、グリッドのソート順や列の表示・非表示等を構成ファイルに保存/読み込みさせるのに独立したPresenter設けても可
144 :デフォルトの名無しさん :2012/06/12(火) 20:43:19.56 .net Presenterの役割定義が昔に比べて広いものを指すようになってきている気がするのは俺だけ? IHogeViewを実装しているビューなら、それがWPFだろうがWindows FormsだろうがConsoleアプリだろうが、 HogePresenterから操作できる、みたいなのがMVPのイメージだったんだけど、 コードを書く = Presenterな使われ方が増えている気がするんだけど、MVPってそういうものだったの? ビュー間にまたがるものやアプリケーション横断的な処理の記述箇所については、 Presenterといわずに別の定義をした方が良いんじゃねと思ったんだけど。
145 :139 :2012/06/12(火) 22:17:28.41 .net >>140 ありがとう。 Livet 関係なくできたのか、 ぐぐっても出ないわけだ・・・。
146 :デフォルトの名無しさん :2012/06/13(水) 02:37:56.25 .net >>142 V->VMが密結合にならないのがコードビハインドとは違うところ 実際やるかどうかは別にしてVMの差し替えが可能
147 :デフォルトの名無しさん :2012/06/13(水) 10:57:45.00 .net NVPVMはあくまでMVVMの派生パターン 特殊なコンポーネント使っててViewの負荷が異常に高い場合、有効なパターンだよ
148 :デフォルトの名無しさん :2012/06/13(水) 12:44:02.37 .net じゃぁViewにプロパティを提供する入力検証の一部をする以外の、 VMでやっていることを考えてみよう。 非常にめんどくさいコーディングスタイルのコントローラじゃないのか?
149 :デフォルトの名無しさん :2012/06/13(水) 13:12:22.81 .net それでいいんだろ 一つのViewを異なる使い方で使いまわすときに VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
150 :デフォルトの名無しさん :2012/06/13(水) 13:19:04.84 .net >>149 > 一つのViewを異なる使い方で使いまわすときに > VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う え? 一つのViewModelを異なるアーキテクチャで使いまわすときに Viewごと入れ替えるのは無駄が多いから の間違いじゃね?
151 :デフォルトの名無しさん :2012/06/13(水) 13:21:02.28 .net MVPVMのサンプルも、VM−Mのコンビは汎用性持たせ、Pで差分吸収するサンプルに思えたが
152 :デフォルトの名無しさん :2012/06/13(水) 13:26:43.72 .net 両方だろ VがVM、VMとビジネスロジックがそれぞれ密結合しないことでVとVMの再利用性を高めるのがねらい
153 :デフォルトの名無しさん :2012/06/13(水) 13:30:43.53 .net こういう意見もありますが ttps://gist.github.com/2041069
154 :デフォルトの名無しさん :2012/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
155 :デフォルトの名無しさん :2012/06/13(水) 13:40:07.82 .net VがVMに密結合してしまってるのが問題だといってたぞ。 U氏も遷移を切り離すならしっくりくると書いてある。 VMから遷移を切り離したら何が残るの? Viewにプロパティを提供する入力検証の一部をする位じゃないの?
156 :デフォルトの名無しさん :2012/06/13(水) 13:46:36.47 .net >>155 VがVMに密結合するのはコードビハインドな それをPに切り出してPを差し替え可能にしてるから密結合しない
157 :デフォルトの名無しさん :2012/06/13(水) 13:47:19.86 .net Viewで相互運用使うならMVPVM有りとの話もあるが、実際作業するとコードビハインドしか逃げようがないんだよなぁ〜
158 :デフォルトの名無しさん :2012/06/13(水) 13:49:10.29 .net コードビハインドってPじゃねえの?
159 :デフォルトの名無しさん :2012/06/13(水) 15:20:15.29 .net 質問。 VMの第一の目的って、Mの構造をVでバインディングしやすい形に変換した形で持つ事っていうのであってる? 例えば、DBの2次元表の構造を、複雑なViewにバインディングするためLINQで変換する、とか。 なので、Mの構造そのままを表示するようなVだと、VMは単純なラッパに見えてしまう。
160 :デフォルトの名無しさん :2012/06/13(水) 15:27:06.16 .net Mの構造そのまま表示できる場合においてはVMは不要
161 :デフォルトの名無しさん :2012/06/13(水) 15:45:57.26 .net 実際に作ってみりゃわかるけど 純粋にMのプロパティだけでインターフェースは作れない タブやエキスパンダの状態とか環境設定とかの話ね めんどくせぇから全部詰め込むってのもありだけど 無駄に一緒にするのは保守性を悪くする どうせそこらへんはほとんどラッパなんだから 書くのがめんどくさい部分は全部T4使えとT4
162 :デフォルトの名無しさん :2012/06/13(水) 15:51:40.10 .net T4使いづらいって印象しかないんだが、なんか間違ってる?
163 :デフォルトの名無しさん :2012/06/13(水) 15:57:40.49 .net 外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ 複数ファイルの処理が面倒なのはわかるが
164 :デフォルトの名無しさん :2012/06/13(水) 16:36:31.97 .net >>162 俺も同じ印象だ。 結局MsBuildタスクで、 http://d.hatena.ne.jp/okazuki/20110116/1295166605 の様な属性からコードを生成するようにしたよ。
165 :デフォルトの名無しさん :2012/06/13(水) 17:01:14.95 .net どうもこうも ViewModelBase<T>から派生してたら partialでTのプロパティを全部ラップしてやればいいのさ 簡単だろ? T4で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら 調べろとしかいいようがないが
166 :デフォルトの名無しさん :2012/06/13(水) 17:10:39.16 .net リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね
167 :デフォルトの名無しさん :2012/06/13(水) 17:23:42.40 .net > T4で自分のプロジェクトからリフレクション このあたりは、みんなどの方法を採用してる気か聞いてみたいね。 俺はWPFのコンパイルプロセスを見習って、 自分自身を一度ビルドしてからCecilでアセンブリにアクセスしてる。 他にも Cecilではなく普通のリフレクションAPIを使ったり、 ビルドせずにRoslynやNRefactoryを使ったりという方法もあるけど こっちを使ってる人もいるのかな?
168 :デフォルトの名無しさん :2012/06/13(水) 17:36:11.05 .net >>166 アセンブリがアンロードできない・・・と来れば、あとはわかるな? そう、AppDomainの出番だ。
169 :デフォルトの名無しさん :2012/06/13(水) 17:39:54.72 .net >>168 おい、やめろ AppDomain芸をよりにもよってT4でとか地獄過ぎる RoslynはまだCTPだしT4上で現実的なところで言えばCecilだろうな コード生成じゃなくてポストプロセスでのIL書き換えでよければPostSharpなんかも選択肢に入るが
170 :デフォルトの名無しさん :2012/06/13(水) 18:07:49.37 .net うん、AppDomainは無い まだ別プロセスを起動した方がマシ
171 :デフォルトの名無しさん :2012/06/13(水) 20:42:48.42 .net PostSharpとか使ってやるのがお手軽? 自前でTaskを作ってビルドプロセスに追加する方が良い?
172 :デフォルトの名無しさん :2012/06/13(水) 21:09:57.27 .net 一番手軽なのは某氏のDSL
173 :デフォルトの名無しさん :2012/06/13(水) 21:11:07.57 .net Castle.DynamicProxyでいいわ コード生成だるい
174 :デフォルトの名無しさん :2012/06/13(水) 23:33:29.53 .net >>172 えむなうさんの?あれってC#専用だよね?
175 :デフォルトの名無しさん :2012/06/13(水) 23:47:53.09 .net T4使ったら、少なくともテンプレートのコードが コンパイルされた結果のアセンブリはロードされるはずだろ だからもともと別AppDomainで実行されるようになってるから 普通にロードして問題ないんじゃないの?
176 :デフォルトの名無しさん :2012/06/13(水) 23:50:14.79 .net >>174 VB.NETやF#とか茨の道だし、C#で普通に使えれば問題ないだろ?
177 :デフォルトの名無しさん :2012/06/13(水) 23:51:37.83 .net 必要ならVB作れってCodePlexかBlogでリクエストすればいい。 まさかJavaScriptやF#じゃないよな。
178 :デフォルトの名無しさん :2012/06/14(木) 00:07:25.99 .net リフレクションでやるんならわかるけど、いちいちDSLでプロパティ定義するんだったら public virtual int Hoge { get; set; } としといてCastleのDynamicProxyで変更通知を自動実装させればいいと思うよ
179 :デフォルトの名無しさん :2012/06/14(木) 00:14:39.91 .net >>176 VB.NETは茨の道でもなんでもないんだが?
180 :デフォルトの名無しさん :2012/06/14(木) 00:16:41.28 .net >>178 プロパティ追加・Hoge・int の3ステップでできる。 赤シャツの嫌いなAOPで実装することもあるまい。
181 :デフォルトの名無しさん :2012/06/14(木) 01:42:25.17 .net VB続けたい奴がXAMLに手を付けるのが不思議だわ
182 :デフォルトの名無しさん :2012/06/14(木) 08:06:59.93 .net >>181 それは偏見。いまのVBはC#と比べて大差ない程機能強化されとる
183 :デフォルトの名無しさん :2012/06/14(木) 09:14:33.85 .net >>176 むしろすべてF#で作りたいんだが。 VMまではF#でやってる。
184 :デフォルトの名無しさん :2012/06/14(木) 13:20:58.33 .net MS自身はVBにも力を入れてるけど、周りが付いてきていない。 サンプルがC#でのみ提供ってのもよく見るし、 MonoはVBコンパイラを非サポートにしつつあるし。
185 :デフォルトの名無しさん :2012/06/14(木) 13:24:58.84 .net F#は面白そうだね。 計算式で上手くリアクティブプログラミングができたら 相当VMが作りやすくなりそうな予感がする。 けど、茨の道には違いないだろう。 IDEの支援は弱いし、ライブラリの中にはC#の文法で使うことが前提のようなものもあるし。
186 :デフォルトの名無しさん :2012/06/14(木) 20:01:18.03 .net VBにいくら機能を追加しても言語仕様が腐ってるから駄目だよ それにどうせ新機能が増えるたびに「冗長な予約語導入→C#より利便性が下がる」って悪循環でしょ
187 :デフォルトの名無しさん :2012/06/15(金) 01:35:08.89 .net VBのラムダ式とか狂った文法だし、機能面だけはC#と対等にしてるけど、もはやボロボロでしょ
188 :デフォルトの名無しさん :2012/06/15(金) 10:44:01.68 .net 言語がどうの以前に、MVVM的インフラとして 他人のコードが重要になるから少数派は厳しい
189 :デフォルトの名無しさん :2012/06/15(金) 11:55:14.41 .net >>186 予約語増えるたびIDEが支援強化するからあまり不便に感じないのも事実 XAML開発の場合、IDEがどれだけその言語をサポートしているかが最重要 そういう意味でF#は終わってるとしかいいようがない
190 :デフォルトの名無しさん :2012/06/15(金) 13:19:16.42 .net VBはVB2005のように、厨言語と呼ばれてもいいから VBらしさを重視していた頃のほうが健全だった C#のクローンに成り下がったVBに存在意義はもう無い
191 :デフォルトの名無しさん :2012/06/15(金) 13:53:34.63 .net >C#のクローンに成り下がったVBに存在意義はもう無い そんなことばかり言うからC#厨は嫌われるんだよ おまえが存在意義感じなくても俺には必要なの!引っこんでろタコ!
192 :デフォルトの名無しさん :2012/06/15(金) 13:55:47.35 .net VBはクラシックVBとの互換性を維持したいのかしたくないのかよくわからないはじまり方をしたのが最大の失敗だったな せっかくのしがらみを捨てる最大のチャンスを逃してしまった
193 :デフォルトの名無しさん :2012/06/15(金) 13:56:55.90 .net >>191 でもまぁ今から.Net始める場合はVB.NetじゃなくてC#選ぶんちゃう?
194 :デフォルトの名無しさん :2012/06/15(金) 13:59:50.60 .net >>192 言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい とはいえVB6との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない
195 :デフォルトの名無しさん :2012/06/15(金) 14:00:50.13 .net >>193 VB.NETに移行する案件、山ほどあるんだが
196 :デフォルトの名無しさん :2012/06/15(金) 14:37:26.30 .net VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな
197 :デフォルトの名無しさん :2012/06/15(金) 14:51:15.90 .net >>196 でしょw でも変にForms覚えてる奴より 「こ れ が .NET じ ゃ 定 番 だ か ら」 と言えば、素直に話を聞いてくれるのから嬉しい
198 :デフォルトの名無しさん :2012/06/15(金) 14:59:21.72 .net Forms直に行ってデフォルトインスタンス触られるよりいいのか
199 :デフォルトの名無しさん :2012/06/15(金) 15:15:25.52 .net >>194 開発に使う分には問題ないが、言語チームがかなり苦労してそうなのが構文とかからにじみ出てくるぜ・・・
200 :デフォルトの名無しさん :2012/06/16(土) 04:16:43.61 .net VB(.NETじゃない方)も未だに元気だからなぁ PHPがじわじわ下がってきてVBと逆転してしまった。 今はまだ一時的な物だけど今後数ヵ月かけて順位が入れ替わりそうだとか何とか。 http://www.tiobe.com/index.php/content/paperinfo/tpci/
201 :デフォルトの名無しさん :2012/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など使わなくてもできてしまうのだから。
202 :デフォルトの名無しさん :2012/06/16(土) 12:40:31.71 .net なにおじさん?
203 :デフォルトの名無しさん :2012/06/16(土) 13:20:33.52 .net 何のコピペだっけそれ
204 :デフォルトの名無しさん :2012/06/16(土) 14:14:46.22 .net 懐かしいなw
205 :デフォルトの名無しさん :2012/06/16(土) 17:03:22.48 .net オブジェクト指向か
206 :デフォルトの名無しさん :2012/06/16(土) 17:52:59.93 .net VMのコストが高いのは事実
207 :デフォルトの名無しさん :2012/06/16(土) 23:27:28.75 .net Livet で Drag and Drop やりたいんだけど、どこかにサンプルないですか?
208 :デフォルトの名無しさん :2012/06/17(日) 11:27:52.39 .net 時間の無駄だと思わないの? お前がMVVM教の修験者か何かでないならコードビハインドを使え
209 :デフォルトの名無しさん :2012/06/17(日) 14:45:06.19 .net Dropイベントを処理したいだけなら>>139-140
210 :デフォルトの名無しさん :2012/06/17(日) 16:08:05.74 .net イベントだけ拾っても仕方ないでしょ 素直にコードビハインドを書くか、 Dropイベントを受け取って引数にデータ入れてバインドしたVMのコマンドを呼ぶ ビヘイビアを作りましょう
211 :デフォルトの名無しさん :2012/06/21(木) 18:57:52.75 .net MVVMって誰が提唱しだしたの?
212 :デフォルトの名無しさん :2012/06/21(木) 19:34:30.00 .net MSの中の人
213 :デフォルトの名無しさん :2012/06/21(木) 19:36:38.56 .net ビヘイビアに書くと再利用性が上がるってだけで中身はコードビハインドと大して変わらんしな まあD&Dはどっちにしても面倒だが
214 :デフォルトの名無しさん :2012/06/21(木) 22:54:05.30 .net コードビハインド書くと、VからVMアクセスするでしょ? それがかっこ悪いのよね〜
215 :デフォルトの名無しさん :2012/06/22(金) 23:26:34.40 .net VからVMにアクセスするのはコマンドも一緒だと思うが…
216 :デフォルトの名無しさん :2012/06/23(土) 07:54:12.87 .net つーかほぼすべてVからVMへのアクセスだろが。
217 :デフォルトの名無しさん :2012/06/23(土) 09:25:51.09 .net VMはVを知らないがVはVMを知っている
218 :デフォルトの名無しさん :2012/06/23(土) 11:10:17.65 .net こんにちは!VMさん。 あなたは、Vさんにフォローされてます。 Vさんをフォローしますか? する →しない
219 :デフォルトの名無しさん :2012/06/23(土) 11:29:14.41 .net MVCのCとMVVMのVMって何が違うの? データを扱うMと画面を扱うVがいて、それらを制御するCでしょ? VMもCもいっしょじゃん。
220 :デフォルトの名無しさん :2012/06/23(土) 15:06:23.66 .net >>219 ASP.NET MVCを想像してみろよ あれはCとVMの両方を持つが、どう見ても同じものじゃないだろ
221 :デフォルトの名無しさん :2012/06/23(土) 15:13:22.96 .net >>220 それが理解できていれば聞かずに済んでいるんだ、無能ですまん。
222 :デフォルトの名無しさん :2012/06/23(土) 15:30:26.15 .net VMってのは、Vから扱いやすいインターフェイスを備えたMのラッパーだよ Vを制御したりなんかしない
223 :デフォルトの名無しさん :2012/06/23(土) 15:57:05.63 .net Vを制御するのは誰? 簡単な話、Viewにある文字をModelでなんかした結果で変えたいみたいな。
224 :デフォルトの名無しさん :2012/06/23(土) 16:02:41.88 .net V自身がバインディングで変える
225 :デフォルトの名無しさん :2012/06/23(土) 19:19:17.03 .net MVCだとVは入力を扱わない
226 :デフォルトの名無しさん :2012/06/24(日) 17:03:07.28 .net Mの状態でフォーカス位置を変えたりするのがめんどい
227 :デフォルトの名無しさん :2012/06/24(日) 17:04:30.15 .net SとMの関係を一言で言うと?
228 :デフォルトの名無しさん :2012/06/24(日) 18:36:15.75 .net rot(M, -π) = S
229 :デフォルトの名無しさん :2012/06/24(日) 21:45:32.65 .net Vを制御するのはVMだろ Vの状態を持つためのMなんだから
230 :デフォルトの名無しさん :2012/06/25(月) 14:05:28.44 .net VMがVを制御しないんならVを制御する別のオブジェクトが必要だな そうだなープレゼンターとかいう名前にするといいんじゃね?
231 :デフォルトの名無しさん :2012/06/25(月) 15:04:10.95 .net 「MVVMパターンで学ぶGUIアーキテクチャパターン」? .NETラボ勉強会で話してきました! http://ugaya40.net/architecture/mvvm_to_mvc.html
232 :デフォルトの名無しさん :2012/06/25(月) 18:19:46.52 .net Mのプロパティをラップすることがあるのは、MVVM関係なく、隣人とだけ話せっていうOOPの作法だよな MVVM的には別にどっちでもよくて、やっぱりVMの本質はVの状態を持つことだよ
233 :デフォルトの名無しさん :2012/06/25(月) 22:39:40.76 .net 従来のウェブアプリ(Ajaxアプリ除く)、 ウェブフレームワークといったらいいかな? で、MVVMを使うメリットある?
234 :デフォルトの名無しさん :2012/06/25(月) 22:50:54.35 .net JSのか?
235 :デフォルトの名無しさん :2012/06/25(月) 22:54:54.79 .net JS関係なくて、普通のフォーム使った ウェブアプリ。
236 :デフォルトの名無しさん :2012/06/26(火) 00:01:38.39 .net 数ある既存の素晴らしいMVC系フレームワーク(あくまでWebでいうMVCね) に乗せられるというメリットを捨ててまで使うほどのメリットは無いと思う
237 :デフォルトの名無しさん :2012/06/26(火) 00:15:01.78 .net ASP.NET MVCにはViewModelと呼ばれるものがあるけど ステートレスでただVと1対1なだけのデータの入れ物だからMVVMとは別物だと思う
238 :デフォルトの名無しさん :2012/06/26(火) 00:17:39.51 .net MVVMはVが入力を扱う場合において威力を発揮する WebのサーバサイドだとVは入力を扱わないし、MVCはVではなくCが入力を扱う
239 :デフォルトの名無しさん :2012/06/26(火) 00:20:17.19 .net あと選択状態とかだろ ステートレスなVMはただのMだ
240 :デフォルトの名無しさん :2012/06/26(火) 00:41:58.72 .net そもそもウェブアプリってMVCじゃないだろ? データとってきてテンプレートに入れるだけじゃん。
241 :デフォルトの名無しさん :2012/06/26(火) 19:38:03.37 .net 何を突然スレ違いなことを
242 :デフォルトの名無しさん :2012/06/26(火) 20:46:48.60 .net >>233 でウェブアプリの話してるじゃん。 ちゃんと読まないでレスするの良くないよ。
243 :デフォルトの名無しさん :2012/06/26(火) 20:53:00.50 .net ここはMVCのスレではないし、クライアントとWebのMVCが同一だと言ってる奴も居ないけど
244 :デフォルトの名無しさん :2012/06/26(火) 20:57:02.48 .net このスレの1/10には MVCという単語が含まれているが? MVCのスレじゃなくても MVCと比較するのだからなんの問題もないだろ。
245 :デフォルトの名無しさん :2012/06/28(木) 18:23:25.38 .net コミュ障って生きていくの大変そうだな。
246 :デフォルトの名無しさん :2012/06/29(金) 00:08:52.57 .net そうだな。そういうことにしておけば?
247 :デフォルトの名無しさん :2012/06/29(金) 14:32:07.81 .net そこはもちょっと親身に相談に乗ってあげなきゃ 245が自殺でもしたら大変だろ
248 :デフォルトの名無しさん :2012/06/29(金) 15:32:22.10 .net ちょっと死にたい
249 :デフォルトの名無しさん :2012/06/29(金) 16:26:05.86 .net コードビハインドさえ書かなければ死なない
250 :デフォルトの名無しさん :2012/06/29(金) 17:17:54.12 .net いや、別に責務さえはっきりしていれば、別にコードビハインド書いてもいいんだよ。 MVVM≠コードビハインドはよくある誤解なので、ご注意を。
251 :デフォルトの名無しさん :2012/06/29(金) 20:05:40.23 .net >>250 が≠の意味を誤解しているのは分かった
252 :デフォルトの名無しさん :2012/07/01(日) 09:58:01.85 .net LivetってPrismにあるようなナビゲーションスタイルのアプリケーションには対応してないよね アホみたいに時間かかってる割には全体的に…
253 :デフォルトの名無しさん :2012/07/01(日) 10:29:40.96 .net お前は何を言っているんだ
254 :デフォルトの名無しさん :2012/07/01(日) 10:44:49.81 .net >>253 ウインドウ内で画面遷移するやつ(PrismのRegionみたいなの) できるなら教えてほしい
255 :デフォルトの名無しさん :2012/07/02(月) 02:00:05.07 .net 個人製作のフレームワークがごく限られたケースにしか対応してないのはよくあること 配慮してくれないと
256 :デフォルトの名無しさん :2012/07/02(月) 17:16:37.30 .net ContentControlでも使ってろ
257 :デフォルトの名無しさん :2012/07/04(水) 01:06:26.25 .net Livetの中の人、ついったーがキモい・・・
258 :デフォルトの名無しさん :2012/07/04(水) 01:21:34.90 .net WebMVC http://d.hatena.ne.jp/yojik/touch/20091019/1255963600
259 :デフォルトの名無しさん :2012/07/04(水) 10:36:51.30 .net >>153 みたいなことしちゃうアレな人だからな
260 :デフォルトの名無しさん :2012/07/04(水) 15:31:22.65 .net いやなら反論してみればいいんじゃね
261 :デフォルトの名無しさん :2012/07/04(水) 15:43:14.21 .net 例の人は目先の細かい実装に囚われすぎなんだよ >>154 で説明されているような ・VMをビジネスロジックに依存させないことによるVMの再利用性の向上 ・VをVMに依存させない(つまりVMを直接触るようなコードビハインドを書かない)ことによるVの再利用性の向上 ・Pは差し替え可能 ・DIとの相性 と言ったことに全く触れられていない
262 :デフォルトの名無しさん :2012/07/04(水) 15:56:30.88 .net 直接言って来いよ ここでやんな
263 :デフォルトの名無しさん :2012/07/04(水) 18:25:12.71 .net 技術的な話はここでいいだろ。 性格批判は向こうでどうぞ。
264 :デフォルトの名無しさん :2012/07/04(水) 18:36:48.98 .net そうそう、そのためのスレなんだから MVPVMのサンプル見ると、三つのプラットホームでVMを共通化してる VとVMの疎結合のためにPを設けてるわけだが、 現実的に考えると、VMの共通化を図る要件って実際あり得るのだろうか?
265 :デフォルトの名無しさん :2012/07/04(水) 18:44:57.68 .net >>154 のリンク先の例にあるような、同じV-VMペアを別の用途で使いまわすっていうのは 割とあるんじゃないかと思う
266 :デフォルトの名無しさん :2012/07/04(水) 19:12:57.94 .net VMの共通化は無い派。 デバイスが変われば見た目も変えたくなるし、全てのデバイスで使えるスーパーセットのVMもどうかと思う。 Mが可能な限り共有できればそれでよいと思う。
267 :デフォルトの名無しさん :2012/07/04(水) 19:25:18.53 .net 要件によるけど、スーパーセットのVM使えるところも多々あるんじゃない? 使えないところだけVMを個別作るとかが望ましいなぁ
268 :デフォルトの名無しさん :2012/07/04(水) 19:42:38.71 .net 最近客に「文字大きくしてくれ」って言われてVだけコピペしたよ
269 :デフォルトの名無しさん :2012/07/04(水) 22:00:23.71 .net ねぇ。これがどうウェブアプリに使えるの?
270 :デフォルトの名無しさん :2012/07/04(水) 22:17:08.46 .net ステートフルなGUIを作るためのものだからサーバーがHTML吐くだけのアプリには無意味 SilverlightやAjaxなら普通に使える
271 :デフォルトの名無しさん :2012/07/04(水) 23:22:11.82 .net うがやって彼女いるの? 24時間キモイことつぶやいてるよね 。 さっきも、アスペルガー丸出しだった。 彼女どころか友達いなそう。
272 :デフォルトの名無しさん :2012/07/04(水) 23:38:25.94 .net 個人攻撃に走るのはいかがなものか。
273 :デフォルトの名無しさん :2012/07/05(木) 00:22:46.48 .net >>272 今Twitter見てみ? 完全にアスペだぜ?
274 :デフォルトの名無しさん :2012/07/05(木) 01:34:01.44 .net 何言ってるのかはみてないが24/7ではなかったな 日付が飛んでたから
275 :デフォルトの名無しさん :2012/07/05(木) 01:42:41.83 .net 技術的な突込みならともかく、スレに関係ない話で個人攻撃はいくない
276 :デフォルトの名無しさん :2012/07/05(木) 07:05:45.91 .net 個人の話がしたければヲチ板へ。 アスペの話がしたければメンヘラ板へ。
277 :デフォルトの名無しさん :2012/07/05(木) 07:37:21.07 .net ウガヤ氏に罵倒された勘違いMVVMerなんですね。わかります(´・ω・`)
278 :デフォルトの名無しさん :2012/07/05(木) 15:11:50.77 .net あれも2ちゃんでの話に文句があるなら2ちゃんでいえばいいのにな
279 :デフォルトの名無しさん :2012/07/05(木) 19:40:28.20 .net 煽り耐性ゼロだから2ch無理とか言ってたけど 正直あのエントリに比べたらここやWPFスレの方がマイルドw
280 :デフォルトの名無しさん :2012/07/05(木) 20:43:53.52 .net いやさすがにそれはない
281 :デフォルトの名無しさん :2012/07/05(木) 20:46:14.32 .net ム板は煽られても他人の振りが出来るからなあ
282 :デフォルトの名無しさん :2012/07/05(木) 21:23:08.74 .net ここってJavaFXの話題もあり?
283 :デフォルトの名無しさん :2012/07/05(木) 22:08:33.80 .net ありじゃね
284 :デフォルトの名無しさん :2012/07/05(木) 22:53:24.29 .net JavaFXが最初に世に出た当時はなんでXMLじゃなくてわざわざ独自スクリプトなんだ ボケカスと言われてたが、デザイナとプログラマの分業なんて幻想であって ある程度ビューに振る舞い書けた方が便利だということを見越した判断だったんだな XAMLのビヘイビア地獄よりははるかにマシだわ
285 :デフォルトの名無しさん :2012/07/05(木) 22:57:52.73 .net 今FXやるぐらいならSLでいいわ
286 :デフォルトの名無しさん :2012/07/05(木) 23:14:34.76 .net ビヘイビア地獄ってなんだよ そんなに地獄に感じるならコードビハインドにコード書いたっていいんだぞ
287 :デフォルトの名無しさん :2012/07/06(金) 00:55:22.61 .net .triggerを手で書くのはうぜぇっていうのは同意するが あれはblendで書く物だろ
288 :デフォルトの名無しさん :2012/07/06(金) 01:54:31.30 .net ビヘイビアもトリガーもインフラが整った環境じゃないとまともに使えん 自力で整えようとすると相応の労力が強いられる 遊びや自己学習でする分には良いけど、サクッと作りたいときや仕事だと2の足を踏むなー Blendみたいな環境が無いと本気で使おうとは思わない コードビハインドでもMVVM自体は可能だから手っ取り早く作りたいときはコードビハインドで良いだろ
289 :デフォルトの名無しさん :2012/07/12(木) 00:19:31.36 .net MVVMってプラガブルMVC劣化させたのと同じじゃねぇの? プラガブルMVC劣化版と何が違うの?
290 :デフォルトの名無しさん :2012/07/12(木) 00:36:47.13 .net XAMLのこと知らないなら黙ってろ
291 :デフォルトの名無しさん :2012/07/12(木) 10:06:32.25 .net 非同期処理ってモデルでSynchronizationContextとか使って面倒見たほうがいい? それともやっぱりモデルの状態が複雑になるのは避けてVMでスレッド動かす?
292 :デフォルトの名無しさん :2012/07/12(木) 10:13:46.36 .net ポリシー次第じゃない? モデルまではそのへんを気にせずガンガン使う→VMで考慮 VMはシンプルに作りたい→上で考慮 自分は前者だな。
293 :デフォルトの名無しさん :2012/07/12(木) 18:25:57.29 .net モデルで非同期してVMではメインスレッドが普通じゃない? ViewからVM呼ぶんだし
294 :デフォルトの名無しさん :2012/07/12(木) 18:51:53.23 .net UIにアクセスするとことか内部の状態を変えるとかだけVMでContextで同期取ればいいやん
295 :デフォルトの名無しさん :2012/07/19(木) 21:22:47.22 .net DIコンテナは何がいい? UnityとNinjectとAutofac試してAutofacが気に入ったんだけど
296 :デフォルトの名無しさん :2012/07/21(土) 17:29:43.89 .net >>290 なんの関係が?
297 :デフォルトの名無しさん :2012/07/24(火) 05:21:39.59 .net Livetの新しいの公開されたけど、これ、 旧バージョンインストールして作ってたアプリある場合、 新しいLivet入れても問題ないのかな? 旧バージョンのままじゃないと動かなくなるとかだと困る
298 :デフォルトの名無しさん :2012/07/24(火) 06:12:23.43 .net Livetのプロジェクトテンプレート使ったんならLivet.dllのローカルコピーがあるべ。
299 :デフォルトの名無しさん :2012/07/24(火) 06:28:21.45 .net それだと古い方のdllも残しておかないといけないってこと? 新しい方に差し替えたらそのまま動かないのかな… 新しいPCにVisualStudioとLivetの新しいのだけ入れたら、 旧バージョンで作ったアプリの修正とかはできなくなる? 上書きインストールしていいのかとか、 そこら辺、公式サイトに何も書いてないから怖くて入れられない
300 :デフォルトの名無しさん :2012/07/24(火) 08:16:05.78 .net >>299 ここに書くよりも直接連絡しろよw
301 :デフォルトの名無しさん :2012/07/24(火) 08:39:50.00 .net Livetのテンプレート使って作ったプロジェクトならInfrastructureAssembliesフォルダにいままでのLivet.dllはそのままあるし 参照設定もそれを参照しているから自分で明示的に置き換えない限り新しいバージョンのLivetを入れてもそいつのバージョンはそのまま 自分でProgram FilesにあるLivet.dllに参照設定してたらアップデートしたらアップデートしたバージョンのものになる また新しいものに差し替えたとしても破壊的変更があるものはそのままでは動かないし、特定バージョン参照してたらたとえ破壊的変更がなくともリビルドが必要 Livetに限らずライブラリ使うときの基本的なことだと思うが
302 :デフォルトの名無しさん :2012/07/24(火) 10:53:05.83 .net >>300 諸般の事情で直接連絡したくない場合もあるんだよ そのための2chだろうが
303 :デフォルトの名無しさん :2012/07/24(火) 13:52:17.88 .net んなわけねーだろ 捨てアカで報告してこい
304 :デフォルトの名無しさん :2012/08/08(水) 10:33:09.91 .net MVVMerなら即VS2012にするよな?
305 :デフォルトの名無しさん :2012/08/08(水) 10:47:52.07 .net それはあんまり関係ないな
306 :デフォルトの名無しさん :2012/08/08(水) 19:08:07.03 .net MVVMerとかフルMVVMとか、日本だけの造語が目立つな
307 :デフォルトの名無しさん :2012/08/08(水) 19:16:36.34 .net 2012というか.NET4.5だとXP切り捨てになるのが
308 :デフォルトの名無しさん :2012/08/08(水) 19:20:24.35 .net >>307 です。 VB6ランタイムはWin8でも動くと言うのに酷い話だ。
309 :デフォルトの名無しさん :2012/08/08(水) 19:33:31.78 .net MVVMはWindows7以降用技術です
310 :デフォルトの名無しさん :2012/08/08(水) 23:10:28.72 .net いいえ、ウェブ技術(JavaScript)です。 http://ameblo.jp/ca-1pixel/entry-11298459074.html knockout.js (http://knockoutjs.com/) knockout.jsはMVVM(Model-View-ViewModel)パターンのフレームワークです。 双方向データバインディングやアイテムテンプレート等の機能があり、SilverlightやWPF開発者にはかなりとっつきやすいフレームワークだと思います。
311 :デフォルトの名無しさん :2012/08/10(金) 00:03:20.35 .net Win8でも動作するし、VB6でのMVVMまだ?
312 :デフォルトの名無しさん :2012/08/10(金) 00:29:56.78 .net パターンにまだ?って言われても 自分でやることじゃねーのか
313 :デフォルトの名無しさん :2012/08/10(金) 00:44:36.96 .net vb6でも普通にMVVMできるだろう Observerやビヘイビア作るのが難儀な気がするからコードビハインド主体になりそうだけど
314 :デフォルトの名無しさん :2012/08/10(金) 10:33:45.16 .net おまいら、なにか根本的に勘違いしてるだろ
315 :デフォルトの名無しさん :2012/08/10(金) 12:38:35.91 .net 誰に言ってんの 何を言ってんの
316 :デフォルトの名無しさん :2012/08/10(金) 13:57:56.40 .net MVVMの定義に相当するものはVB6ではできんだろ。 MVPも厳しい。 おとなしく、モジュール分割をちゃんとした昔ながらのC/Sシステムっぽくやっていろ。 …っという話かな?
317 :デフォルトの名無しさん :2012/08/10(金) 22:33:15.87 .net クラスをちゃんと定義すりゃできるだろ ライブラリで用意されてるインフラ全部自分で作らにゃならんけど
318 :デフォルトの名無しさん :2012/08/10(金) 22:48:20.32 .net VB6の仕様だけでインフラ作るのは厳しくないかね? いや、API使ってフックレベルからやれば、そりゃ出来るだろうけど
319 :デフォルトの名無しさん :2012/08/10(金) 22:52:44.04 .net MVVMのどういう場面だ?
320 :デフォルトの名無しさん :2012/08/11(土) 01:28:16.52 .net VBだとクラスモジュールから イベント送信できるんだから MVVMは実装しやすい方法言語だよ。
321 :デフォルトの名無しさん :2012/09/08(土) 12:02:20.04 .net 可能性とかで語られてもな。 実際にそれを VB6 でやる気になるかい? って話も重要だろ
322 :デフォルトの名無しさん :2012/09/08(土) 12:30:15.15 .net 「VB6 を やる気にならない」が正解
323 :デフォルトの名無しさん :2012/09/08(土) 12:58:28.48 .net VBってまだ絶滅してないのか 何のためにMSはC#出したんだ
324 :デフォルトの名無しさん :2012/09/08(土) 23:34:49.46 .net MSほど多様な製品を長期に渡ってサポートしてくれるとこは他にない。 VB6が世に出てから14年経つがWin8でも公式にサポートされた。 リプレースするにも金がかかるから動く限りは保守しながら使いたいって客は案外多いよ。
325 :デフォルトの名無しさん :2012/09/10(月) 11:25:40.15 .net そういう用途ならhost側で動かなくてもVMで動いてくれりゃ充分なんだが
326 :デフォルトの名無しさん :2012/09/21(金) 19:02:26.84 .net VB早く消えてなくならないかなー MSもサクッと切ればいいのに
327 :デフォルトの名無しさん :2012/09/21(金) 19:03:37.99 .net リプレースに金がかかるかもしれないが保守にも金がかかる
328 :デフォルトの名無しさん :2012/09/21(金) 20:02:31.93 .net 案外金が掛かった方が良いのかも知れない 払ってくれる相手なら
329 :デフォルトの名無しさん :2012/09/21(金) 21:11:01.59 .net VB6からC#へのリプレースおいしいです
330 :デフォルトの名無しさん :2012/10/06(土) 11:05:26.15 .net んで MVVMでアプリつくってるやついるの??? まじでいらねぇんだが.
331 :デフォルトの名無しさん :2012/10/08(月) 09:21:35.40 .net 一つの画面でいろいろやるタイプのアプリには向かないのは事実
332 :デフォルトの名無しさん :2012/10/08(月) 19:09:14.56 .net 一つの画面で色々やるというか、Vの作り込みの比重が多いアプリだとあんま活躍しないわな。
333 :デフォルトの名無しさん :2012/10/08(月) 20:43:24.80 .net ツール類には向かんわな せいぜい複雑なダイアログがあればそこに使う程度
334 :デフォルトの名無しさん :2012/10/08(月) 21:26:12.25 .net 複雑なウィンドウなら複数のコントロールに分割すればいい話じゃね
335 :デフォルトの名無しさん :2012/10/13(土) 17:02:29.65 .net メモリリークする原因がわからない
336 :デフォルトの名無しさん :2012/10/13(土) 17:08:27.07 .net イベント
337 :デフォルトの名無しさん :2012/10/13(土) 19:31:26.75 .net >>335 メモリを使っている人がいるんじゃないかな
338 :デフォルトの名無しさん :2012/10/14(日) 16:54:03.98 .net 徐々にウェブの世界でも MVVMが浸透してきたな。 MVCだけじゃ、いろいろ足りない。
339 :デフォルトの名無しさん :2012/10/14(日) 17:05:03.26 .net >>335 こういうのでは? https://www.google.co.jp/search?q=mvvm+ メモリーリーク&ie=UTF-8&oe=UTF-8&hl=ja
340 :デフォルトの名無しさん :2012/10/14(日) 20:38:40.26 .net >>338 Ajaxとかだるすぎ WebはサーバーでHTMLを垂れ流すだけという低脳さが良いのに
341 :デフォルトの名無しさん :2012/10/16(火) 00:33:06.45 .net >>340 テンプレート使ったこと無いの? サーバーでテンプレートに渡す値を 値そのまま渡せばそれがAjaxになる。 サーバーサイドアプリ - テンプレート処理 なのだから、確実にAjaxの方が簡単になってる。;
342 :デフォルトの名無しさん :2012/10/16(火) 01:04:33.51 .net 意味がわからない テンプレートって普通サーバーで使うもんだろ? クライアント側でテンプレート使うってこと? それがサーバーでやるより簡単だと言える根拠は?
343 :デフォルトの名無しさん :2012/10/16(火) 01:11:23.92 .net どっちも簡単だろ。 jQueryみたいなライブラリが充実してきて笑えるぐらい簡単になった。 これが難しいってム板に居られる資質がないとしか思えん。
344 :デフォルトの名無しさん :2012/10/16(火) 18:10:03.69 .net >>342 サーバの負荷の関係上、サーバでテンプレートエンジン使わない方がいいとかもあるんだけど、 最近は、サーバから戻ってくるのはJSONオブジェクトとテンプレートで、クライアントでテンプレート エンジンかましてページを生成する方が良いような気がしてるよ。基本Ajaxで。 受けとったJSONオブジェクトを元に、自力でDOMを書き換えても良いし。
345 :デフォルトの名無しさん :2012/10/16(火) 20:40:35.72 .net クライアントが以前より負荷が高くなるという問題もあるけれど、 以前というのはもう十数年前だったら問題になるというレベルで 今はクライアントは十分な性能を持ってるしね。 ブラウザ自体も速くなった。 それに比べるとネットワークはまだまだ遅いわけで、 テンプレートはローカルにキャッシュしておいて データ量を減らすほうが得策かな。 サーバー負荷も低くなるし。 これぐらいだれでも思っていることで、 普通サーバーでやるもんだろで終わってる人ってのは 何も考えてないとしか思えないけどw
346 :デフォルトの名無しさん :2012/10/16(火) 20:43:20.12 .net 一方Twitterは以前API直接たたいてJSONからDOM生成してたのが最近生成済みのhtml片を鯖から受け取るようになった
347 :デフォルトの名無しさん :2012/10/16(火) 21:07:29.77 .net 完全なAjaxができるならいいが、 普通そうはいかないもんな どうせサーバーで生成しなきゃいけないならなるべくサーバーにまとめちゃった方が楽
348 :デフォルトの名無しさん :2012/10/16(火) 21:18:45.66 .net どっちみちAjaxは使わないといけないんだから クライアントにまとめちゃったほうが楽
349 :デフォルトの名無しさん :2012/10/16(火) 21:24:48.64 .net Ajaxはオプションだろ 利便性のためにクライアントでAjax使ってバリデーションしたとしても、 どのみちサーバーでもやらないといけない
350 :デフォルトの名無しさん :2012/10/16(火) 21:30:02.30 .net Ajaxはバリデーション以外で使うものって わからないのか?w バリデーションなら単なるJavaScriptで良い
351 :デフォルトの名無しさん :2012/10/16(火) 21:31:42.33 .net >>350 JavaScriptでもいちいちバリデーションするの? バカ?
352 :デフォルトの名無しさん :2012/10/16(火) 21:32:50.76 .net JavaScriptでバリデーションが通ったら サーバーでは検証せずにそのままDBに入れちゃうの? やばくねそれ
353 :デフォルトの名無しさん :2012/10/16(火) 21:34:43.44 .net 話し理解できてないの?w バリデーションをAjaxで行う=サーバーで通信して行うから、 そのバリデーションはサーバーでやってる事になるだろうって話だ。 あと、サーバーでやらないなんて一言も言ってない。 なんでこんなに文章読めないの?馬鹿なの?
354 :デフォルトの名無しさん :2012/10/16(火) 21:36:01.79 .net サーバとJavaScript両方でバリデーションするの? マジキチ?
355 :デフォルトの名無しさん :2012/10/16(火) 21:36:16.18 .net >Ajaxはバリデーション以外で使うもの >バリデーションなら単なるJavaScriptで良い さっきと言ってることが180度違うけど
356 :デフォルトの名無しさん :2012/10/16(火) 21:38:07.68 .net うーん? > Ajaxはオプションだろ >>349 が オプションでやるって書いてあるじゃん。 みんな最初っから、両方でやるという前提で話してるんだが。 両方でやるのは、レスポンスを早くしてユーザビリティを上げ 無駄な通信を削減するため。言わなくても常識だと思っているが。
357 :デフォルトの名無しさん :2012/10/16(火) 21:38:54.60 .net >>355 そりゃ、さっき言った人俺は別人だからねw
358 :デフォルトの名無しさん :2012/10/16(火) 21:40:19.92 .net みんなって誰? マジキチは一人で十分なんだがw
359 :デフォルトの名無しさん :2012/10/16(火) 21:40:51.87 .net >>358 みんな=お前以外
360 :デフォルトの名無しさん :2012/10/16(火) 21:41:02.38 .net ああ、別人という設定なんですね、わかります
361 :デフォルトの名無しさん :2012/10/16(火) 21:41:14.80 .net 鯖とJS両方で検証するだろうよ 検証はカスタム属性から自動生成でもしたらいいってかそういうのすでにある
362 :デフォルトの名無しさん :2012/10/16(火) 21:43:13.41 .net 一人だけ、程度の低い人が居ますね
363 :デフォルトの名無しさん :2012/10/16(火) 21:45:12.56 .net >>362 自己紹介は結構です
364 :デフォルトの名無しさん :2012/10/16(火) 21:58:42.34 .net 今時Ajaxだるいと言って済ませられるような、簡単なお仕事をしているぬるま湯な環境うらやましす コストをかけずにAjaxやJSでのMVVMをどう実現するか試行錯誤している人が多い中で
365 :デフォルトの名無しさん :2012/10/16(火) 21:59:49.81 .net ×今時Ajax ○いまさらAjax
366 :デフォルトの名無しさん :2012/10/16(火) 22:12:49.60 .net クライアントにまとめるとか言って鯖から全件投げつけてクライアント側で検索やらせる奴とかが現れませんように
367 :デフォルトの名無しさん :2012/10/16(火) 22:16:13.83 .net >>366 それはさすがに見た事ないけど ページングせずに数万件の検索結果のレコードを送り付けてくるやつなら見た事がある。
368 :デフォルトの名無しさん :2012/10/16(火) 22:16:48.57 .net そのうちJavaScriptでクラサバやるわけですね
369 :デフォルトの名無しさん :2012/10/16(火) 22:17:15.76 .net node.js最強
370 :デフォルトの名無しさん :2012/10/16(火) 22:20:02.67 .net >>366 ASP.NET素人だとクライアント側にViewStateで全データを保管して、サーバー側でページングとか日常茶飯事だぜ?
371 :デフォルトの名無しさん :2012/10/16(火) 22:22:07.06 .net まーた、なんか低レベルの流れになってんなー
372 :デフォルトの名無しさん :2012/10/16(火) 22:30:55.59 .net 下見てもつまらないよ
373 :デフォルトの名無しさん :2012/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 http://bloggemdano.blogspot.jp/2012/10/knockoutjs-added-to-fc-mvc-4-single.html
374 :デフォルトの名無しさん :2012/10/21(日) 22:42:39.14 .net なんか最近尾上の言うことがぶれすぎ 先月ぐらいから少しずつさりげなくぶれ始めてたんだが なにがあったんだ? コードビハインドとか頭おかしくなったのか? その内容自体は宗教だからどうでもいいが さんざん自分の考えと違うやつを罵倒してきた人間が そこまでころっと価値観変えてどうなんだ?
375 :デフォルトの名無しさん :2012/10/21(日) 22:56:05.22 .net コードビハインドを無理に排除しようとすると、どうしても 特定のビュー専用のビヘイビアがしばしば出てくる。 その場合無駄に煩雑になるだけで実質何のメリットもない。 彼も気付いちゃったんだよ。
376 :デフォルトの名無しさん :2012/10/22(月) 06:04:37.89 .net 単に自分の考えが甘かった、自分の見える世界だけしか見ていなかった事に気がついただけだろ。 ああいうキャラの人間はだいたいそんなもん。
377 :デフォルトの名無しさん :2012/10/22(月) 08:48:01.98 .net MVVMやっててWPFの仕組みがわかってくると、 意外とWPFのコードビハインドってよくできてることに気付くよね 正直、ビヘイビアは再利用できるものだけに限定して積極的にコードビハインド使うのがベストだと思う
378 :デフォルトの名無しさん :2012/10/22(月) 09:20:38.69 .net メッセージも多くの場合Vがインターフェイスを実装すれば十分 メモリリークガーとか言うけど、そんな大したことじゃないだろ。 参照管理の問題なんてどうせWPF関係ないところでも常に付きまとうのに、 それをコードビハインドの問題であるかのように大袈裟に騒いで、 WPFがまだよくわかってない人に変な先入観を植え付けている。
379 :デフォルトの名無しさん :2012/10/22(月) 09:41:07.23 .net MVVMというより、Blend至上主義みたいな話になっちゃってるような所があったからな。
380 :デフォルトの名無しさん :2012/10/22(月) 12:14:52.36 .net 本人はBlendを第一に考えてるようだしその辺だろうな
381 :デフォルトの名無しさん :2012/10/24(水) 00:05:27.67 .net Blend 2012まだかよ
382 :デフォルトの名無しさん :2012/11/02(金) 12:07:46.01 .net ViewModelのインターフェイスって意味ある?
383 :デフォルトの名無しさん :2012/11/02(金) 14:00:24.51 .net Mや各種サービスからのコールバックに使うとか コードビハインドでVからVMのメソッドを呼ぶときにV->VMを密結合させたくないとか そういうときには意味ある
384 :デフォルトの名無しさん :2012/11/02(金) 14:32:57.66 .net まあ通常は継承ベースでいいと思う
385 :デフォルトの名無しさん :2012/11/04(日) 22:35:06.98 .net >>383 コードビハインドってViewって認識なの? 否定じゃなくて単純に質問。
386 :デフォルトの名無しさん :2012/11/04(日) 22:49:04.80 .net Viewとみなすのがふつう ビヘイビアもコードビハインドの一形態なので同じくView
387 :デフォルトの名無しさん :2012/11/05(月) 20:21:18.14 .net 結局 vmに置かれるviewに強く関係するけど 共通ロジックの置き場がない
388 :デフォルトの名無しさん :2012/11/05(月) 23:16:15.79 .net 共通ロジックならUTILとかに置けばいいだろ?
389 :デフォルトの名無しさん :2012/11/05(月) 23:36:53.45 .net >>386 Viewとみなすのは分かったんだけど VMじゃななくてVとみなす理由はなんなのかな?
390 :デフォルトの名無しさん :2012/11/05(月) 23:38:49.26 .net >>389 ビューと不可分だから
391 :デフォルトの名無しさん :2012/11/05(月) 23:45:04.35 .net >>390 WinFormsのコードビハインドなら不可分といえなくもないけど WPFはそうともいえないんじゃね?
392 :デフォルトの名無しさん :2012/11/05(月) 23:51:07.82 .net >>391 この場合の不可分は「単体テスト可能かどうか」な。 ユーザーコントロールやウィンドウのクラスに対してXAMLを差し替えることは普通はできないし 無理矢理読み込むファイルを変えたとしてもコードビハインドからコントロールを直接触ってるから 結局ビューを表示して実際に操作してみないとテストできないわけ。 だからコードをビューから分離してビューなしでテストできるようにしましょうっていうのがVM。
393 :デフォルトの名無しさん :2012/11/06(火) 00:03:14.09 .net >>392 なるほどねー
394 :デフォルトの名無しさん :2012/11/06(火) 00:05:46.84 .net >>387 ViewModelsってフォルダにそういう機能のクラスを作ればええんや まーそもそも、Views、ViewModels、Modelsってフォルダ群もなんだかなーって気もするが そのほかのフォルダ構成でやってるやつおる?
395 :デフォルトの名無しさん :2012/11/06(火) 03:50:39.94 .net フォルダ分けない方が楽な気はするがその3つにしてるな
396 :デフォルトの名無しさん :2012/11/06(火) 15:16:09.04 .net М氏も「MVVM=コードビハインド無し」みたいな誤解撒き散らしてたし 「フルMVVM」って造語が誤解生んだのも事実 でもだからなんなの?勝手に誤解してずっこけたの本人のせいじゃん お前が元信者だから裏切られた感強いだけだろ
397 :デフォルトの名無しさん :2012/11/06(火) 16:34:58.61 .net dynamicを積極的に使うのはどうだろう VMがdynamic型でVへの参照を保持して動的にVのメソッドを呼ぶようにすれば、 メッセージやインターフェイスを介さなくてもVM->Vの密結合が避けられる。 dynamicなら完全に透過的なプロキシが使えるから、たとえばメモリリークの恐れがある箇所は WeakReferenceでビューへの参照を持ち、ビューがGCされたらnullオブジェクトとして振る舞う ようなプロキシを利用すれば、メモリリークの問題もコードの見た目を全く汚さずに解決。 型無しがダメだというならメッセージだって同じようなもんだよね。 (Vが当該メッセージをサポートしているかどうかはコンパイル時にチェックされないという意味で)
398 :デフォルトの名無しさん :2012/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(); } }
399 :デフォルトの名無しさん :2012/11/09(金) 04:16:24.83 .net MVVMってメトロになってもやること変わらんの? 技術的にはあっちが本流だと思うんだけど
400 :デフォルトの名無しさん :2012/11/09(金) 09:11:57.38 .net どうしてデザパタが環境によって変化すると思うんだw 技術じゃないぜ。概念だろ。
401 :デフォルトの名無しさん :2012/11/09(金) 10:13:41.46 .net この手の概念って「ある一定の規則とか法則に名前をつける」 だけの話だからね。
402 :デフォルトの名無しさん :2012/11/09(金) 11:31:24.11 .net コーディング段階は結構変わるがな
403 :デフォルトの名無しさん :2012/11/09(金) 22:45:20.26 .net >>401 概念の話と 概念に名前をつけるって 話がごっちゃになってるよ。 概念に名前をつけるのは重要なことだが、 もちろん概念そのものも重要なことだぞ。
404 :デフォルトの名無しさん :2012/11/11(日) 00:32:37.19 .net すいません、よかったら教えてください MVVM Light Toolkitで遊んでるんですが、テンプレートから作成されるModelの IDataServiceのメソッドがActionを渡して結果をコールバックさせる形になっています 普通に戻り値や例外を返せばいいと思うのですが、あえてコールバックさせているのはなぜなんでしょう? 考えても理由がちっとも思いつかないので、もしわかったらお教えください よろしくお願いします
405 :デフォルトの名無しさん :2012/11/11(日) 00:36:08.24 .net >>401 MVVM以前からMVVM的な物が存在していたということ?
406 :デフォルトの名無しさん :2012/11/11(日) 00:40:40.06 .net >>404 処理に時間がかかる場合にGUIが固まるのを防ぐためだろ Webからデータを取ってくるような場合は言うまでもないが、 ローカルなファイルやデータベースからちょっと取ってくるくらいでも結構固まる
407 :デフォルトの名無しさん :2012/11/11(日) 00:53:11.62 .net >>406 それはasync、awaitの非同期処理はModel内部で行ってServiceのメソッドをasync宣言しない方がよい ということでしょうか? Serviceのメソッド自体が非同期メソッドであれば画面が固まったりしないですよね? そこら辺も初めてさわったのでトンチンカンなこと言ってたらすいません
408 :406 :2012/11/11(日) 00:56:51.28 .net あ、MVVM Light Toolkitは別にasync、awaitのサポート環境を限定してないからかな? 逆にいうとasync、awaitが使える環境ならば別にコールバックさせる必要はないってことでいいんでしょうか??
409 :デフォルトの名無しさん :2012/11/11(日) 00:57:16.17 .net >>407 いやMVVM Light Toolkitは結構昔からあって、当時はasyncが無かっただけ U氏はasyncは内部で使うものであってインターフェイスに使うなとか 思い込みだけで頓珍漢なことを言ってたが 今からasync前提で作るなら普通に使っていいよ
410 :406 :2012/11/11(日) 01:01:22.02 .net >>409 なるほど、納得しました サービスレベルでasyncにしてコールバックは利用しない方法でいってみます いろいろありがとうございました
411 :デフォルトの名無しさん :2012/11/12(月) 00:22:58.42 .net >>409 うがやは、C#というか言語や.NETに関して知識なさすぎだからな。 ライブラリ設計者としてのセンスもない。
412 :デフォルトの名無しさん :2012/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のプロパティに設定しています が・・・なんかいまいち感が 他にいいアイディアってあるのでしょうか?
413 :デフォルトの名無しさん :2012/11/12(月) 20:12:25.87 .net ListBoxのItemsSourceにVMたくさん入ったコレクションセットして ContentControlのContentか任意のViewコントロールのDataContextにListBoxのSelectedItemをバインドするのが楽じゃね
414 :デフォルトの名無しさん :2012/11/12(月) 21:01:20.01 .net あぁそっか、そういうやり方があるんですね 勉強になります ありがとうございました もしよかったらもう一つ教えてください 実はAで選択されたItemをまた別のコントロールに今度は単一を設定するのではなくて どんどん追加もしたいんですが・・・ そういう場合はどうするのが良いのでしょうか? 一つ一つの機能は徐々にわかってきたんですが、合わせ技になると発想がついてこないっす
415 :デフォルトの名無しさん :2012/11/12(月) 21:01:56.33 .net SelectedItemは同意だけど、VM自体はPage用1つだけでいいと思う 「AB両方の表示用を子プロパティとして持つクラス」のコレクションを VMがプロパティとして公開して、Aがそれにバインド、 BがAのSelectedItemにバインド、が一番すっきりかな
416 :デフォルトの名無しさん :2012/11/12(月) 21:14:21.92 .net >>415 なるほど、そういうやり方もあるのか そこで一つ疑問が出てきてしまったんですが・・・ WebでMVVMのユーザコントロールのサンプルをいくつか見たところ たまたま?すべてのサンプルがユーザコントロール毎に定義されていて それを鵜呑みにしてたんですが・・・ 親になるビューだけがVMを持つのとコントロールも独自にVMを持つケース どういった感じで使い分けたらいいのでしょうか? ちなみに今回の場合、AもBも表示するだけではなくて、それなりに個々の コントロールに機能を持っています Aはソート順を変えたり絞り込んだり、Bは詳細を編集したりなどです
417 :デフォルトの名無しさん :2012/11/12(月) 23:25:58.38 .net >>416 俺は複数のWindowでControl使いまわしてるから、Controlに専用のViewModel持たせてるよ
418 :デフォルトの名無しさん :2012/11/13(火) 00:54:12.58 .net Model側でコレクションを持つ場合、そのVMも子ModelのVMのコレクションを持つようにしてるかな この場合Model側もObservableCollection的な通知機能付コレクションを使うことになるが 子ModelがVM持つほどの意義がない場合は親Modelのコレクションそのまま使ったりもする
419 :デフォルトの名無しさん :2012/11/13(火) 04:42:27.67 .net 414は単純に、「別のコントロール」側のItemsSourceになってるコレクションに Addしてやればいいだけだと思う… 単純過ぎるので質問の意味取り違えてるかも知れないけど 416についてはケースバイケース どうするのが、開発や保守しやすいか。それ次第でしょう
420 :414 :2012/11/13(火) 20:36:52.73 .net 昨日はレスいただいたのに返事できずにすみません >>417-418 コントロールは再利用するつもりなので、今回はコントロールにVM持たせてみます 子もVMに入れてみようと思います
421 :デフォルトの名無しさん :2012/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)の部分が特にしっくりこなくて気持ち悪いというのが、質問させていただいた経緯です
422 :デフォルトの名無しさん :2012/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の処理も全て完結 って感じにするかな…。
423 :デフォルトの名無しさん :2012/11/13(火) 21:40:19.58 .net >>422 ふむふむ、なるほど レス読ませてもらって考えているうちに思ったんですが、AVMにItemが選択された ことを通知するイベントを定義して、そこにラムダ式突っ込んであげれば良いのかな? って気がしてきました 何が気持ち悪かったって、AVMにはほかにプロパティもあるわけで、PropertyChangedを ハンドルしていると、別にPageには興味がないプロパティも飛んでくるわ プロパティの名前をAVMで定数定義してAVMからもPageVMからも参照しようとすると、 MVVM Light ToolkitでVMのインスタンスを生成するときにエラーで落ちちゃって プロパティ名をAとPageの双方に文字列で指定してた所なんで、一番キモイ所は解決された気がします ただなんか手法が古臭いような気がしないでもないですがw XAMLでこう書いてああ書いてすればサクっとできちゃうよ!的な解決策はさすがにないですよね?w
424 :デフォルトの名無しさん :2012/11/13(火) 23:15:36.04 .net @ugaya40: 難しいとかいってる人はコードビハインドでMVVMしましょ コイツ、MVVMでコードビハインド使うのはMVVMを理解していない無能のすること とか散々ほざいてたくせしてなに言っちゃってんのって感じなんだが。 「難しいとか言ってる人」とかつけ加えてて誤魔化してんじゃねーよ。 難しいとか難度の問題じゃないってわかんねーのかな?
425 :デフォルトの名無しさん :2012/11/13(火) 23:18:09.19 .net コードビハインドを使用したものは神の怒りに触れ 永久にメモリリークの責め苦を受けるんじゃなかったのかw
426 :デフォルトの名無しさん :2012/11/13(火) 23:23:22.77 .net テンプレートにハンドラつけた場合じゃねそれ
427 :デフォルトの名無しさん :2012/11/13(火) 23:28:45.74 .net 自作のライブラリーをコードビハインドに対応させるって言ってたし完全に方向転換したんじゃないのかな? それ自体はいい事だとは思うけどね ただ、間違った持論でMVVMの概念をめちゃくちゃにした罪は大きいよね きちんと間違ってたことを認めればいいけど、あの歪んだ性格じゃ無理だろうな…
428 :デフォルトの名無しさん :2012/11/13(火) 23:33:30.98 .net 必死にPSDって略語を流行らせようとしてるのに誰も使ってないのが泣ける、というか笑えるw
429 :デフォルトの名無しさん :2012/11/13(火) 23:39:32.37 .net PDS言ってるのは知ってるがPSDは知らんな
430 :デフォルトの名無しさん :2012/11/13(火) 23:40:55.84 .net DPSならしってる。全部知ってる。DPS全部
431 :デフォルトの名無しさん :2012/11/13(火) 23:43:51.07 .net 社内ではよく使うがネットで使う機会が無い
432 :デフォルトの名無しさん :2012/11/13(火) 23:45:32.47 .net 本人もあれだけど最近はアンチのがウザいな 直接煽られたことある人はそうなるのか
433 :デフォルトの名無しさん :2012/11/13(火) 23:50:31.04 .net 面白がってアンチに乗じてアンチごっこしてるやつが一番うざいし役に立たない
434 :デフォルトの名無しさん :2012/11/14(水) 00:37:00.22 .net MSの将来が不安なのでAndroidのMVVM環境教えてください
435 :デフォルトの名無しさん :2012/11/14(水) 00:42:27.62 .net JavaScriptでよければ KnockoutがMVVMのフレームワークだよ
436 :デフォルトの名無しさん :2012/11/14(水) 00:47:11.25 .net Androidでバインディングは無理だと思う コントロールがそれぞれ独自にXML読むクソ設計なんだぜ?w
437 :デフォルトの名無しさん :2012/11/14(水) 00:59:28.17 .net AndroidのフレームワークでバインディングやるならActivityのコード側でsetBindingみたいなメソッド呼んで 実装はリフレクションで頑張るしかないだろうけど そんなことするくらいならPassive Viewの方がいいと思う
438 :デフォルトの名無しさん :2012/11/14(水) 01:13:42.40 .net さすがに今年中にBlend出してくれんとしんどいわMSさん
439 :デフォルトの名無しさん :2012/11/14(水) 01:24:18.30 .net Expression Studio 5まだー?
440 :デフォルトの名無しさん :2012/11/14(水) 02:03:13.02 .net android binding があるでしょ
441 :デフォルトの名無しさん :2012/11/14(水) 21:26:33.41 .net @ugaya40: 俺はWin8デスクトップにはスタートメニューが必要だと思うけど、シノフスキーさんの辞任と現時点で結びつけたりするわけもなく。ただその反対意見もまた極端なのが散見してるな。どっちもアホじゃないですか。 散々、極端なことを言ってたのはお前だろ?w 自分で自分がアホって自覚がちゃんとあるんだな。
442 :デフォルトの名無しさん :2012/11/14(水) 21:27:50.23 .net >>426 メモリーリークするの? メンドクサイからテンプレートから呼ぶようにしたんだけど・・・
443 :デフォルトの名無しさん :2012/11/14(水) 21:49:40.33 .net >>441 お前さん、うがやのこと大好きなんだな
444 :デフォルトの名無しさん :2012/11/14(水) 22:08:23.42 .net そのうちVSスレのキチみたいに発狂しちゃうんだろうな
445 :デフォルトの名無しさん :2012/11/14(水) 22:12:55.52 .net さすがに粘着が過ぎる
446 :デフォルトの名無しさん :2012/11/14(水) 23:17:24.64 .net まぁ、こういう個人攻撃はネットウォッチ板でやるもんだな
447 :デフォルトの名無しさん :2012/11/15(木) 10:53:44.15 .net >>442 そんなことでリークするわけない。動的に生成された要素は、XAMLでイベントハンドラが登録されたままでも ツリーから外れた時点でGC対象になる。XAMLではなくコードビハインドなどから追加した場合は当然 WPF管理外のため、イベントハンドラによる強参照が当然残るのでそれがマズい場合があるだけ。 つまりWPF自身の問題などでは決してなく、あくまで愚かな人間によるミス。 例の宗教はあえてそのあたりをぼかす(信者の多くはそもそも理解してないまま復唱してるだけだろうが) ことによって恣意的なイメージ操作を行っている。
448 :デフォルトの名無しさん :2012/11/15(木) 10:57:08.02 .net そもそもWindow自体を解放する手段ないだろ
449 :447 :2012/11/15(木) 11:01:14.57 .net ItemsTemplate/DataTemplateの中のコントロールのイベントに対して コードビハインドのイベントハンドラを登録したときの話な 試してみたら分かるが、要素を削除した後にGCが走れば ちゃんとコントロールのファイナライザが呼び出される。
450 :デフォルトの名無しさん :2012/11/15(木) 11:25:23.41 .net メッセージに応答してダイアログを開いたりする汎用的なビヘイビアって本当に必要? VMからダイアログ開きたいんだったら、IoCでVMからIOpenFileDialogServiceのような インターフェイスを通してメソッドを呼び出せばいいだけの話だと思うんだけど。 わざわざメッセージ投げてVで処理するなんて複雑だしXAMLも無駄に汚れるしタイプセーフじゃないし。 特定のビューでしか使わないようなサービスにするまでもない処理ならメッセージもアリだと思うけど その場合ビヘイビアにする意味はなく(再利用しないんだから)、コードビハインドで受けて処理すればいい話だよな。
451 :デフォルトの名無しさん :2012/11/15(木) 17:05:54.35 .net テスト
452 :デフォルトの名無しさん :2012/11/15(木) 20:05:32.67 .net 行き過ぎたBlend主義。 俺もサービスにするかな。
453 :デフォルトの名無しさん :2012/11/15(木) 22:36:46.09 .net VMからのメッセージでアニメーションを開始させたいときなんかにはビヘイビアが便利かも と思ったけどそんなビューの細かいことをVMで意識するのも本末転倒な気がするな そこはメッセージとXAMLは直接繋がないと割り切った方がいいのかも
454 :デフォルトの名無しさん :2012/11/15(木) 22:46:23.39 .net 俺はビヘイビアで済ませたほうが楽かな
455 :デフォルトの名無しさん :2012/11/15(木) 22:52:24.24 .net Livet教のMVVM…ドカタMVVM IoC使うPrism系のMVVM…JavaっぽいMVVM
456 :デフォルトの名無しさん :2012/11/15(木) 23:15:07.41 .net MVVM Light…光のMVVM
457 :デフォルトの名無しさん :2012/11/17(土) 00:05:50.69 .net よく話にでるlivetってライブラリ落としてみたけどクラス名にまでlivetって入ってんのね。 ダサすぎる。
458 :デフォルトの名無しさん :2012/11/17(土) 00:08:09.15 .net てゆーか、9割以上がPrismとMVVM light toolkitのパクリコードってのはどうなの? Ugayaはずいぶんえらそーなことを言ってたがただのパクリライブラリじゃんか。
459 :デフォルトの名無しさん :2012/11/17(土) 06:32:58.08 .net そうだなC#はJavaのパクリだもんな つーかソース見たことはないが本当にパクリなら大問題だしそれならここで言ってないで大々的に批判すればいいんじゃないか
460 :デフォルトの名無しさん :2012/11/17(土) 09:52:41.30 .net >>459 見ればわかるがおおざっぱに言えばLivetの独自部分でメソッドキャッシュとT4コンバーターぐらいじゃね? C#っつーか.NET Frameworkだろ 1.0のころはパクリだったんじゃないの? 実際Javaがなければ今と同じ1.0は生まれてなかった
461 :デフォルトの名無しさん :2012/11/17(土) 10:11:39.47 .net なんだコード盗用とかじゃなくて概念の話だったのか
462 :デフォルトの名無しさん :2012/11/17(土) 11:07:14.48 .net >>461 >>458 はコードと言ってるな
463 :デフォルトの名無しさん :2012/11/17(土) 12:09:36.74 .net >>461 綺麗に言えば、車輪の再発明? ぱくりライブラリと言われても仕方がない代物ではある 何を目的にやってるのか分からないところもあるし インフラを乱立させたって混乱するだけだし ドキュメントやサンプル充実させて裾野を広げるってわけでもないし 尾上が自身の狂った思想から少しでもずれてる意見を発見すると 死ぬまで粘着されるしな 尾上は自分が日本での唯一のMVVM啓蒙者になるために 他人がおいそれと語れないようにしてるだけ 完全に癌でしかない
464 :デフォルトの名無しさん :2012/11/17(土) 12:14:26.42 .net MVVMの土台として画面遷移は極めて重要だと思うが、そこがいい加減なのはいただけない 同期ダイアログによる遷移のみってWinFormsかよw WinRTじゃそんなもん使えないぞ?
465 :デフォルトの名無しさん :2012/11/17(土) 12:30:02.96 .net >>464 MVVMはMSが本気で取り組まない限り無理。 言語、.NET Framework、IDEが三位一体で対応しないと今はまだ欠陥が多すぎる。
466 :デフォルトの名無しさん :2012/11/17(土) 12:38:05.90 .net >>465 WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、 IDEでどうするもんでもないだろう Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
467 :デフォルトの名無しさん :2012/11/17(土) 13:33:39.79 .net U氏に親殺されたやつ多すぎだろ
468 :デフォルトの名無しさん :2012/11/17(土) 14:04:28.46 .net >>467 叩かれてる奴に「氏」付けるのは本人だけ ってだいぶ前に小学生の妹が言ってたよ。
469 :デフォルトの名無しさん :2012/11/17(土) 14:08:17.71 .net 画面遷移についてはMVVMと絡めてもっと真剣に議論されるべきだと思うぞ? U氏関係なく。自称MVVMインフラではたいてい完全スルーされてるが(Livetでもおまけ程度) どうしてもインフラ的なコードを書くことになる部分だし、MVVM使ってるなら画面遷移の設計も それに強く影響されることになる。
470 :デフォルトの名無しさん :2012/11/17(土) 14:08:19.65 .net >>466 > WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、 WPFの話じゃなくてMVVMな > IDEでどうするもんでもないだろう IDEにどれだけ恩恵受けてるかわかってないの? MVVMだってフレームワークだけではどうにもならないことがある > Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。 Prismがもっと使いやすく標準で.NET Fxに乗らないと無理ってこと
471 :デフォルトの名無しさん :2012/11/17(土) 14:44:14.95 .net コードビハインド前提のMVVMフレームワークが出てきたら少しは前進すると思う。 Livetがダメなのは作者がコードビハインド完全否定してることと >>458 が言う通り、既存フレームワークの単なる2番煎じで MVVMの問題点を克服するものではないから。 コードビハインドいいと思うんだけどな。 うがやのサイト見ていると分業とか書いてるが Vをデザイナーに別注してるチームってあるのか。 デザイナーとデベロッパーの分業なんて幻想じゃないのかな。 XAMLをフルに理解してるデザイナーなんて一人もいないと思うよ。
472 :デフォルトの名無しさん :2012/11/17(土) 14:57:27.23 .net >>471 その点に関してはすでに奴は考え改めてコードビハインドの有無はどうでもよくなってるみたいだぞ
473 :デフォルトの名無しさん :2012/11/17(土) 15:03:53.77 .net VMの処理中にユーザの入力を求めたくなった場合とかかね画面遷移は ぶっちゃけどのライブラリも何かあるたびにクラスやらインターフェイスやら増やさないとならなかったりして面倒だわ MSはMVVMを推奨するんならASP.NET MVCくらい充実させるべき
474 :デフォルトの名無しさん :2012/11/17(土) 16:41:52.99 .net >>473 そういう遷移はビューだけで完結するのでほとんどMVVM関係ない。 ビューの実装の詳細だ。 設計に大きく影響するのはVMごと遷移するやつな。
475 :デフォルトの名無しさん :2012/11/17(土) 17:27:45.79 .net 具体的な例で言ってくれよ
476 :デフォルトの名無しさん :2012/11/17(土) 17:34:46.35 .net 例も何も、無理にVMくつけなきゃ 一覧画面 <-> 編集画面 とか大概の画面遷移はVMごと遷移だろ ダイアログベースならそんなに意識しないだろうけどさ
477 :デフォルトの名無しさん :2012/11/17(土) 17:43:10.77 .net それならDataContextにVM突っ込んでもらうだけでよくね
478 :デフォルトの名無しさん :2012/11/17(土) 17:54:24.04 .net そのコードをどこに書くのかとかいろいろ問題があるよ 本来、一覧画面VMで 画面遷移しろ("編集ビュー", selectedItemId); だけで済むはずで 一覧画面のVMやVが遷移先の画面のVやVMのクラスを知っている必要は全くないけど そう書けるようにするためには結局インフラがいるんだよね
479 :デフォルトの名無しさん :2012/11/17(土) 18:03:52.82 .net railsのscaffoldみたいにサクッとアプリを作れるようなインフラが欲しい・・・
480 :デフォルトの名無しさん :2012/11/17(土) 19:28:02.12 .net >>472 どうでもいいわけないよね? 氏のMVVMサイト見てくれば。
481 :デフォルトの名無しさん :2012/11/17(土) 20:46:12.52 .net プロ粘着なら奴のツイッターも観察すべき
482 :デフォルトの名無しさん :2012/11/17(土) 23:51:38.42 .net >>481 前はフォローしてたんだけどね。 自分とちょっとでも意見が違うと噛みついて粘着のパターンが多すぎて ずいぶん前にフォロー解除したよ。 あの人ちょっとアスペ入ってるよね。 ちょっとというかかなり。 高卒で会社員経験なし、ってとこで人間の底が知れるわ。
483 :デフォルトの名無しさん :2012/11/18(日) 00:01:26.49 .net と2ちゃんねるで批判するガキwww
484 :デフォルトの名無しさん :2012/11/18(日) 00:03:44.32 .net >>483 ugayaの負けず嫌いもここまで来ると褒めたくなるなw せっかく社会人になれたんだから2chで自演擁護とかやめたら?wwwww
485 :デフォルトの名無しさん :2012/11/18(日) 00:09:01.67 .net >>484 まともな社会人は多少の煽りには反応しねーんだよ お前みたいな無職のクズとは違うんだよ 分かったらとっとと寝ろ
486 :デフォルトの名無しさん :2012/11/18(日) 00:11:32.55 .net ugayaは2chの煽りにtwitterやブログでキレまくってたけどなw
487 :デフォルトの名無しさん :2012/11/18(日) 00:17:22.53 .net >>486 いいから早く寝ろよ
488 :デフォルトの名無しさん :2012/11/18(日) 00:20:54.13 .net 反応はしてたけど別にキレまくってたってほどじゃなかったろ
489 :デフォルトの名無しさん :2012/11/18(日) 00:24:44.54 .net MVPVMの(Uによる)煽りはひどかった
490 :デフォルトの名無しさん :2012/11/18(日) 01:06:10.42 .net お前ら本当に暇なんだな 文句があるなら一度でいいからGoogleの検索トップになってみろよ U氏のサイトはMVVMで検索すると余裕でトップなんだが
491 :デフォルトの名無しさん :2012/11/18(日) 01:10:17.68 .net そんなんだと宗教に騙されるぞ U氏も言ってるだろ? 「MVVMだからこうしなければならない」じゃなくて目的を考えろと
492 :デフォルトの名無しさん :2012/11/18(日) 01:14:55.07 .net >>491 自分の考えた最強の目的しか許さず その目的を達成するにはこうするしかないと決めつける そこから外れたツイートを見つけると相手が黙るまで粘着ツイート 相手が黙ると「都合が悪くなると無視かよ、これだからクズは困る」的なツイートで〆 尾上さんのそこにシビれる!あこがれるゥ!
493 :デフォルトの名無しさん :2012/11/18(日) 01:15:09.27 .net 目的を考えろと言ってる本人が一番権威主義を煽ってる元凶という皮肉
494 :デフォルトの名無しさん :2012/11/18(日) 01:19:48.67 .net 尾上を擁護してるのはいったい誰なの? 誰がどう見てもアスペルガーじゃん。 尾上にへこへこ媚び売って家畜に成り下がってる奴って 高野将かぐらばくぐらいなもんだろ?
495 :デフォルトの名無しさん :2012/11/18(日) 01:40:50.56 .net 相手を擁護と認定してしまえばどんな誇大を使って過激に叩いても正当化できて安心だもんな
496 :デフォルトの名無しさん :2012/11/18(日) 01:49:36.48 .net 文句があるなら同じMVVMの土俵で反論すればいいじゃないか。 このスレに持論を垂れ流すだけでも人格攻撃よりはマシだしまともな議論なら歓迎だぞ。 考え方に関してはここはわりとU氏に反発してる人が多いみたいだし(俺もその一人だが)。
497 :デフォルトの名無しさん :2012/11/18(日) 07:01:25.21 .net MVVMの思想に関してはいい加減多少は理解したから、 そろそろMVVMの実装について語って欲しいなぁ、
498 :デフォルトの名無しさん :2012/11/18(日) 07:25:20.92 .net とりあえずインフラ使っとけっていう風潮?って MVVMじゃなくてMVVMライブラリの使い方を憶える事になる 危険性高い気がするのよね。 MVVMインフラが解決しているであろう、 様々な問題を自力で解決できるように成らないと ほんとうの意味でMVVMやXAML環境を理解したとは言わない気がする。 MVVMの啓蒙者ならそのぐらいまでやってくれないと片手落ちだろって思う。 ところでMVVMインフラってどんな問題を解決してるの?
499 :デフォルトの名無しさん :2012/11/18(日) 13:25:29.40 .net コードビハインドのこともそうだしModelの責務の話もそうだけど 言ってることがコロッと変わるのはどうにかならないものなのか なんか昨日もフォーカス制御をModelでとか唐突に言い始めるわけですよ それが正しいかどうかは別として ざんざん大声で他人を罵倒してまで言い続けてたことを ちょこちょこ小出しでさりげなく路線変更してくる卑怯なところが俺が気に入らないところ といういか、それがうがやが叩かれる原因じゃね?
500 :デフォルトの名無しさん :2012/11/18(日) 15:58:45.35 .net >>499 やっぱ大学もいってないし、会社員としての経験もほぼ0でしょ? どう考えても性格、人格が歪んでるというか問題があるんでしょう。 完全にアスペだよ、アスペ。
501 :デフォルトの名無しさん :2012/11/18(日) 16:01:06.83 .net お前アスぺの意味やその性質わからずに罵倒語として使ってるだけだろ
502 :デフォルトの名無しさん :2012/11/18(日) 16:06:22.21 .net 人格の話は別の板でやれ。
503 :デフォルトの名無しさん :2012/11/18(日) 16:17:28.34 .net 私怨ならヲチでやれ
504 :デフォルトの名無しさん :2012/11/18(日) 18:51:48.91 .net ここって元々WPFスレを正常化するための隔離スレッドだからいいんだよ。 便所の落書きスレッドで。 いやなら見るなw by 岡村
505 :デフォルトの名無しさん :2012/11/18(日) 18:59:24.39 .net まあアスペには違いない
506 :デフォルトの名無しさん :2012/11/18(日) 20:26:20.24 .net 尾上さんは 「日本でMVVMを正しく語れる人間は自分以外にいないッ!!」 って断言してたしスレ名を「尾上について語ろう」に修正してもよいと考えられる
507 :デフォルトの名無しさん :2012/11/18(日) 20:52:02.11 .net ここMVVMやってる奴はキチガイだらけという見本のスレか
508 :デフォルトの名無しさん :2012/11/18(日) 20:58:34.33 .net そもそもMVVMって何だよ ぐぐってもクソみてーなサンプルコード乗せただけの記事しか出てこないしまともに概念を解説してるやついねーのな コマンド(笑)とか冗長すぎてもうね
509 :デフォルトの名無しさん :2012/11/18(日) 21:04:18.24 .net わからないならこれでも勉強しろ JavaScript製のMVVMフレームワーク「Knockout」 http://www.moongift.jp/2010/11/2010110212/
510 :デフォルトの名無しさん :2012/11/18(日) 22:37:36.36 .net >>508 尾上さんのサイト見れば簡単に理解できる。 簡単に言うとPDS的にコードビハインドを記述しないで開発する手法だよ。
511 :デフォルトの名無しさん :2012/11/18(日) 22:40:25.76 .net 一応言っておくとPDSは一般的な用語じゃないから通じないと思うぞ。
512 :デフォルトの名無しさん :2012/11/18(日) 22:41:17.17 .net 一般的にはフリーソフトで通じる
513 :デフォルトの名無しさん :2012/11/18(日) 23:36:11.21 .net >>511 自分が知らないことは一般的じゃないと考える根拠は何だろうね 自分の無知を晒しているだけと気が付かない人には何を言っても無駄ではあるが、助言だけはしておくかな
514 :デフォルトの名無しさん :2012/11/18(日) 23:39:05.83 .net Wikiにないから一般的じゃないと推定される
515 :デフォルトの名無しさん :2012/11/18(日) 23:40:30.50 .net どこのWikiだよ
516 :デフォルトの名無しさん :2012/11/18(日) 23:42:35.17 .net 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 .net 海外 http://en.wikipedia.org/wiki/PDS
518 :デフォルトの名無しさん :2012/11/18(日) 23:48:19.69 .net >>510 PDSという概念があるよということなら納得できる ただしPDSという言葉が一般的というのは賛同しかねる
519 :デフォルトの名無しさん :2012/11/18(日) 23:51:14.50 .net で、そのPDSとMVVMに何の関係が?
520 :518 :2012/11/18(日) 23:57:05.51 .net MVVMは、XAML系フレームワークにおけるP(resentation層)の問題を解決するもの その前提としてPとD(omain層)の分離がある
521 :518 :2012/11/18(日) 23:59:12.80 .net とはいえこれはあくまでパターンであり、絶対の解法ではない その証拠として、MicrosoftもXAML系コンポーネントベンダーもMVVMを推奨してないという事実がある
522 :518 :2012/11/19(月) 00:02:35.76 .net WPF・Silverlight・RTの公式ドキュメントで、一ヶ所でもMVVM必須と謳っている箇所があるだろうか? また国内だとGrapeCity・Infragistics等のベンダーがXAML系コンポーネントを販売している これらベンダーのマニュアルにも、MVVMを必須・提唱しているドキュメントは全く見当たらない
523 :デフォルトの名無しさん :2012/11/19(月) 00:07:49.16 .net MがちゃんとしててVMはぺらっぺらになるのがMVVMの設計としては理想だからな Web MVCではいくらぺらっぺらでもC無しというわけにはいかないが VMがぺらっぺらになっていき、ついに無くなるのは別に問題ない 微妙に矛盾したパターンだよ
524 :デフォルトの名無しさん :2012/11/19(月) 00:07:57.56 .net そりゃ必須なわけがない MSDNマガジンやChannel9とかで適度に触れられている程度だな あと「推奨していない」だと非推奨と主張しているように聞こえるから注意だ 「触れていない」あたりでいい
525 :518 :2012/11/19(月) 00:08:10.96 .net 勘違いしてはいけないのは、パターンはあくまでパターンであり、絶対の解法ではないことだ 逆にパターンに振り回されてその本質を見失えば、返って障害が発生する場合もある MVVMを使わずに開発できるのならそれでよし
526 :デフォルトの名無しさん :2012/11/19(月) 00:09:31.95 .net VMとテスト
527 :デフォルトの名無しさん :2012/11/19(月) 00:11:53.87 .net >>526 MがちゃんとしててMのテストだけで済むならそれに越したことはない
528 :デフォルトの名無しさん :2012/11/19(月) 00:12:18.51 .net >>524 どうかな? 「MVVMが必須」という誤ったイメージが蔓延し過ぎて参入障壁が上がり過ぎると Microsoftや周辺ベンダーしては返って喜ばしくない事態になると思う ・・・いやすでになっているな 「触れていない」というより、いまとなっては「触れたくない」が正解だと思う
529 :518 :2012/11/19(月) 00:15:52.43 .net かくいう私はどうかといえばMVVMは割と好きなパターンであるし、 実際これでかなり問題を解決できているのも事実だ しかし、使えない、理解できない、開発速度が極端に落ちて苦痛に感じるくらいなら、 そこまで無理に使う必要もないと思う
530 :デフォルトの名無しさん :2012/11/19(月) 00:28:44.37 .net VMがわかりにくいのって、CとかPとかと違ってVMにはこれといって Mとの間に役割の違いが無いことだよ 特定のVとバインドすることを意識して作ったMってだけだからな
531 :デフォルトの名無しさん :2012/11/19(月) 00:53:44.94 .net なにいってんだ? ビューの状態を表すモデルデータという 役割があるだろ。
532 :デフォルトの名無しさん :2012/11/19(月) 00:58:48.11 .net 別に選択状態持つためのMを設けてもいいんだぜ?
533 :デフォルトの名無しさん :2012/11/19(月) 01:02:55.31 .net それはもはやMではない。 Mの役割としては、GUIアプリではなく CUIアプリからでも普通に使えるようなものを 目指すべきだ。 そんなGUIに依存した機能を持たせるべきじゃない。
534 :デフォルトの名無しさん :2012/11/19(月) 01:04:56.93 .net その選択状態がGUIとしてあらわす際に必要となる選択状態なのか、 そのプログラムの動作自体を構成するにおいて存在する必然性のある選択状態なのかによるね
535 :デフォルトの名無しさん :2012/11/19(月) 01:19:56.04 .net 画面ごとのVMはいいけど、モデルごとのVMはめんどい
536 :デフォルトの名無しさん :2012/11/19(月) 10:20:32.56 .net >>532 GUIの選択状態を維持するためのモデルをViewModelという
537 :デフォルトの名無しさん :2012/11/19(月) 22:03:23.29 .net グリッドのボタン付けるときとかの 行ごとにVM作る派と作らない派の比率が知りたい
538 :デフォルトの名無しさん :2012/11/19(月) 22:15:46.48 .net 行って何の話だよ
539 :デフォルトの名無しさん :2012/11/19(月) 22:20:34.86 .net WPFでデータグリッド使ったら負けだろ それならWinForms使うわ WPFならテンプレートで作れ
540 :デフォルトの名無しさん :2012/11/19(月) 22:29:30.62 .net 普通コンボボックスの項目毎VM作るだろ
541 :デフォルトの名無しさん :2012/11/19(月) 23:23:02.89 .net グリッドって何かと思ったらDataGridのほうか
542 :デフォルトの名無しさん :2012/11/20(火) 13:30:22.35 .net >>540 ??? コンボボックスにモデルのコレクションをバインドするだけでええやん
543 :デフォルトの名無しさん :2012/11/20(火) 13:54:25.91 .net HeaderedItemsControlとかをこねくり回すのは常套手段なのか
544 :デフォルトの名無しさん :2012/11/28(水) 11:11:37.09 .net 考え増やしたいから、 MVVM の各レイヤーの具体的な責務を教えてください 以下、テンプレ M: V: VM:
545 :デフォルトの名無しさん :2012/11/28(水) 11:22:45.65 .net >>544 > M: ビューに関係無いデータ構造など変更部分。いわゆるモデル。UIスレッドと分離されてる事が望ましい。 > V: ビューの見た目。極力もらったデータを表示したりインプットを上にあげるだけで何もしない。 > VM: その両者を繋ぐもの。そのビューに関係するコーディネーター。ユニットテストできること。スレッド間の調整をここで吸収。
546 :デフォルトの名無しさん :2012/11/28(水) 11:22:46.45 .net Set-Location : ドライブが見つかりません。名前 'M' のドライブが存在しません。
547 :デフォルトの名無しさん :2012/11/28(水) 11:34:44.90 .net 一番ありそうな間違いは、WebMVCの典型的な間違った使い方のように M: データ VM: ロジック としてしまうことだな 注文画面のMは注文処理クラス。VMはあくまでインターフェイスの差を吸収するだけ。
548 :544 :2012/11/28(水) 11:45:53.66 .net >>547 まさにこれw
549 :デフォルトの名無しさん :2012/11/28(水) 12:47:28.47 .net 使う側ならそれでいい
550 :デフォルトの名無しさん :2012/11/28(水) 14:02:32.93 .net Mのビジネスロジックがバックエンドに移って 結果的にMがデータだけになることはあるだろうけど VMから見たら特に関係ない話。VMにビジネスロジックを書いてるわけじゃない。
551 :デフォルトの名無しさん :2012/11/28(水) 21:50:02.31 .net プレゼンテーションに関わるものとしてVMに置いとくべきデータやロジックがあるって意見も耳にするけど 自分には区別が難しいので極力Mに持たせるわ。
552 :544 :2012/11/28(水) 22:50:19.03 .net 永続化しないデータとか?
553 :デフォルトの名無しさん :2012/11/28(水) 23:14:06.28 .net MVVM界隈の話はVMが強調されすぎるきらいがあるよな。 本当はMの方が遥かに重要なのに。どちかか省くなら迷わずM。 VMはMVVMパターンのアイデンティティだから仕方がないけど。
554 :553 :2012/11/28(水) 23:14:52.00 .net 間違えた省くならVM
555 :デフォルトの名無しさん :2012/11/29(木) 00:02:45.23 .net プレゼンテーションにかかわるものはVに書くんじゃないのか
556 :デフォルトの名無しさん :2012/11/30(金) 06:22:26.73 .net VMは、抽象的な、表示する「ための」データだな 例えば、VでItemsSourceにバインドして表示する一連のデータのコレクションとか 特定のデータを、手段は特定しないからとにかく強調表示しろ、ということを示すプロパティとか Vは、具体的な、表示「の仕方」だな 同じVMからでも、同じコレクションを表示させる方法はListBoxだったりDataGridだったり単なるテキストだったり どんな形で表示するのかはVが決めることでVMは手を出せない また、強調表示の仕方にしても、単なる色変化だったり太字だったり、その部分だけ無意味にアニメーションさせたり 表示の仕方もVに任せられててVMは手を出せない
557 :デフォルトの名無しさん :2012/12/11(火) 16:23:56.96 .net VBでペタポトプログラミングしか経験ない奴にパターン教えても一向に概念理解してくれない ましてMVVMなんか到底無理無理
558 :デフォルトの名無しさん :2012/12/11(火) 18:18:42.11 .net そんな動けばいいという考えの奴に何をいってもダメだ。 平気でModel部分にフォームやコントロール(UI)のインスタンスを食わそうとしたりするからな。
559 :デフォルトの名無しさん :2013/01/16(水) 20:12:33.47 .net MVVMって従来のASP.NETやWindowsフォームに慣れた人に説明するなら、 V Aspxファイル/フォーム VM コードビハインドのcs M 業務ロジック と対応してて、従来のASP.NETやWindowsフォームとの大きな違いは、 ViewとViewModelがバインディングを介すると言う制約があるので分離しやすい、 と言う理解なんだけど大体合ってるかな?
560 :デフォルトの名無しさん :2013/01/16(水) 22:46:55.45 .net 全然
561 :デフォルトの名無しさん :2013/01/17(木) 23:06:47.49 .net 大体合ってるみたいですね。 VB6脳なPGとJava/Struts脳なPG、どっちがMVVM覚えるのに向いてますかね?
562 :デフォルトの名無しさん :2013/01/18(金) 08:37:02.03 .net >>561 全然違うと言われてんだろ 概念がそもそも違うがそれが分からない人間でも ・コードビハインドは画面と同一クラスだがVMは別クラス ・コードビハインドとViewは一対一だが、View:VMは1:n ・VSでコントロールをダブルクリックしてもコマンドが作られて自動的にバインドされたりしない ・そもそもコードビハインドはコードビハインドで存在するだろ と、上げ出したらきりが無い MVVM使うならちゃんとMVVMの概論くらいは理解させないとあとで自分が地獄行きだぞ
563 :デフォルトの名無しさん :2013/01/18(金) 09:03:18.93 .net 的外れな回答()キター
564 :デフォルトの名無しさん :2013/01/18(金) 14:28:02.15 .net いまだにVB6脳なんて他のこと何も向いてないだろ
565 :デフォルトの名無しさん :2013/01/18(金) 14:46:29.63 .net 違うって言われてるのに合ってると受け取っちゃうのはどこにも向いてないな。
566 :デフォルトの名無しさん :2013/01/18(金) 17:07:06.64 .net 全然合ってるかもしれない
567 :デフォルトの名無しさん :2013/01/20(日) 07:38:18.01 .net 559は大体あってるよね? というより562が間違いすぎw ・コードビハインド(各種イベントで呼び出される関数)は 手動で設定すれば Viewとは別のクラスにすることは可能だし ・V:VM は 一つのデータを別表現で表示することがあるので V:VM = n:1 ・デザイナでダブルクリックしても自動で出来ない →細かい処理を行いたければデザイナに任せずに手動で操作するのは当たり前。 ・そもそもコードビハインドはコードビハインドで存在するだろ →別にイベントで関数呼び出しても、 CommandやActionのバインディングで関数呼び出してもよくね?
568 :デフォルトの名無しさん :2013/01/20(日) 07:50:01.85 .net そういえば、データバインディングって ほんの少し MFCのValue変数とDDX_〜 に似てないか?
569 :デフォルトの名無しさん :2013/01/20(日) 09:40:48.58 .net >>568 ほんの少しな( ´Д`)y━・~~
570 :デフォルトの名無しさん :2013/01/22(火) 07:57:45.76 .net @Grabacr07 いままでのオレオレICommandの正しい実装基底クラス Prismのパクリなのになんでこんなに偉そうなの?
571 :デフォルトの名無しさん :2013/01/22(火) 19:39:17.12 .net 心底どうでもいい
572 :デフォルトの名無しさん :2013/01/22(火) 21:17:29.87 .net MVVMライブラリはすべてPrismのパクリだからな いまさらだろ
573 :デフォルトの名無しさん :2013/01/25(金) 10:23:59.51 .net 別に偉そうじゃない件について どれだけコンプレックス感じてんだよw ダッセーやつw ぷげら
574 :デフォルトの名無しさん :2013/01/25(金) 23:38:53.69 .net 実際やってみたらMVVMではなくWPFやSilverlight固有の部分でかなり躓いた 初見でXAMLを自由自在に扱える奴とかいるのか?
575 :デフォルトの名無しさん :2013/01/25(金) 23:46:59.77 .net 固有の約束事を理解しないといけないのはWinFormsだってASP.NETだって PHPとかのWebフレームワークだって一緒だ
576 :デフォルトの名無しさん :2013/01/26(土) 00:00:26.99 .net パネル使ったレイアウトに慣れてないだけじゃね?
577 :デフォルトの名無しさん :2013/01/26(土) 00:07:18.85 .net >>574 ちなみに躓いたのどこら編?
578 :デフォルトの名無しさん :2013/01/26(土) 00:11:58.51 .net ControlTemplateとか初見でMSDNだけで使いこなせたら神だわ
579 :デフォルトの名無しさん :2013/01/28(月) 10:43:39.37 .net Templateカスタマイズする時点で折れるな
580 :デフォルトの名無しさん :2013/01/29(火) 02:16:53.83 .net >>573 別にウガヤが考えたロジックじゃあないのに まるで自分で考案したような口ぶりが臭いだけじゃろ。 特にcommandのweakeventなんてprismのアイデアそのまんまだし。 ++c++やneueと違って.NETやC#(言語)の知識は薄っぺらいのに ビックマウスだから余計に臭い。
581 :デフォルトの名無しさん :2013/01/29(火) 05:30:37.24 .net >>580 詳しくは知らんが咀嚼して自分のライブラリとしてまとめ上げて、それを採用してくれてるとこもあるんだから、口だけ番長のお前より遥かにまし。 リアルでフルボッコにされたの?悔しいのぅ悔しいのぅ。
582 :デフォルトの名無しさん :2013/01/29(火) 07:57:35.12 .net 奴が自分で考案したみたいなことを言っているのは見たことないが どの辺で言ってたのか気になるな
583 :デフォルトの名無しさん :2013/01/29(火) 08:22:09.37 .net 別に好きでも嫌いでもないが、世の中のMVVMフレームワークは全てLivetより下と言ってるように取れる文書ならみた MVVMが普及しないのは既存のインフラが不十分なせいで、Livetがそれを解決するんだとか 確かアンチMVVMに反論する記事だったかと思う
584 :デフォルトの名無しさん :2013/01/29(火) 08:34:30.68 .net 現場でMVVMゴリ押しして使ったら大失敗したからアホにも使えるように作ったんだっけ? 部下も可哀想だな
585 :デフォルトの名無しさん :2013/01/29(火) 08:50:43.67 .net まあ既存のが不十分なのはあってるな ただLivetが必要十分かと言うとそうでもない
586 :デフォルトの名無しさん :2013/01/29(火) 09:18:58.54 .net Javascriptエンジン組み込んでknockout.jsを逆移植するのがいいと思う ビューに振る舞いを書けた方がいいのは、それを最初否定してたMVVM自身によって証明されたし VMも静的言語で書くのは面倒な単純作業すぎる
587 :デフォルトの名無しさん :2013/01/29(火) 09:31:08.32 .net ReactiveExtensions絡めて作ってるがすこぶる楽だし見通し良くなってイイよ。 まぁ向き不向き有るかもしれんが。まだ試しで作ってるだけなので後でいろいろはまるのかもしれんけど。 内部の状態遷移など含めて綺麗に落とし込みたいんだけどまだそこまで出来とらん。
588 :デフォルトの名無しさん :2013/01/29(火) 10:26:40.09 .net MVVMとリアクティブプログラミングの相性は非常にいいね。 ただ、ReactiveExtensionsは記述が冗長になるので 人にはお勧めできないな。 async,awaitみたいにコンパイラ支援があればいいんだけど。
589 :デフォルトの名無しさん :2013/01/29(火) 10:36:58.35 .net >>588 非同期として扱うだけなら冗長になるかもしれんがその以上やるならあんなもんじゃない?どの変が気になる? F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
590 :デフォルトの名無しさん :2013/01/29(火) 12:29:20.69 .net MVVMって何ですか?
591 :デフォルトの名無しさん :2013/01/29(火) 12:40:25.22 .net wwwwみたいなAAの一種
592 :デフォルトの名無しさん :2013/01/29(火) 12:51:58.26 .net >>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 .net >>592 > int A { get { return B ? C : D.E; } } > って単純な関係性を記述するだけでも、それなりの量になる。 自分もまだそこまで突っ込んで触ってないのでなんだが、自分で用途に合わせた複数要素を取れるZipみたいな物とか作らないと記述が冗長になりそうな気はしてる。 Zip重ねてとかでもいいけど見た目的にも身微妙な気がしなくもない。 > 計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。 その辺でSelectManyとかSwitchで上手く合成出来ると綺麗に書けるんかね( ´Д`)y━・~~
594 :デフォルトの名無しさん :2013/01/29(火) 15:41:47.19 .net 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 .net >>594 自分が言ってるのはQueryExpressionsの方。 使ってる例としてはこんな感じ。 http://mnajder.blogspot.jp/2011/09/when-reactive-framework-meets-f-30.html これはクエリ式への直接変換的な感じだけど、望みのクエリ式を追加できるので独自のDSL的に定義できる。
596 :デフォルトの名無しさん :2013/01/30(水) 18:31:22.62 .net 従来型のほうがいいだろ 誰かさんにプレゼント 優れた言語より流行ってる言語 優れたフレームワークより使われてるフレームワーク
597 :デフォルトの名無しさん :2013/01/30(水) 18:52:28.14 .net アプリケーションで、各種バー表示のon/offや配置等の、GUIに関する設定がよくあると思いますが そういう設定の保存・読み込みロジックはVMでいいんですよね? MVVMの概念がまだあやふやで確信が持てません。
598 :デフォルトの名無しさん :2013/01/30(水) 18:55:35.45 .net 一番使われてるフレームワークが一番、ってのなら、 一番のラーメンはインスタントラーメンだぜ?
599 :デフォルトの名無しさん :2013/01/30(水) 19:04:13.88 .net Haskell大流行だもんな
600 :デフォルトの名無しさん :2013/01/30(水) 19:13:05.88 .net >>598 フレームワークとラーメンとが置換可能であることを証明できれば完璧だな。 イグノーベル賞がんばれよ。
601 :デフォルトの名無しさん :2013/01/30(水) 20:13:22.03 .net COBOL最高だろうが
602 :デフォルトの名無しさん :2013/01/30(水) 20:49:05.37 .net >>597 Vでしょ というかそういう作り込みが必要な画面にMVVMを適用するのは不適切だと思うよ。 大してメリットがなく面倒なだけ。使うならダイアログとかで使う。
603 :デフォルトの名無しさん :2013/01/30(水) 20:55:18.66 .net メニューとか(共有の)ツールバーとかウィンドウ制御のようなシェル的な部分に MVVMを適用しようと考えてはいけない そういうのはインフラとしてMVVMの枠外で実装して、その中で扱うドキュメントには 必要に応じてMVVM適用するのがスマート
604 :デフォルトの名無しさん :2013/01/30(水) 22:12:56.62 .net あくまでVの都合だしな MVVMは本体処理とUIの組み合わせ方のパターンでしかないので、ウィンドウのサイズ保存とかはロジックとは無関係
605 :デフォルトの名無しさん :2013/01/30(水) 22:13:53.89 .net >>602 え?Modelじゃないの? 煽りじゃなくて、真面目な質問です
606 :デフォルトの名無しさん :2013/01/30(水) 22:14:56.02 .net あぁ、確かにビジネスロジックではないのか
607 :デフォルトの名無しさん :2013/01/30(水) 22:45:08.78 .net あえてシェルにMVVMを適用するんならMだろうな どちらにしろGUIに閉じた話であって、ビジネスロジックの世界とは分けて考えるべき
608 :デフォルトの名無しさん :2013/01/30(水) 22:47:03.45 .net >>597 VMで正しいよ。 ビューモデルというのは、ドメインモデルとビューとのギャップを埋めるラッパーの役割をするもので、 まさに>>597 のようなビュー固有のデータを扱うのに適している。 Vに置くのは(少なくともこのスレにおいては)間違いだから>>602 は気にしなくていい。
609 :デフォルトの名無しさん :2013/01/30(水) 22:56:21.08 .net >>608 それこそビジネスロジックとUIがごっちゃになってね? もともとビジネスロジックから見たらVの実装の詳細にすぎないことで、 それが少々複雑になるからMVVM適用しようってんなら GUIの設定情報を持つためのMを使うのが適切だと思うよ
610 :デフォルトの名無しさん :2013/01/30(水) 23:00:06.22 .net アプリケーションモデルというやつですか。
611 :デフォルトの名無しさん :2013/01/30(水) 23:07:07.58 .net そもそもそんなロジックに直接関係なくてGUIに閉じた混みいった制御と 金,人間,住所,データベース,入力フォーム云々を一緒にして扱うのがおかしい そこ明確に分けるのが一番大事だろ
612 :デフォルトの名無しさん :2013/01/30(水) 23:19:21.22 .net そんなめんどくさいことせんでも、VBで画面にぽちぽちボタンとか張って、 ダブルクリックしてイベント追加したら、その中に全部処理書けばええやろww
613 :デフォルトの名無しさん :2013/01/30(水) 23:22:23.10 .net PrismだとShellに対してVとVMがあって、ShellのVMのプロパティに 入力画面とかのVM渡して、ShellのVの中でその画面開いて、ツールバーなども Shellが管理するようになってたはず。サンプルではShellに対するMは無かったけど、 ツールバーの細かい設定入れるとしたら当然この設計ではShellのMになるよね。 ShellのVMが本当に必要かどうかはかなり怪しいが。
614 :デフォルトの名無しさん :2013/01/30(水) 23:22:30.14 .net >>609 ビジネスロジックというのを定形的に捉えすぎてね? アプリケーションシェルと言った物の実装も対象が違うだけでビジネスロジックの実装と変わらんだろ。 MVVMはロジックとビューをブリッジ介して分離する仕組みでその対象がシェルでも構わんと思うけどね。 他の実装がしやすいなら無理に適応する必要はないけど。
615 :デフォルトの名無しさん :2013/01/30(水) 23:26:54.51 .net >>609 ドメインモデル(ビジネスモデル)からはビューモデルに対して一切関知することはなく、完全に独立している。 ビューモデルからはドメインモデルを(継承やコンポジションなどの形で)参照することになるが、 当然ながらドメインの詳細には立ち入らないため、ごっちゃになることはない。 > GUIの設定情報を持つためのMを使うのが適切だと思うよ ここではモデル(M)をドメインモデルとビューモデルとに明確に区別しているわけで、このGUIの設定情報と いうのがまさに表示のためのモデルであり、ビューモデルだと>>608 で書いたつもり。 なんか噛み合ってないかな?
616 :609 :2013/01/30(水) 23:32:29.95 .net >>614-615 うん。だからシェルの抽象化がVMだしシェルのロジックやデータがMとするなら Mじゃないかってことが言いたかった。省くならVMを省くべきじゃない? バインディングもあんまり役に立たなそうだし。
617 :デフォルトの名無しさん :2013/02/04(月) 00:54:01.35 .net ViewModelHelper.ReadOnlyDispatcherCollectionのソース見てるんだけど Dispatcher経由でViewModelのDisposeしなくていいの?
618 :デフォルトの名無しさん :2013/02/04(月) 02:17:34.63 .net WeakReferenceがなんとか
619 :デフォルトの名無しさん :2013/02/12(火) 00:41:05.78 .net だからコードビハインドのあるなしとMVVMに何の関連もないと何度言ったら。。。最近コードビハインド付のMVVMしかしてない おがやさん以前は、コードビハインドはMVVMの癌、肯定してる人は糞みたいなニュアンスのこと言ってませんでしたっけ? この人若年性健忘症なのかな?
620 :デフォルトの名無しさん :2013/02/12(火) 00:45:23.42 .net そーとー昔じゃないかな?それ
621 :デフォルトの名無しさん :2013/02/12(火) 00:59:57.57 .net いくら昔でも180度真反対に勘違いするほどの痴呆症を患った高齢の方には見えなかったもので。
622 :デフォルトの名無しさん :2013/02/15(金) 08:39:40.77 .net >>621 ようするにやせ我慢だったと。そういう事です。 コードビハインドなんて所詮MS界隈でしか使われないローカル技術仕様の用語に過ぎず モデル云々を語る抽象的な概念にはほど遠い。 単に趣味と程度の問題を高尚っぽく語りたい人が散見されるだけ。
623 :デフォルトの名無しさん :2013/02/16(土) 04:51:33.73 .net >>622 MS以外でも使われてるだろ もっと幅広い知識を持たないといかんよ。
624 :デフォルトの名無しさん :2013/02/16(土) 06:51:52.98 .net 例
625 :デフォルトの名無しさん :2013/02/16(土) 10:39:51.16 .net MS以外のコードビハインドkwsk!
626 :デフォルトの名無しさん :2013/02/16(土) 11:09:58.98 .net >>625 knockout.js
627 :デフォルトの名無しさん :2013/02/16(土) 15:33:08.84 .net なんかデータバインディング持っているフレームワークなら何でもコードビハインドだとでも 言いたそうな勢いだなw UIの画面設計の宣言的定義とUIロジックの手続き的記述を分けて書けるフレームワークなんて MS以外にもいくらでもあるし、データバインディングもそのための定番手法の一つではあるが knockout.js含めて「コードビハインド」という用語がMS関連以外の文脈で使われることなんて ほとんどね〜よ。手続き的記述の部分をMSが独自にそう呼んでいるだけの話。
628 :デフォルトの名無しさん :2013/02/16(土) 15:44:41.67 .net 日本語だと分離コードになるのか。 確かにMS関連しかその言葉聞かないし、ぐぐってもMS関連しか出てこない
629 :デフォルトの名無しさん :2013/02/19(火) 01:32:44.57 .net 似たようなものだと、コードビハインドという単語ではないけどJSFの管理ビーンとか似た雰囲気
630 :デフォルトの名無しさん :2013/02/19(火) 08:22:24.77 .net 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 .net やっぱダイアログや画面遷移はView Serviceにするのが好きだな。
632 :デフォルトの名無しさん :2013/03/03(日) 10:12:08.72 .net 同意 共通に使えるものにメッセージ使うのはアンチパターン というかメッセージいらない
633 :デフォルトの名無しさん :2013/03/07(木) 11:13:30.47 .net MVVMの意図するところはこんな認識で合ってる? ・V<->VM の依存関係はバインディングに任せましょ ・VM はデータの加工と操作 (コマンド) の提供に専念しましょ
634 :デフォルトの名無しさん :2013/03/09(土) 07:15:19.68 .net 大雑把にはあってるんじゃないか
635 :デフォルトの名無しさん :2013/03/09(土) 19:14:13.47 .net MとV&VMを別プロジェクトにして問題ある?
636 :デフォルトの名無しさん :2013/03/09(土) 19:48:12.38 .net >>635 ないって言うかむしろしろ(´・ω・`)
637 :デフォルトの名無しさん :2013/03/09(土) 19:48:13.70 .net よっぽど小規模でない限り分けるだろ
638 :デフォルトの名無しさん :2013/03/22(金) 14:44:16.04 .net 開幕迎える前にグッバイ・モーガンになるんか?
639 :デフォルトの名無しさん :2013/04/01(月) 12:24:22.90 .net livet 詳しい人いたら教えてくれ。 ttps://github.com/karno/Mystique/blob/master/Mystique/Views/Dialogs/SettingSub/ColoringConfig.xaml ここの200行あたりにある感じで、ConfirmationDialogInteractionMessageAction を使う、MenuItem を作った。 でもこの方法だと、MenuItem の IsEnabled に ListenerCommand の CanXXXX が反映されない。 IsEnabled に反映させるにはどうしたらいいんだろうか?
640 :デフォルトの名無しさん :2013/04/01(月) 13:51:12.65 .net MenuItemに直接アクション持たせてIsEnabled管理も別プロパティでやるか、 CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ
641 :639 :2013/04/01(月) 19:20:38.99 .net せっかく教えてもらったが、いってることがわからんズラ 「MenuItemに直接アクション持たせて」とはどのようすればいいんだろうか? サンプルのサイトがあったら張ってもらえないだろうか。 「CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ」 これをやるためには、MenuItem の Command にバインディングする必要があるだろうが、ダイアログの表示はコード・ビハインドでやるという理解でよいでしょうか? 質問ばかりですまんです。
642 :デフォルトの名無しさん :2013/04/01(月) 19:58:53.84 .net MenuItemのIsEnabledにコマンドの可否状態が反映されないって言うからMenuItemにコマンドはバインドした状態で反映されないって言ってるんじゃなかったの? それともコマンドをMenuItemにバインドせずにMenuItemに反映されないって言ってるの? ダイアログの表示ならコマンドで叩かれたVMからVへメッセージ飛ばしてやるんだろ そのために確認用のトリガとアクション書いたんじゃないのか
643 :639 :2013/04/01(月) 23:25:33.35 .net 質問の仕方がまずかったかな。 IsEnabled と具体的なプロパティを書くのではなくて、 MenuItem の活性・不活性に CanXXXX が反映されない と書けばよかった。 コードはリンク先に書いてあるのとほとんど同じ。 "Interaction.Triggers"に設定していあるのであって、 MenuItem の Command にはバインドされてない。 質問をかえれば、リンク先のようなコードを書いたが、 これでは SetDefaultColorCommand の CanSetDefaultColor が MenuItem の状態(活性・不活性)に反映されません。 どうしたらいいでしょうか? って感じです。
644 :デフォルトの名無しさん :2013/04/02(火) 01:20:28.31 .net >>643 MenuItemはLivetのメッセージ機構なんて知らないし DirectInteractionMessageにもコマンドの状態を反映させる仕組みは無いから 自分でやらなきゃならんだろうな。 VMにプロパティを用意してIsEnabledにバインドするとか コマンドの状態をIsEnabledに反映させるBehaviorでも書けば?
645 :デフォルトの名無しさん :2013/04/02(火) 13:33:43.91 .net LivetのCommandにはCanExecuteプロパティあるからIsEnabledにそれをバインドするのがいいだろう
646 :639 :2013/04/02(火) 21:29:50.11 .net >>645 ありがとう。できた。 シンプルな解決策だね。
647 :デフォルトの名無しさん :2013/04/05(金) 08:36:23.77 .net Livetの0.98辺りの時に書いてたソースコード、 今のバージョンだとそのまま使えないんだな… DispatcherCollectionとかWindowMessageActionとか、 コンストラクタに渡せるパラメータの型とか順番とか、すっかり変わっちゃってる
648 :デフォルトの名無しさん :2013/04/08(月) 17:23:05.27 .net Livet .NET4.5で、読み取り専用のスレッドセーフなコレクションをModelに持たせたいんですけど ObservableSynchronizedCollectionをラップするクラスを自作するしかありませんか?
649 :デフォルトの名無しさん :2013/04/08(月) 19:50:30.83 .net MVVMだのスレッドセーフだの言う前にマルチスレッドをちゃんと理解しろよ 読み取り専用ならスレッドセーフだからReadOnlyCollection<T>でいい
650 :デフォルトの名無しさん :2013/04/08(月) 20:35:10.02 .net 読取専用のコレクションは変更されないわけじゃないぞ
651 :デフォルトの名無しさん :2013/04/08(月) 20:47:02.14 .net さすがにそれは無理があるだろ… それに、随時少しずつ変更されるんじゃなくて時々ゴソっと入れ替わるだけなら Observable*使わなくてもコレクションごと差し替えてしまえばいい
652 :デフォルトの名無しさん :2013/04/08(月) 21:01:42.99 .net っていうか作法的には>>651 のやり方の方が正しく「スレッドセーフ」だと思う Observable*使うと、連続してコレクションを変更するときに変更途中の変な状態が晒されちゃうよ 決してObservableSynchronizedCollectionなら解決するという問題ではなく
653 :デフォルトの名無しさん :2013/04/08(月) 21:35:22.96 .net 一括で変化させるのではなく、逐一反映させたいのです。 その為読み取り専用ラッパもINotify〜でないといけません。
654 :デフォルトの名無しさん :2013/04/11(木) 14:22:53.29 .net Livetプロジェクトを作った時にできるInfrastructureAssembliesフォルダは何のためにあるの?
655 :654 :2013/04/11(木) 14:37:04.33 .net すいません。必要なDLLとクイックヒントのXMLっぽい事は分かりました。 でもLivet.Design.dllが何の役割があるのか分かりません。
656 :デフォルトの名無しさん :2013/04/13(土) 02:18:05.29 .net >>648 ReadOnlyObservableCollection
657 :デフォルトの名無しさん :2013/04/15(月) 14:41:24.53 .net 昔の0.9xのLivetで開発してたもので、画面描画が完了したタイミングでアニメーション開始させるために DispatcherHelper.BeginInvoke(action, DispatcherPriority.Render); みたいに書いてたのがあるんだけど(actionはアニメーション開始させる処理)、 今のLivetだと「BeginInvokeは古い形式です」とかいう警告になってしまう。 まぁ、警告だからコンパイルできるし実行もできるんだけど… 警告出ない、古くない形式ってどう書けばいいんだろう?
658 :デフォルトの名無しさん :2013/04/16(火) 00:44:11.22 .net UIDispatcherプロパティからBeginInvokeだったと思う。
659 :デフォルトの名無しさん :2013/04/16(火) 07:45:34.55 .net >>658 それでOKみたいですね どうもでした 0.9xと1.xで、結構変わってるとこ多いですねー
660 :デフォルトの名無しさん :2013/05/02(木) 16:37:49.02 .net MVVMでの非同期処理をする場合について質問なんですが MはUIスレッドを意識せずプロパティやコレクションを変更し それを監視してるVMが適宜UIスレッドにディスパッチする という感じでするのでしょうか?
661 :デフォルトの名無しさん :2013/05/02(木) 17:18:30.55 .net UIスレッドというものはView側の都合だからそんな感じだな VかVMあたりだろう
662 :デフォルトの名無しさん :2013/05/08(水) 13:29:53.61 .net Livetの公式ページが404 File Not Foundになってる…
663 :デフォルトの名無しさん :2013/05/08(水) 14:57:34.62 .net よくあること
664 :デフォルトの名無しさん :2013/05/10(金) 06:05:27.27 .net よくあるのか たまにしか見に行かないから、この1年半くらいで初めてだった そのうち直るのかな
665 :デフォルトの名無しさん :2013/05/14(火) 17:27:08.94 .net @merancronと@ugaya40のサイレントバトルがかなり面白い
666 :デフォルトの名無しさん :2013/05/17(金) 06:09:53.49 .net Livetのページ、1週間以上経ってもまだ404 File Not Foundなんだが閉鎖しちゃった? それとも移転したのか? 閉鎖にしても移転にしても何かその旨書いといて欲しい しかしユーザー困るな
667 :デフォルトの名無しさん :2013/05/17(金) 14:40:36.69 .net >>666 たぶんサーバーの料金払ってないだけ
668 :デフォルトの名無しさん :2013/05/17(金) 15:27:29.29 .net MVPなんだからAzureの無料枠ぐらいもらってるだろうに……
669 :デフォルトの名無しさん :2013/05/17(金) 19:00:21.91 .net や ら な い か
670 :デフォルトの名無しさん :2013/05/17(金) 19:07:32.07 ID:NuBHhb8n!.net kon
671 :デフォルトの名無しさん :2013/06/24(月) 11:30:16.12 .net Uにリムーブされていることに気がついたw まあ、ちょくちょく揉めてたからなw
672 :デフォルトの名無しさん :2013/10/03(木) 15:35:02.10 .net Vにバインドしたコマンドの内部で非同期操作を呼び出したときのお作法ってあるんですかね?
673 :デフォルトの名無しさん :2013/10/03(木) 16:40:34.53 .net 俺は気にしてないが、VMでは特に気にしなくていいんでね?
674 :デフォルトの名無しさん :2013/10/10(木) 22:24:40.50 .net >>672 同じコマンドを複数回読んだ場合、場合によっては順序が変わる可能性あるからその辺に注意ぐらいかのー
675 :デフォルトの名無しさん :2013/10/10(木) 23:00:23.03 .net いい加減日本語の書籍を出してほしい。
676 :デフォルトの名無しさん :2013/10/14(月) 23:43:00.78 .net ModelがINotifyPropertyChangedを実装する理由は Mを操作した結果、プロパティが変化したことを通知する という理解でいいですか?
677 :デフォルトの名無しさん :2013/10/15(火) 12:36:49.83 .net OK
678 :デフォルトの名無しさん :2013/10/16(水) 15:35:26.82 .net >>676 OnPropertyChanged で渡すプロパティ名が間違っていると View への通知が 正しく行われない。当たり前の話だけど、この種のつまらないトラブルが 多いから注意してね。
679 :デフォルトの名無しさん :2013/11/14(木) 23:01:29.82 .net >>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 .net 俺も最初に参考にしたサンプルが View/ViewModel/Model みたいにフォルダ作ってたので それに倣ってそんな感じにしたけど、サンプル程度のクラス数ならいいんだけど 数が2桁くらいになってくるといまいちだよね。サブフォルダまで作っても。 むしろ、特定の機能のフォルダ作っちゃって、そこに それに関連したView/ViewModel/Modelをセットで入れる、みたいなのも 逆にそこだけで完結しないで複数にまたがるのが分類しにくかったり。
681 :デフォルトの名無しさん :2013/11/15(金) 13:19:46.47 .net >>680 俺もそれが妥当と思う
682 :デフォルトの名無しさん :2013/11/15(金) 14:20:43.75 .net 少なくともView内は分けない方がいいと思う
683 :デフォルトの名無しさん :2013/11/15(金) 14:31:37.31 .net 昔はフォルダで分けてたけど、今はこんな感じ↓ ソリューション - ModelLayerプロジェクト - ViewModelLayerプロジェクト - ViewLayerプロジェクト - UnitTestプロジェクト - Commonプロジェクト
684 :デフォルトの名無しさん :2013/11/15(金) 14:38:30.55 .net 書き忘れたけどもう一つ、ソリューション名と同名のプロジェクトが有るな (仮にMainプロジェクト) MainプロジェクトとUnitTestプロジェクトは、アプリケーションプロジェクトで V/VM/M及びCommonプロジェクトは、クラスライブラリプロジェクト
685 :デフォルトの名無しさん :2013/11/15(金) 18:56:17.04 .net C#の場合自動生成される名前空間にフォルダ階層が付加される仕様がこういう場合鬱陶しい
686 :デフォルトの名無しさん :2013/11/15(金) 19:45:58.66 .net 複数の機能(サブシステム)から構成されるようなアプリなら、俺も680派。 「レイヤ」よりも「機能」の方が凝集度高いんだし。 1機能内でもまだ画面が多いようなら、/機能/の下にView/ViewModelとかを作っても良いけど。 そこまででなければ、少なくともViewとViewModelはセットで。 Modelは、機能固有のものならセットにしても良いけど、だいたいはアプリケーションレベルで 考えるものな気もするので、別配置。
687 :デフォルトの名無しさん :2013/11/15(金) 23:49:30.50 .net ModelはともかくViewとVMは一対一で対応してること多いからなあ
688 :デフォルトの名無しさん :2013/11/16(土) 04:31:20.31 .net Modelはフォルダどころか別プロジェクトだろ
689 :679 :2013/11/17(日) 16:07:31.49 .net >>680 ,686 機能ごとに分けて、そのフォルダの中にV/VMを突っ込むのよさそうだね。 VとVMは一緒にいじること多くて、近くに置いておきたいし。 ありがとう!! すごく参考になった。
690 :デフォルトの名無しさん :2013/11/17(日) 16:51:12.93 .net VMが扱うモデルは1つとは限らないわけで、そういうのは無理があると思うけどね
691 :デフォルトの名無しさん :2013/11/18(月) 10:21:42.10 .net ん?
692 :デフォルトの名無しさん :2013/11/19(火) 23:38:23.24 .net >>690 機能単位でまとめるのはVとVMまでにして、モデルは別フォルダとか別プロジェクトにまとめる、でいいんんじゃないかな?
693 :デフォルトの名無しさん :2014/01/13(月) 13:39:58.61 .net Mの設計にいまいち確信が持てないんだけど 例えばChromeみたいなタブブラウザを作る場合、開いてるページのコレクションはMで持つの?
694 :デフォルトの名無しさん :2014/01/13(月) 18:47:34.47 .net >>693 MVVMはそんなに厳密に考えんでいいと思うけどね。 VMをVIEWを軽くするためのロジック移し場所ぐらいに考えてモデルを分ける必要あるなら作ると。そのモデルは一つでも複数でもいい。 Chromeの例なら自分なら開いてるタブやその他の状態を持つアクター一個作るかな。
695 :デフォルトの名無しさん :2014/01/14(火) 13:13:51.65 .net MVVMの設計に関しては、 まずアプリケーションをVとMに分ける。 次にVをVとVMに分ける くらいの考えでいいと思う
696 :デフォルトの名無しさん :2014/01/15(水) 10:21:03.85 .net 今はMVVMPCEARELS
697 :デフォルトの名無しさん :2014/03/05(水) 07:59:10.50 .net test
698 :デフォルトの名無しさん :2014/03/05(水) 16:17:16.97 .net 普及している感じがしない
699 :デフォルトの名無しさん :2014/05/20(火) 17:04:41.75 ID:Vv+C9W3P.net >>699 のような手合いは一度ふぁうらー先生の本でも読んだらいいよ 関心事の分離とフレームワーク依存がわかってない
700 :デフォルトの名無しさん :2014/05/20(火) 20:57:52.43 ID:PPVaI37M.net PoEAAは読んでるけど、どこがわかってないのかわからないので、教えてくれ。
701 :デフォルトの名無しさん :2014/05/20(火) 22:25:34.65 ID:9K9vHtgJ.net >>699 今迄一度もViewでこのデータが必要だからここに持たそうとかやったことのないものだけが石を投げなさい(。-_-。)
702 :デフォルトの名無しさん :2014/05/21(水) 21:50:13.56 ID:v99ZJ6SN.net >>699 マジでなにがどうわかってないんだか教えて欲しいんだがな。
703 :デフォルトの名無しさん :2014/05/23(金) 07:24:21.57 ID:mY7MwSDJ.net PoEAAのMVCの説明って意味不明だよな
704 :デフォルトの名無しさん :2014/05/23(金) 11:25:59.93 ID:EWfyg3GH.net >>702 [ModelがViewを意識]と[Modelの責務]は次元の異なる問題ではないだろうか
705 :デフォルトの名無しさん :2014/05/23(金) 11:26:58.12 ID:EWfyg3GH.net >>703 翻訳文が意味不明なんだろうな
706 :デフォルトの名無しさん :2014/05/23(金) 13:12:25.80 ID:3xLYWpXM.net >>704 だからモデルの債務になるものでビューのことを一切意識しないで扱えるものがどんだけあんだよ。 ビューでこういう使い方するからこういう風に元のデータは持とうとかいちどもやったことないの?
707 :デフォルトの名無しさん :2014/05/23(金) 13:57:11.39 ID:EWfyg3GH.net >>706 それはModelのデザインの話であって、責務とは別の話だろうよ デザインと責務がごっちゃになってない? いすれにせよ>>699 の非難は的外れだけどね
708 :デフォルトの名無しさん :2014/05/23(金) 14:02:08.57 ID:EWfyg3GH.net 大きな切り口としてアプリケーションをプレゼン層とドメイン層に分ける プレゼン層=ビュー、ドメイン層=モデルだから当然責務は違う しかし>>706 のいうとおり、モデルがビューの使い方を意識した設計になるのは 開発の都合上当然の話だと思うな
709 :デフォルトの名無しさん :2015/02/26(木) 21:33:45.94 ID:cT7tYUid.net ReactiveProperty良さげなんだけど使ってる人います? 週末にでも遊んでみよう。
710 :デフォルトの名無しさん :2015/09/25(金) 15:22:24.80 ID:kx8P/2+s.net Livet1.3キタ
711 :デフォルトの名無しさん :2015/10/21(水) 22:31:30.80 ID:4/KXy1nx.net WPF MVVMでアプリ作ってる人いるんだろうかと思えるくらい過疎っぷりだな ほんと情報少なくて困ってる
712 :デフォルトの名無しさん :2015/10/22(木) 01:36:32.77 ID:5QLmtDbA.net こんなスレあったのか。今まで気が付かなかった。 MVVMは机上の空論っていうか筋が悪いの一言に尽きると思う。 これは過去にオブジェクト指向が攻撃されたような批判者の理解不足に基づく誤解では必ずしもない。
713 :デフォルトの名無しさん :2015/10/22(木) 11:01:27.71 ID:T+i/NslY.net とオブジェクト指向の時にも同じようなことを言っていた人はいた。
714 :デフォルトの名無しさん :2015/10/22(木) 12:13:21.98 ID:dfQe7r4R.net >>712 具体的にはMVVMのどこらへんが実情に即していない机上の空論で、筋の悪さなの? 可能であれば、古典的MVCやMVPとの比較も交えながら論じてみてほしい。
715 :デフォルトの名無しさん :2015/10/22(木) 13:13:45.09 ID:522gqyPw.net >>713 オブジェクト指向は筋が悪かったからな
716 :デフォルトの名無しさん :2016/01/20(水) 23:45:57.28 ID:xrqpD1Un.net 結局どんな設計がいいの? Rxに傾倒したけど、上手く使いこなせてない
717 :デフォルトの名無しさん :2016/05/01(日) 15:54:23.24 ID:tKi6j9CT.net 匿名通信(Tor、i2p等)ができるファイル共有ソフトBitComet(ビットコメット)みたいな、 BitTorrentがオープンソースで開発されています 言語は何でも大丈夫だそうなので、P2P書きたい!って人居ませんか? Covenantの作者(Lyrise)がそういう人と話したいそうなので、よろしければツイートお願いします https://twitter.com/Lyrise_al ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーw The Covenant Project 概要 Covenantは、純粋P2Pのファイル共有ソフトです 目的 インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します 特徴 Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW) 接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です DHTにはKademlia + コネクションプールを使用します UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります) 検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません ・
718 :デフォルトの名無しさん :2016/05/01(日) 22:27:00.95 ID:VrD9Va1p.net >>716 fluxとかかな。まだよく分かっていないけど。 状態を一箇所に集約する
719 :デフォルトの名無しさん :2016/05/03(火) 11:18:03.92 ID:uB7yk5jG.net fluxのデータフロー見てたらApache Strutsを再発明したかったのかなって思た
720 :デフォルトの名無しさん :2016/05/10(火) 17:20:07.82 ID:sgC64ZMu.net MVVMって保守性が悪いよね。 WPF自体がそういう傾向が強いけど、MVVM使うと輪を掛けてそうなる。 他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、 ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。 MVVMで保守性が高くなるんだ!って喧伝してる人がいるのは知ってるけど、 正直裸の王様を褒めてるようにしか思えない。
721 :デフォルトの名無しさん :2016/05/10(火) 20:43:19.06 ID:OBekjSgo.net 結局正解はなくて最適解があるだけなんだけどさ よくある失敗はMVC、それも頭でっかちなコントローラーをVMに置き換えているだけパターン この場合ビューモデルが主役で、テンプレートエンジンのビューと1:1の対となる入れ物の箱モデル を量産することになる ちょこっとイベントハンドラーをコードビハインドに書いたら、あとは全部ビューモデルにお任せ という中央集権国家が誕生、疎結合どこいったって話だな
722 :デフォルトの名無しさん :2016/05/10(火) 21:04:44.88 ID:Urp5/7iJ.net >>720 >他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、 >ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。 これって単に慣れてないからってだけじゃなくて?
723 :デフォルトの名無しさん :2016/05/10(火) 21:24:17.05 ID:YLufBM4s.net 昔のようなデバッグして追いづらいってのはあるな。
724 :デフォルトの名無しさん :2016/05/11(水) 11:26:55.39 ID:sA9FQTwa.net やっぱりrails系は偉大だったってことかなー。 どこにどんなコードを置くのかフレームワークとして強制するって大事だね。 iOSとかUIKitってだけだから特にファイル構成に対する強制がなくて悩む。
725 :デフォルトの名無しさん :2016/11/25(金) 20:31:02.28 ID:JXCOPEY3.net お前らがMVVM頑張っても 画面設計者がMVVM理解者とは限らないから どこかは破綻するんやで
726 :デフォルトの名無しさん :2016/12/15(木) 23:39:13.49 ID:KILwFG0x.net MV)o¥o(VM
727 :デフォルトの名無しさん :2017/03/23(木) 17:58:48.49 ID:aO3Y1mks.net データを格納したdatatableをdatagridにバインドして表示させてます。 この場合、datatableはVMですか?Vですか?
728 :デフォルトの名無しさん :2017/03/23(木) 23:57:20.04 ID:pns5gc7N.net 他のフレームワークに比べてMVVMが有用なケースって、WPF以外だとどんなのがありますか?
729 :デフォルトの名無しさん :2017/03/31(金) 23:28:02.62 ID:Cc537bij.net >>728 Xamarin.Forms vue.js
730 :デフォルトの名無しさん :2017/04/21(金) 04:30:27.44 ID:H6APCPmE.net UWPみたいな大きい画面から小さい画面までサポートする奴。 UIとロジック分けられないと死ねる。
731 :デフォルトの名無しさん :2017/05/11(木) 22:40:49.29 ID:NjKe635i.net modelからViewModelに通信の結果を返すときに、 Rxとか使わずに、interfaceを渡してコールバックを返すようにするのは何かマズいんでしょうか
732 :デフォルトの名無しさん :2017/05/11(木) 23:10:02.50 ID:w+/nr1Tg.net Rxも結局インターフェースだしいいんじゃ?
733 :デフォルトの名無しさん :2017/05/11(木) 23:55:27.09 ID:NjKe635i.net modelは状態の公開と戻り値のないメソッドの提供のみするそうですが、 状態の公開っていうのは要はpublicなfieldってことなんでしょうか getterで提供したらなんで駄目なんでしょうか c#のことはよくわかりませんandroid javaを想定しています
734 :デフォルトの名無しさん :2017/05/12(金) 11:29:50.90 ID:WPNdofPW.net >>733 メソッドの戻り値をvoidにする、setterを提供しないのはMVVM由来ではなく、非同期な作りをしたい場合に起因します。 これは非同期な作りの場合、メソッドを呼び出しても直ちに状態が変更されるとは限らないから。 なので、状態の変更が完了した時点でMが通知し、受信側がgetterを介して状態を取得することを推奨しているに過ぎない。 逆に同期的な呼び出ししかしないのであれば、setterやメソッドの戻り値も好きにすればいいと思います。
735 :デフォルトの名無しさん :2017/05/12(金) 12:01:49.68 ID:efiy+Fg+.net がや氏の戻り値返すなとかはCQRSやReactみたいに処理の流れを固定しろってのが本質と思うが本人もアーキによって返しますよとかいってるからじゃああの煽りはなんだったの感もありよくわかんね
736 :デフォルトの名無しさん :2017/05/12(金) 18:50:06.13 ID:NqFIOOZC.net 本人の中では色々な蓄積もあってその上で言ってんだろうけど、間を飛ばすから外から見たらよくわからん事になってるという印象
737 :デフォルトの名無しさん :2017/05/12(金) 19:52:15.91 ID:05vfegfG.net とりあえず御大の言うことはスルーしておいて、Flux、Reduxなんかについて調べてから、自分で答えを出せばよろし
738 :デフォルトの名無しさん :2017/05/12(金) 20:05:15.61 ID:6PqY2VyR.net C#で状態の公開というとプロパティを使うわけだけど、 javaにはプロパティがないからgetter使うしかないだろうし… そもそもMVVMではgetter使っちゃダメなんて話があるの…?
739 :デフォルトの名無しさん :2017/05/12(金) 20:34:29.17 ID:z/cC9xJA.net 状態の公開が何でpublicなfieldになんのか分からん オブジェクト指向もっかい勉強した方がいい
740 :デフォルトの名無しさん :2017/05/12(金) 22:16:02.54 ID:Ne3HESGY.net いや返り値のないメソッドしかテイギシタラ駄目っていう縛りがあると思ってたから、 getterも駄目なのかと
741 :デフォルトの名無しさん :2017/05/12(金) 23:10:52.37 ID:6PqY2VyR.net MVVMの提唱がMSからだし、MSが作った言語にはプロパティがあるから… …javaのgetterが駄目ならプロパティ使うのも駄目になるはず
742 :デフォルトの名無しさん :2017/05/12(金) 23:56:43.00 ID:XKa7CxLZ.net ゲッターかプロパティかは本質じゃないだろう。 ゲッターをフィールドっぽく見せてるのがプロパティなだけなんだし。
743 :デフォルトの名無しさん :2017/05/13(土) 06:13:49.08 ID:Hzzf9sbT.net AndroidでMVVMやりたいだけなのに C#でのMVVMとFluxとReduxとクリーンアーキテクチャと databindingとRxとretrolamdaと全部学ばないといけないわけ? 敷居高杉ませんか
744 :デフォルトの名無しさん :2017/05/13(土) 08:08:27.52 ID:JyAd7JIY.net MVVM含めアーキテクチャごっこをやること自体が目的なら全部学べよ。 Androidで開発しやすくしたいというのであれば、まずはData Bindingを使うことと、 APIの戻り/公開メンバとしてObservableを使ってみるところから始めろ。 DroidKaigiのアプリあたりを参考にしながら。
745 :デフォルトの名無しさん :2017/05/13(土) 08:55:58.29 ID:R5mpG+FZ.net build 2017と関係あるのかわからないけど、UWP関連でこんなもんが https://github.com/Microsoft/WindowsTemplateStudio https://developer.telerik.com/topics/net/announcing-windows-template-studio/
746 :デフォルトの名無しさん :2017/05/13(土) 09:01:35.75 ID:Hzzf9sbT.net droid kaigiですね。ありがとうございます。 他にMVVMの参考になる小規模なソースコードのgithubリンクとかないっすか
747 :デフォルトの名無しさん :2017/05/13(土) 14:21:43.11 ID:DOmFl3BV.net Android java MVVMで検索したら色々出てくるけど…
748 :デフォルトの名無しさん :2017/05/13(土) 17:26:38.50 ID:Hzzf9sbT.net 画面遷移の処理とか結局viewでしかできないから、 view -> viewModel -> view で行ったり来たりしてるのとかみると糞だなあと思う
749 :デフォルトの名無しさん :2017/05/13(土) 21:32:34.67 ID:JyAd7JIY.net Presentation Coordinator Navigation Service なお、画面遷移の話とは別に、Androidの場合どうしてもActivity/Fragmentに 依存してしまう部分は出てくるから、その辺はあまり厳密に考えない方がいい。
750 :デフォルトの名無しさん :2017/05/25(木) 12:23:45.13 ID:7qHN/0ER.net VMとMの分割についてきちんと説明してくれてるサイトってあまりないけど、 基本的には全部Mに入れてVMはプロパティとしてMだけを持ってそれをVにバインドするってことでいいの? 大抵のサイトでは全部VMに入ってるけど
751 :デフォルトの名無しさん :2017/05/25(木) 12:55:06.49 ID:jD8c7u6v.net サイトは知らんが、一番しっくりくるなーと思う考えの一つは MはDBなどのデータを格納する何か、もしくはデータそのもの。 VMはMからのデータを加工するものとVewとの橋渡しを分けてVMへ。 VはVewそのもの。 ってのが個人的に一番しっくりくる。
752 :デフォルトの名無しさん :2017/05/25(木) 12:57:53.56 ID:V6q89FWa.net viewそのものだとactivityがviewになるのは違和感がないか
753 :デフォルトの名無しさん :2017/05/25(木) 12:59:02.78 ID:jD8c7u6v.net 違和感ある。 VMに入れたい。
754 :デフォルトの名無しさん :2017/05/25(木) 14:34:21.13 ID:CXNFHBlU.net MVCだろ M はDB以外のことは出来るだけしない V は表示するだけ C(VM) で色々する 概ね >>751 さんに同意
755 :デフォルトの名無しさん :2017/05/25(木) 18:18:08.97 ID:V6q89FWa.net VMがactivityの参照を持ったらだめだと聞いたが。。 Xamarinだとpageか
756 :デフォルトの名無しさん :2017/05/26(金) 00:49:21.51 ID:rlJlQaZI.net C=VMだとMVCと変わらんだろうが
757 :デフォルトの名無しさん :2017/05/26(金) 02:36:40.07 ID:NvS9muX6.net イメージとしてはCより広い範囲のものをぶち込んでMやVに余計な物置かないのがVMって思ってる。 基本MVCと変わらん。 Cじゃないのはどこに置くとか名前から混乱してる人多かったから、VでもMでも無いのは全部VMってした方が混乱は少ない。
758 :デフォルトの名無しさん :2017/05/26(金) 06:12:40.96 ID:Xdie43+z.net MVVMのVはMVCのV+Cだよ MVPのVとかと同じ
759 :デフォルトの名無しさん :2017/05/26(金) 06:38:23.57 ID:OOmYkqkr.net MVVMのVって左から3番目のVのことですか
760 :デフォルトの名無しさん :2017/05/26(金) 07:01:45.39 ID:Xdie43+z.net 2番目だよ
761 :デフォルトの名無しさん :2017/05/26(金) 12:30:06.83 ID:fehtyedu.net めちゃ効率悪い作り方
762 :デフォルトの名無しさん :2017/05/26(金) 15:34:26.98 ID:ZNc2U8qB.net MVVMってMVCより明確にしたもの VMはCという漠然とした者じゃなくて Viewに対応するオブジェクトそのもの。 だからVMのプロパティを変更することでViewに反映されるし Viewで何か変更するとVMのプロパティに反映される。 双方向バインディングを使って実現する。
763 :デフォルトの名無しさん :2017/05/26(金) 19:26:58.74 ID:GnitEmTF.net 全然進化してないな
764 :デフォルトの名無しさん :2017/05/26(金) 20:59:38.95 ID:ovKX6RUR.net >>761 効率求めたらガチガチにVewと結びつくからな。 Vewが固定ならMVCもMVVMも要らない。 デスクトップやモバイルで中身同じだけどVewだけ違うとかだからMVCやMVVMが必要になる。 デスクトップとモバイルで同じ処理を別々に書くよりは全体では効率が良くなる。 特にモバイルが画面の大きさや画面比率が多様化してる昨今では。
765 :デフォルトの名無しさん :2017/05/26(金) 21:03:56.89 ID:ovKX6RUR.net >>763 強いて進化と言ったらMVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したままで、updateで更新しないと値を更新しなかった。 MVVM独自かは不明だが、MSでは相互に値の更新を自動通知し合う仕組みが出来た。 >>762 が言ってるのはそういう事。
766 :デフォルトの名無しさん :2017/05/26(金) 21:40:38.92 ID:Xdie43+z.net >>765 そんなもん独自のわけないだろ
767 :デフォルトの名無しさん :2017/05/26(金) 22:27:08.33 ID:F2M8XGQu.net MVVMにおいてactivityはviewでいいんだよな?
768 :デフォルトの名無しさん :2017/05/26(金) 23:41:27.21 ID:ZNc2U8qB.net 更にいうとMVVMをさらに発展と言うか破綻しづらいようにしたのが flux。MVVMのVMは双方向バインディングだけど fluxの場合は、Viewの変更は直接VMに反映しない方針。つまり片方向バインディングに限定した。 その代わりVMへの変更関連をActionに集約して Action -> State(VMに対応) -> View ->Action と片方向への情報の流れに限定したのがflux
769 :デフォルトの名無しさん :2017/05/27(土) 02:57:55.41 ID:V3ffhZkY.net >MVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したまま 糞Windowsだけだろω
770 :デフォルトの名無しさん :2018/05/23(水) 23:07:17.16 ID:Au5e7VGg.net 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方 役に立つかもしれません グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』 USCRF
771 :デフォルトの名無しさん :2018/07/04(水) 23:01:58.94 ID:gFgZc5FG.net QIC
772 :デフォルトの名無しさん :2018/07/06(金) 12:35:20.43 ID:uTPDH9XV.net USCRF
773 :デフォルトの名無しさん :2019/01/28(月) 14:30:35.46 ID:2/HZJEKq.net LivetとPrismとはなんだったのか
774 :デフォルトの名無しさん :2019/01/28(月) 22:53:33.32 ID:ELKeaiTx.net Livetは使った事ないから知らんがWPF開発には色々便利なものあったらしいしPrismも便利なとこあるんじゃないの 自分は使わんけど
775 :デフォルトの名無しさん :2019/01/30(水) 03:07:28.56 ID:nTVyoRLY.net 知らんなら答えなくて良いんじゃね?
776 :デフォルトの名無しさん :2019/01/30(水) 10:24:55.23 ID:g/bNoaAl.net 評判は聞いてたからその範囲で教えてあげてんだけど? 無知すぎるボンクラは逝ってどうぞ
777 :デフォルトの名無しさん :2019/01/30(水) 10:35:20.87 ID:MXCEKHH4.net Prism.Unityは、UWP版のほうがシンプルでかつ十分な機能で良いんだけど wpf版もあっち基準に改善したら良いのにな
778 :デフォルトの名無しさん :2019/01/30(水) 12:36:56.89 ID:m67rAUwN.net https://teratail.com/questions/140681 MVVMやってるのこんなのばっかりだからな死滅すればいいよ
779 :デフォルトの名無しさん :2019/01/30(水) 12:37:12.23 ID:m67rAUwN.net ハイハイ理解できないから終了ね
780 :デフォルトの名無しさん :2019/01/30(水) 12:38:11.42 ID:m67rAUwN.net >>776 知らないなら答えなくていいんじゃね? ぼんくらは死ね
781 :デフォルトの名無しさん :2019/01/30(水) 12:43:13.60 ID:eltFPQSh.net >>776 知らんなら答えなくて良いんじゃね? 過疎スレで無駄に煽るボンクラ
782 :デフォルトの名無しさん :2019/01/30(水) 14:39:06.71 ID:g/bNoaAl.net 無知が顔真っ赤にしてテラワロス
783 :デフォルトの名無しさん :2019/02/05(火) 22:13:49.20 ID:y7JCcM6u.net >>782 無知が顔真っ赤にしてテラワロスっておまw そんなんがほんとに面白い人とかいるのかね MVVMはどこいったのw スレタイと何も関係ない書き込みしちゃって頭おかしくないのボンクラwwww
784 :デフォルトの名無しさん :2019/02/05(火) 22:15:30.79 ID:y7JCcM6u.net いやテラワロスってのはMVVMなんだろうな 無知なのでわからんわ
785 :デフォルトの名無しさん :2019/02/05(火) 22:50:39.27 ID:sDFzuzWu.net >>778 >INotifyPropertyChanged はバインド専門ではありません。 これって詭弁だよね MVVM使う時点で通常のモデルにすると不便だからINotifyPropertyChanged使うだけ
786 :デフォルトの名無しさん :2019/02/05(火) 22:57:59.44 ID:sDFzuzWu.net MVVMじゃない設計で作られた モデル、ビジネスロジックがあってそれをMVVMで使う場合どうすんの?ってことなんだろうけど もう一層外からくるんだだけじゃうまくいかないからほとんどを作り直しすることになるんじゃないかな?
787 :デフォルトの名無しさん :2019/02/06(水) 02:16:42.38 ID:ar/eio3d.net >>783 何日も前のに突然どうしたw >>785 MMV間は好きにすればいいかと 自分はわざわざMでINotifyPChangedなんか使わんけど
788 :デフォルトの名無しさん :2019/02/06(水) 09:39:48.85 ID:DbH07QrE.net 俺なんかMVCすらよくわかんないな Webは兎も角、それ以外はMVCだと言われてるアプリを見てもCからVを書き換えてるのだらけに見えちゃうんだな これでいいんか?それとも世の大半が間違えてるのか?どっちなんだ
789 :デフォルトの名無しさん :2019/02/06(水) 12:24:14.98 ID:ar/eio3d.net Cからvだけでしかないってのはダメだと思うが、結局その場合にちょうどいい程度に疎結合になってればいいと思うけどね 自分はMVにロジックも詰め込んで、でかくなってきたらMにする程度でやってる
790 :デフォルトの名無しさん :2019/02/11(月) 03:23:52.16 ID:h3xrvU+a.net いつも疑問なんだけどMVVMでダイアログ表示するときなんでVMでShowDialog()しちゃいかんの? MessengerでViewに送ってコールバックでってやるよりもVMをDataContextにぶっこんで直接操作したほうがわかりやすくない?
791 :デフォルトの名無しさん :2019/02/11(月) 04:01:02.71 ID:KW1QXsfq.net >>790 MVVMのVMは、UIへの依存を排除することを試みるパターン。 なので、直接呼んで良いかと問われればNo UIの知識に起因する処理を行いたいのであれば、UIから提供されたインターフェースを介してUI操作を行うMVPの採用を検討する。 結局のところ、MV*の違いは責任範囲の違いだけであり、MVPがMVVMよりV寄りに広いパターンなので、MVVMをベースにMVPにしても構わない。 ただしその場合、混乱の元なのでMVVMとは呼称すべきではない。
792 :デフォルトの名無しさん :2019/02/11(月) 12:20:24.20 ID:YckZaLLU.net >>790 ぶっ込んで直接操作が何を指してるのかわからん。 そのダイアログを表示がらみだと思うけどもうちっと具体的に言ってくれ。 元のViewと対応したVMがあったとして、そこからダイアログ表示させる場合でいいんだよね?
793 :デフォルトの名無しさん :2019/02/11(月) 13:34:01.09 ID:NWPg0Oyv.net >>792 すまん、説明が悪かったかも あと無意識にWPFを前提に話してしまっていた MainWindow MainWindowViewModel MainWindowModel DialogWindow DialogWindowViewModel があったとしてMainWindowのボタン押下をトリガーにDialogWindowを表示したいとする でWPFの昨日でVMにコマンドバインディングしていたボタンの処理の中で DialogWindowのDataContextにDialogWindowViewModelを入れる →MainWindowViewModelの中でDialogWindowのインスタンスを生成する みたいな感じ
794 :デフォルトの名無しさん :2019/02/11(月) 15:12:43.09 ID:QkJqimZ7.net VMからVを直接生成するのは禁じ手かと てスタビリティーが担保できない
795 :デフォルトの名無しさん :2019/02/16(土) 02:23:43.23 ID:9HG1VuDS.net 7年前から何も状況変わってなくてワロス
796 :デフォルトの名無しさん :2019/02/16(土) 02:52:06.72 ID:9HG1VuDS.net https://teratail.com/questions/74961 わからないやつは使うな! でほんとに使わなかったケースが多かっただけみたいだな ユーザーの質がほんとひどい 難しい案件でだけ使えばいいがな
797 :デフォルトの名無しさん :2019/02/16(土) 09:30:22.31 ID:9K5d8FVn.net 自分は自分で作るちょいアプリでも使ってるけどな といってもVM膨らませてMもそこでやってて、ややこしくなったら分離させてるだけだけど
798 :デフォルトの名無しさん :2019/02/16(土) 19:22:44.93 ID:PhVDH7kZ.net WPF+MVVMはテストがつらい M、VMでテストが出来てても実際にVでうまく動くかは全然わからない
799 :デフォルトの名無しさん :2019/02/16(土) 20:37:11.87 ID:9K5d8FVn.net >>798 ん?それほかのUIフレームなら出来るん?
800 :デフォルトの名無しさん :2019/02/16(土) 20:48:59.47 ID:mveZudXk.net アプリケーションのテストとしてはVM-M間で十分だと思うがな。 V-VM間はデータバインディングが意図通りか確認する程度だし。 少なくともFormsよりだいぶUIに近いところまで自動テストできるようになった。
801 :デフォルトの名無しさん :2019/02/17(日) 03:18:26.01 ID:xGFF6jRx.net >>798 ViewはMVの状態をそのまま表示するだけってのが理想だからね セレニウムだっけ?WEBでのUIテスト出来る奴とかあるかもだけど、自動テストでそこまでの工数かけるのちときつくね? VMのテストならプログラム的にしやすいからまだわかる
802 :デフォルトの名無しさん :2019/03/17(日) 03:07:47.90 ID:ZfsC9V3u.net >>698 バカには使えないありがたいアーキテクチャなので 普及とかはどうでもいい話だった
803 :デフォルトの名無しさん :2019/03/17(日) 08:02:38.52 ID:F89k9A+v.net VisualWorksのPluggable MVCとどう違うのだろうか?
804 :デフォルトの名無しさん :2019/03/17(日) 18:31:05.56 ID:drnV2zGh.net Pluggable MVCとはだいぶちがうだろう Application Modelの間違い?
805 :デフォルトの名無しさん :2019/03/17(日) 22:43:26.65 ID:F89k9A+v.net >>804 ValueHolder、AspectAdaptor、PluggaleAdaptorとか
806 :デフォルトの名無しさん :2019/03/17(日) 22:56:42.27 ID:drnV2zGh.net ああ、そういうことか もっと古典的でプリミティブなものを指しているのかと思った http://aokilab.kyoto-su.ac.jp/documents/MVC/page4.html
807 :デフォルトの名無しさん :2019/03/17(日) 23:43:40.49 ID:F89k9A+v.net 結局、ビュー寄りのモデルを作るという発想は90年代初頭にVisualWorksで提唱されていたんじゃないかと。
808 :デフォルトの名無しさん :2019/03/18(月) 01:01:31.84 ID:Y1evCyMB.net まあその結論で合っているんだけど ただValueHolderとかのアダプターはあくまで ApplicationModelのプロパティでデータバインドを実現するための道具に過ぎないので https://matarillo.com/general/uipatterns.php#p3 MVVMとの類似性に言及するのであれば Pluggable MVCではなく「ApplicationModelアーキテクチャ」と表現する方が誤解が無くてよいと思う http://wiki.c2.com/?ModelModelViewController
809 :デフォルトの名無しさん :2019/03/18(月) 01:37:38.06 ID:QCOM2t0u.net もともとMVCとかでごちゃごちゃしてきたところにMVVMってことなんだろうな デスクトップアプリに当てはめるのは微妙だったよ
810 :デフォルトの名無しさん :2019/03/18(月) 07:19:28.89 ID:Y1evCyMB.net いやそういう基本的な理解の欠如ではない
811 :デフォルトの名無しさん :2019/03/18(月) 09:45:01.81 ID:npgehNDX.net デスクトップに当てはめるのが微妙ってのは何だ?仮想Dom的なものがあればおさまる話? あとMVVMはMVCを改良したってよりもXAMLのバインディング気候に合わせたって側面の方が強いと思うがな それを改良と言えばそうだけど
812 :デフォルトの名無しさん :2019/03/18(月) 11:53:25.70 ID:sCXVSnIM.net もしや810はMVCとMVC2を混同してるとか?
813 :デフォルトの名無しさん :2019/03/19(火) 03:35:07.74 ID:3jNcVOgT.net 実装者の能力不足が問題になるということは設計パターンが悪いんだろ 本当に理解してるか確認するが難しいようなのもダメだ
814 :デフォルトの名無しさん :2019/03/19(火) 21:56:18.31 ID:RkrxeYqz.net バインディングで楽が出来れば、それで満足よ
815 :デフォルトの名無しさん :2019/03/19(火) 22:06:06.31 ID:+Ccy7x/V.net >>814 楽できるかどうかじゃなくて、 画面を直接触らずに済むかどうかの問題だろ。
816 :デフォルトの名無しさん :2019/03/22(金) 00:42:05.87 ID:piAmWzDj.net こりゃ天才ですわ https://qiita.com/hiki_neet_p/items/e381c687b0644c0e4978
817 :デフォルトの名無しさん :2019/05/30(木) 12:04:36.21 ID:v6SxCCrX.net 暇だから数年ぶりにWPFでも触ってみようかなと思ってるけど、 乱立してた結局MVVMライブラリって結局何かに統一された? Livetは死んでしまったみたいだねw 個人的には応援してだけど
818 :デフォルトの名無しさん :2019/05/30(木) 19:49:16.08 ID:YQby5rNV.net >>817 統一されたかどうかは分からんが、 https://github.com/XamSome/awesome-xamarin/blob/master/README.md#mvvm によると、ReavtiveUI, MVVVCross, Prismあたりが人気らしい
819 :デフォルトの名無しさん :2019/05/30(木) 19:50:47.36 ID:YQby5rNV.net >>818 typo x MVVVCross o MVVMCross
820 :デフォルトの名無しさん :2019/06/19(水) 05:03:53.74 ID:tVNS+22r.net 【出資】松本卓朗 人工知能詐欺【注意】 https://rio2016.5ch.net/test/read.cgi/rikei/1560859403/
821 :デフォルトの名無しさん :2019/07/27(土) 02:26:32.72 ID:0sBDs5f5.net むっちゃ初歩的なところの質問になってしまうのですが、 WPF + Prismの環境で、画像ファイル(png)をウインドウ内にタイル状に並べたいのですが、 単体でパスをSourceに指定して、Converterを通して表示、までは出来たのですが、 これをListView上でおこなおうとすると、ListviewにBindingしているObservableCollectionにAddしても、 画像が表示されません。 何かわかりやすいサンプルや、チュートリアルなどありませんでしょうか?
822 :デフォルトの名無しさん :2019/07/27(土) 03:17:09.73 ID:l8PDbbg2.net >>821 チュートリアルは知らんが、リストにテキストやボタンは表示できるの? 出来るなら今単体でコレクションの要素とビューテワやってる関係を同じようにするだけだけど
823 :デフォルトの名無しさん :2019/07/27(土) 10:04:07.36 ID:0p0d4tKK.net >>821 ListViewのTemplateをGridViewとしDataTemplate使うんじゃなかった? よく知らんけど。
824 :デフォルトの名無しさん :2019/11/01(金) 18:07:00.51 ID:hqW7WiA1.net >>821 どんな見た目作りたいの?
825 :デフォルトの名無しさん :2020/07/02(木) 15:07:15.93 ID:WhLcbIiC.net MMVMで言語を作る!
826 :デフォルトの名無しさん :2020/07/02(木) 17:47:32 ID:WhLcbIiC.net LLVMと勘違いした
827 :デフォルトの名無しさん :2021/01/27(水) 11:51:54.98 ID:cJSBZXf9.net てす
828 :デフォルトの名無しさん :2021/01/27(水) 23:40:32.54 ID:7/w7pDgL.net Win Formsでやってる人いますか? datagridviewで値によってセルの色を変える場合、どのようにしてますか?
829 :デフォルトの名無しさん :2021/01/28(木) 01:44:53.83 ID:aQj0oWVr.net >>828 BindingListへの追加・変更・削除がイベントで拾えるので、 そのイベントハンドラで状態に応じてセル変更すればいいんじゃね? 汎用化するのであれば、BindingListを[M]、Gridを[V]とみなし、 その間を取り持つPresenterに移譲させるMVPパターンにするとかか めんどくさがりやなので、前者でお茶を濁すかなぁ
830 :デフォルトの名無しさん :2021/01/29(金) 20:29:07.30 ID:czxZDJRE.net MVVMはバインディングを活用するために考案されたパターンなので、WinFormsでは実践できません
831 :デフォルトの名無しさん :2021/02/02(火) 19:09:08.24 ID:LnwudBv/.net ユーザーメリットなしのオナニー
832 :デフォルトの名無しさん :2021/02/02(火) 21:40:04.70 ID:WEqR7ZrT.net ユーザーってのがアプリユーザならその通り 開発者は恩恵受けてるよ
833 :デフォルトの名無しさん :2021/04/06(火) 11:03:35.23 ID:A0Gb+cSU.net MVVM おっそ。 イベント発生元からトンネル経由しない前に捕まえて、View->ViewModelのイベントデリゲート呼ぶのが一番速い。 Commnad Bindingなんか使ってられない。 遅くて・・・
834 :デフォルトの名無しさん :2024/02/29(木) 21:06:03.14 ID:xliFyZcDB 拉致ガーだの個人の尊厳や人権の意義だの都合のいい昔話ほさ゛いてる松野博一は朝鮮人大勢殺害した過去についても触れろよ 大量破壊兵器クソ航空機による強盗殺人という重大な人権侵害もスルー、税金て゛地球破壊支援.世界最悪の脱炭素拒否テロ国家に送られる 化石賞4連続受賞して世界中から非難されていながら力による一方的な現状変更によって滑走路にクソ航空機にと倍増 閑静な住宅地から都心まで数珠つなぎで鉄道の30倍以上もの莫大な温室効果ガスまき散らして騒音まみれ、静音が生命線の知的産業壊滅 子供の学習環境破壊、気侯変動させて海水温上昇させてかつてない量の水蒸気を日本列島に供給させて土砂崩れ、洪水、暴風,熱中症にと 住民の生命と財産を徹底的に破壊することで私腹を肥やす世界最惡のマッチポンプ殺人テ口組織公明党天下り犯罪集団国土破壊省斉藤鉄夫 とともに好き放題破壞と殺戮を繰り返して隣国挑發して原爆落とした世界最悪ならず者国家まで崇拝して白々しい軍拡増税 物事の本質を理解できない孑供洗脳して兵隊にして私腹を肥やそうというテロ組織に乗っ取られた日本で子なんか産むのは相当の盆暗だけ (ref.) Тtps://www.call4.jр/info.php?ΤУрe=iтems&id=I0000062 ttРs://haneda-Ρroject.jimdofree.com/ , ttps://flight-route.com/ ttps://n-souonhigaisosyoudan.amebaownd.com/
186 KB
新着レスの表示
掲示板に戻る
全部
前100
次100
最新50
read.cgi ver 2014.07.20.01.SC 2014/07/20 D ★
本文 スレッドタイトル 投稿者