MVVMについて語ろう

1 ：2012/06/06 〜 最終レス ：2012/11/02

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

2 ：

関連記事
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 ：

語れるほどニーズあんのか？

4 ：

MVCよりはまし。
でも、MVCすら理解できないのが大半だからなー

5 ：

MVPとMVC混同してる人けっこういるよね

6 ：

UIパターン知らんでMVVM知ろうとしても無理ゲー

7 ：

>>5
実装上の違いだけで本質的には同じもの
そこにこだわるってことは、たぶん本質が分かってないんだろうな

8 ：

語ることあるのか知らんが期待しとく

9 ：

要するにXAMLで開発してれば自動的にMVVMなんでしょ？
開発環境を作ってるのでも無ければ、あんまり純粋主義主義者になる意味は無いと思う。

10 ：

このスレッドは天才pンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

11 ：

MVVMツールがVSに標準装備されてないことか推測するに、MVVMがXAMLUIに必須でないことが判る

12 ：

>>9　自動的にMVVMではない。
>>11　必須ではないが有用。

13 ：

デザインパターンと同じで、フレームワークの名称じゃないからね
自分でフルスクラッチしてもいいんじゃよ？　別にむずかしくないし
でも「mstest？　なにそれおいしいの？」って子は
本来のメリットの半分もえられないからこれまで通りにかけばいいんじゃないの

14 ：

MVVMで実際のDBに繋いでCRUDのサンプルってないね。
DBのあたりはEntity Frameworkでいいの？

15 ：

つか語呂悪い。なんで最後だけ二文字なんだよ。

16 ：

>14
プレゼンテーション層以外はすべてModelなのでどうでもいい話
>15
回文

17 ：

>>15
じゃあ何て略したらいいんだよｗ

18 ：

Mのぶぶんは別になんでもいいお。
そもそもMの部分はVMとのセパレーションさえできていればいわゆるModel的なものですらなくていいと思う。
なんというかViewに関連しないものでありさえするなら、ステートを持つ実体的なものでもサービスとのやり取りをするProxi的なものでもなんでも。
実際のアプリではVMとMが一体化してるようなものもあると思われ。

19 ：

アプリケーションや実装固有の話だからといって、MVVMにおけるMやMVCにおけるMのパターンを語る気が無いなら
「V-VM-VとVM以外パターン」とか「V-C-VとC以外パターン」とか言っておくべきだな。

20 ：

Mはドメインロジックなのでモデルといって問題ない

21 ：

つうか、むしろ話としては、VVMな部分の話よりも、MVVMにおけるMの話の方が語ることは多いと思うが。
VMとして責務を分離する話に、スレを立てるほどの広がりがあるのかなあ？

22 ：

ドメインロジックという言葉が何に対してでも都合良く使われる問題。

23 ：

実装の話とか？

24 ：

>>22
それはすげー思うｗ

25 ：

Mについてはそれなりに構築できるけど、
そこにVを被せるときに毎回苦労するんだなー

26 ：

対象領域の課題を解決するためのモデルの「対象領域」の部分を拡大解釈しすぎなんだよ。
MVVMの文脈で、プレゼンテーションパターン以外の個別のアーキテクチャやパターンとして語るべき物までひっくるめてドメインモデルと言ったり、
ひいては状態を持っているるからドメインモデルです(｀・ω・´)ｷﾘｯ、みたいな事を言っていても、世間一般の同意は得られないと思うけどな。

27 ：

いやいや、MVVMパターンの目的はXAMLアーキテクチャ特有のプレゼンテーションロジックの解決がメインであって、モデルの問題は二の次以下なんだがな

28 ：

だからMについては一切語らない、っていうのは別に良いんだけど、それでそんなに語る事がある？、っていう。
まあ、VMとMの接続パターンについてはまったく語らないわけにはいかないだろうけど。
DBの話が知りたいって言う話が出てくるのも、DB実装固有の話がどうのというのではなくて、VMからサービス層とかへの参照を誰が生成してどう設定するのとか、
サービスロケータ的な部分をどうすべきかを知りたいって事だと思っているけど。

29 ：

それはアプリケーション（Model）の役目だろうよ
V＆VMはむしろ生成される側だと思われ

30 ：

簡単に言えば
V　見た目
M　本処理
VM　接着剤
だろ
MVCと同じようにUI層とその他を分けるときどうするかっていうのをパターンにしてるわけで
UI以外の処理、例えばデータの読み書きがどうこうなんてのはMVVMには関係ない話だな
Modelって名前なんだから何々であるべきなんだ！！１なんて話はナンセンス

31 ：

その「アプリケーション（Model）」っていう言い方も微妙だが…。
生成されたVMがMをどう参照するかは、VM自体の話というよりアプリケーションインフラの話というならそうだけど。
でも、その話すらしないのだとしたら、本当に何の話をするんだ？

32 ：

ザックリ分けると
・DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
・MVVMとしての各画面の作り方の部分
・Prism的にDIやサービスロケータ含めたクライアントアプリとして構造的な部分
って感じかね。

33 ：

>>30で良いなら、それがもう結論じゃん。それ以上なにか言うことがあるの？

34 ：

>>33
>>30の話だけでナイスなWPFアプリが作れるんだったらいいんじゃないの？

35 ：

MVVMの実装に関する話ならいくらでもできるんじゃね

36 ：

むしろそちらの方を知りたいという人間多いんじゃね？
MVVM的に考えるとコマンドはVMに置くべきか否か
コードビハインドとイベントハンドラとVMの関係
コードビハインドはいわゆるプレゼンターか否か
バインディングとMVVMは切り離して考えるべきか否か
MVVMとしてふさわしいVMの実装は
もっと高速にVMを実装する方法はないかとかね

37 ：

あとMVVMツールの良し悪しや使用方法についてとか

38 ：

ビヘイビアってよく聞くけどVMに入るの？

39 ：

>>32みたいな、アプリケーション構造の話をするのはこのスレではあり？、なし？
MVVMフレームワークの実装比較の話は俺も聞きたいな。

40 ：

定義論にまた脱線しない限りまあいいんじゃね

41 ：

>>39
むしろそのためのスレだろ

42 ：

Mっとういか、VVMじゃない部分の話をしだすと荒れる傾向にあるじゃん。
その境界がどこかの確認。

43 ：

>>42
新参者だが、荒れるん？
むしろMVVM作る上で重要なファクターだと思うんだが。

44 ：

Modelって言う言葉が出るだけで、すぐ定義論と決めつけて、プレゼンテーション層以外のどうでもいい話なんです！、な発言が出てくるから。
その一方で、アプリケーション構造部分までModelという言い方をする人も居るので。

45 ：

何度も言うが、MVVMで焦点当てて考えにゃならんのはプレゼンテーション層であって、Modelは二の次だと何度いわせりゃいいんだか
MVVMがXAMLというDSLに極めて特化したパターンだということを考慮せねばならんよ

46 ：

本来VとMだけ分離すればいいのだが、XAMLの場合、バインディングを強く意識した設計になっている。
そこでV〜M間に仲介者を設け、V(XAML)、VM（C#）の二層構造とし、VMにViewの状態とModelのデータを保持させて
V〜VM間をバインディングで通信するのがMVVM。

47 ：

ほらｗ
>>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途
WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。

48 ：

>>45
それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには１も３も必要だろ。

49 ：

＞DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
ってMVVMとどう関係あるの？
洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがｗ

50 ：

>>48
VMとM間の通信は考えなければならんが、M内の構造については別のパターンを導入すべきだろ

51 ：

>>49,50
M内の構造はMVVMとは関係ないよ。
でも実際のアプリを作る上ではどこまでをMとするか、そのMをどういう仕組で作るか、それらとV,VM含めたものを紡ぎ上げるにはどうしたら良いか考えないと出来ないでしょ？
MVVMはあくまでもUIを作る上でのパターンであって、実際のアプリはその他のパターンが組み合わさったもの。

52 ：

>>51
ああ、ごめん。IDが出ないから流れがわかりにくいなこのスレ
>>49は>>47への反論です
>>50も俺だけど>>51と全く同意

53 ：

>>46
そもそもVMはV層でしっかりVとMの分離になってるんじゃないか
Mの設計がVMなしにそのまま使える物であればVMの省略もしばしばみられるし

54 ：

やっぱり、VVM内に閉じた話だけを扱うスレなのか？、MVVMを使用したアプリケーションの構造まで扱うのがOKなスレなのか？、っていう最初に戻るじゃん。
VMとMの繋ぎは考えるなら、サービスロケータあたりの話からがグレーゾーンになってくると思うけど。

55 ：

定義論に発展しない限りどうでもいいと言ったら定義論がヒートアップしてたでござる
定義知りたきゃMVVMでぐぐってろ

56 ：

そもそもMVVMってなに？

57 ：

>>56
>>2

58 ：

Model
アプリケーションのドメイン(問題領域)を担う、そのアプリケーションが扱う領域のデータと手続き（ビジネスロジック - ショッピングの合計額や送料を計算するなど）を表現する要素である。
多くのアプリケーションではデータの格納に永続的な記憶の仕組み（データベースなど）が使われていたり、
サーバが別途存在するアプリケーションではサーバ側との通信ロジックなどが含まれている。
MVVMの概念ではMVCの概念と同様に、データの（UI以外の）入出力は取り扱わないので、強いて言うならばそれらはModelの中に隠蔽されると考えられる
一般的にModelはドメインを担当すると言われるがこの言葉だけをもってModelの役割を想像するのは難しい。
たとえばクライアントサーバモデルのアプリケーションのクライアントアプリケーション側は、そのドメインそのものがプレゼンテーションになっている。
アプリケーションをプレゼンテーションとドメインに分けて考えようとした際にはこの事が混乱の一因となっている。
Modelの役割は、後述するViewとViewModelの役割以外の部分と考えるのが妥当である。

59 ：

MVVMの定義自体は、みんなさほど異なる認識を持っているとは思わんが。
それをわかった上で、アプリケーション固有の話が出てくるのをわかった上でアプリケーション構造の話をするか、しないかについて話てるだけじゃね？

60 ：

>>58
それってU氏の記述だろ？

61 ：

わかりにくいからMVVMをガンダムでたとえて

62 ：

>>54
そこまで細分化しても意味ないと思うから、自分はぜんぶ含めていいと思うの(´・ω・｀)

63 ：

>>61
M=ララァ
VM=サイコミュ
V=ビット

64 ：

>>63
なんとなくこれ思い出した
http://d.hatena.ne.jp/hilapon/20120426/1335411488

65 ：

スレのあり方を議論するだけで終わりそうだｗ

66 ：

おまえが勝手に思ってるだけだろ

67 ：

質問です。
ButtonクリックしてViewModelからWindowクローズしたいんだけど、ViewModel側にはどう書いたらいいのでしょうか？

68 ：

ウィンドウを閉じる動作はViewで完結しているものなんじゃないでしょうか

69 ：

ウィンドウサイズ保存したい

70 ：

>68
そうなんですか？わかりました...(´･ω･`)

71 ：

>>69
コードビハインドで実装すればいいよ

72 ：

>>68
未保存のデータがあるときだけ確認メッセージを表示とか、Viewだけじゃ完結しないだろ。

73 ：

LivetのMessengerクラス使えば、ViewModelからWindow閉じたり最大化・最小化を操作できる
http://d.hatena.ne.jp/hilapon/20111108/1320728308

74 ：

よし分かった、俺がこれがコードビハインドだって
お手本のプログラムを作って見せてやるよ。

75 ：

>>73
他のMVVMツールにも同様の機能はありますか？

76 ：

>>75
その部分だけパチってくればいいじゃん。

77 ：

ugaya40さん、MVVMの本書いてよ。

78 ：

彼は文書よりもLivetのチュートリアルの優先度をあげるべきだろ。

79 ：

チュートリアルないと使えないか？
サンプルなら探せばそれなりにあると思うけど

80 ：

使える使えないという話ではなく、広くアピールしたいならそういう地味な作業の優先度の方が高いんじゃないの、という話。

81 ：

ugaya40さんって誰？と思ってこれを読んだけど
http://ugaya40.net/wpf/mvvm-mvc-mvp-pm-eventdriven.html
MVPとPresentation Modelの認識がおかしいな
まぁ全体として意味は通じるけど…

82 ：

ところで、これってMVCとどう違うの？
MVCのときとMとVも当然違うと思うんだけど。

83 ：

u氏の言っていることは、VVMや実装の話についてはほぼ同意だしすごいとも思っているけど。
ただ、そこからMよりの話やもっと大きな構造の話になってくると、言っていることが微妙というか、
言おうとしていることはわかるけど、他の人の同意は得られないだろうな、っと思うことが多いかな。

84 ：

Livet使ってるけど2chの名無しに返信しないで欲しい、とだけ言っておきたい

85 ：

Livetネタは荒れるからやめろ。
本人に直接聞け。

86 ：

>>77
そんなニッチ層向けの本書いても売れないだろ

87 ：

MVVMってどれがええの？
Livetがオススメ？

88 ：

mvvmlight

89 ：

それはプログラミングにどの言語がいいのかと聞くようなもので
PrismもLivetもMVVMLightもどれも一長一短だからな
人に聞けばたぶんバラバラに返ってくるだろうから
一度使ってみて使いやすいのを判断したほうが早い

90 ：

>>81
どの辺が認識おかしいの？

91 ：

>>89
そういうんでは、その一長一短を聞きたいんだろ。
ぜんぶ試すってのはなかなか難しい。

92 ：

>>86
いや、結構売れるかも知れんぞ。

93 ：

VMへのサービス層のDIってどうやるべきものなの？
それ以前に、VMとMを繋ぐ方法として、VMにサービス層をインジェクションする、っていう考え方はあってる？

94 ：

>>93
時と場合によるんだろうけど、そうするとMでやるべきのがぜんぶVMに来ない？

95 ：

>>94
自分が想定したのは以下の様なサービスファサードがあったとして。
interface HogeServeiceFacade
{
IE<Foo> GetFooList();
}
HogeServeiceFacadeの実装の中では、外部サービスにアクセスしたり、ドメインモデルによる処理をしたり。
HogeServeiceFacade自体はバッチやWebでも使うものだとして。
ここがファサードになるので、それ以上Mの処理がVMに来ることは無いと思っているんだけど。
っで、このHogeServeiceFacadeとVMを接続する方法にコンテナ/サービスロケータを使う場合に
どうするのかとか？、それって考え方としてそもそもあっているの？、っていうのを聞きたかった。

96 ：

>>95
そういうんではありなんじゃない？
そもそもMVVMは大本はViewとMの分離があって、それにさらに薄いVMいれると更にセパレーションで来て良いよねって話だから。
で、ロケータ使う場合色々あるけど既存の使うか自前で作るかじゃない。
薄いやつなら実質ただのKeyValueで出来るだろうし、それで結構まかなえると思われ。Prismとかはその辺も実装されてる。DIがより良くインテグレートされてる。他は知らん。

97 ：

コンバータ(IValueConverterを実装したクラス)はMVVMのどの層に属するものなの？

98 ：

>>97
View

99 ：

コンバータ自体簡易VMみたいなもんじゃね？

100 ：

>>97
それを分類することに何か意味があるの？

101 ：

コンバータ、StringFormat、VMでの詰め替え等が混在していると保守性が悪くなりそうだ

102 ：

VMでなんでも出来はするるが、責務としてVMでやるのはデータ構造の変換までにして、色だの文字だのの修飾はコンバーターでやるべきだろう。

103 ：

自分はコンバータも形式の変換で、修飾なりなんなりはViewにやらせるな

104 ：

おまえらユニットテストには何使ってるの

105 ：

>>96
Thx
考え方としてはありか。
Prismにはその辺の仕組みもあるのね。
じゃあ、各フレームワークでそういう機構を持っているものについて、該当クラス名とかを知っている人がいたら教えて下さい(*・ω・)*_ _)ﾍﾟｺﾘ
後は自分で調べるので。

106 ：

>>104
NUnit

107 ：

MVCとかMVPとかのパターンを判りやすく解説してる本あったら教えて

108 ：

>>104
俺もNUnit。

109 ：

上のご神託を読んでこい。

110 ：

>>109
いや、MVVMの前提となるMVCやMVPについて知りたいんだが
やっぱファウラー先生あたりの本になるのかな？

111 ：

偉い先生が書いたものとか読んだことないわー
MVCとかなにかのパターン本に乗ってたけどネットで探れるのと大差ない。
MSDNでMVPVMの説明してるやつでMVC,MVP説明してるのあったお

112 ：

MVCではクライアントはC(イベントハンドラ、リスナー、コールバック)に
アクセスしてVがレスポンスとして帰ってくるのに対し、
MVVMはクライアントがVにアクセスしてVが帰ってくる感じだな。
HTMLならステートレスなMVCが、Viewがクライアント内にある
ステートフルなappletとかsilverlight、デスクトップGUIならMVVMが良さそうだ。

113 ：

MVCについて知りたいならSmalltalkを調べろ。
WebのMVC(2)ならむしろRESTってキーワードで調べろ。
MVVM自体に関する本は知らん。
そしてそれとは関係無しに、PoEAAなんかも読んでおくべき。
PoEAAだけ読んで、ドメインモデルvsトランザクションスクリプト厨になったりする奴も多いけどな。

114 ：

そろそろ電子書籍で売ってくれ

115 ：

>>113
MVCってSmalltalkコミュニティから提唱されたのか

116 ：

たしか。
オブジェクト指向の元祖たるSmalktalkで発展したものだと効いた希ガス

117 ：

良スレの予感。

118 ：

やっぱりVMのライフサイクル管理やVMへのインジェクションを行うサービスロケータはあっても良いよな。
アプリケーションの構造によっては別にいらないだろうけど。

119 ：

複数ViewModel間の呼び出しってどうすべき？

120 ：

public string Name
{
　 get { return Model.Name; }
　 set { Model.Name = value; }
}
こういう感じで VM で M のプロパティを V に伝えるためだけの
プロパティってなんていうの？

121 ：

ごめん、knockout.js の話題はここで良い？

122 ：

>>120
NotifyPropertyChanged使わないなら直接Modelのプロパティにバインドしてよくね

123 ：

>>122
難読化でいちばん隠したい部分がまる見えになるからオススメできない
プロパティ多すぎて書きたくねぇ！ってならＴ４

124 ：

難読化か。難読化なら確かにラッピングは必要かもしれんが
internalなViewModelじゃだめなん？

125 ：

ラムダ式からプロパティ名を取り出す方法なら難読化できるよ

126 ：

ああXAMLには影響が出るから無理か
インターフェイスが曝されるだけなら別によくない?
VMでラップしまくるのも大差ないと思うが

127 ：

まあ全部ラッピングしたらしたでやっぱり中身の名前はそのまま出てくるわけだしな
それなら直接Model繋げた方がいい

128 ：

ふむ。
ttp://www.mnow.jp/LinkClick.aspx?fileticket=U%2b2U8DNLxfs%3d&tabid=220&mid=867
確かにナビゲーションなんかは、MessengerやBehaivorで解決できはするんだけど、
VVMの責務としてどうなのかとか、MVVMというよりもBlend至上主義になりすぎているのではと思うことはあって。
何かしら別の層があっても良いと感じてはいたが。
それをPと呼ぶかどうかはともかく。

129 ：

世の中にはコードビハインドというものがあってだな

130 ：

コードで書くかと、コードをどこに書くかは全然違う話であってだな

131 ：

ところでVS2012のデザイナはBlendベースで刷新されて前と比べ物にならないくらい良くなってるぞ
アニメーションやテンプレートやリソースの編集にはBlendがまだ必要だけど
MVVMのV作るときにはそろそろBlendいらないと思う

132 ：

>>121 のやつ
http://en.m.wikipedia.org/wiki/KnockoutJS
http://knockoutjs.com/
SilverlightとKnockoutJSの比較
http://www.codeproject.com/Articles/365120/KnockoutJS-vs-Silverlight

133 ：

コマンドもバインディングできて、シンプルなテンプレートも付いてるのはいいな。
なかなか使いやすそうな感じだね。これは確かにMVVMだ。
質問とかだったらWeb制作板のライブラリ質問スレが適当かな。

134 ：

WebはWebでもJSはクライアント側でUIを扱うからMVVMなんだな

135 ：

VS2012になると ビュー モデルは Portable Library でサポートされるそうだ、VM と M は可能な限り Portable Library に押し込んでマルチプラットフォーム化を目指せるのか。

136 ：

VMが厚くなるな

137 ：

MetroとWPFでVM使い回しはきついだろ
ギャップが大きすぎるから、大量のコードビハインドでVMを相当抽象化することになるか
互換性のためにどっちつかずでプラットフォームの空気を読まない不自然なUIになりそう

138 ：

Portable Libraryは別に良いんだけど、別にVMのマルチプラットフォーム対応を目指す必要は無いと思うんだよね。
使用するビューのテクノロジーやデバイスが異なればVMに求められる構造だって変わってくるし。
WebのMVCでPCサイトとモバイルサイトで同じControllerを使う、程度には面倒で制約が多い気がする。
むしろマルチプラットフォーム化できるんならしたいのはMじゃね？

139 ：

Livet で、Winodws.Loaded 時にコマンド発行させたいんだが、どうすればいいの？
WindowAction みたいなので、コマンドを発行するだけの Action があればいいだんけど、
見つからなかった。
自分で作るしかない？

140 ：

>>139
i:EventTrigger
i:InvokeCommandAction

141 ：

Portable Library に Model を押し込む努力はするべきだ。
Portable Library に押し込むには ViewModel は View にプロパティを提供するだけにせざる負えない。
と書いてどっかで聞いたなと思ったら。 MVPVMパターンあった。
Portable Library に ViewModel と Model を押し込んで View と Presennter をプラットフォーム依存にするのか。

142 ：

で、そのPresenterってコードビハインドじゃん、ってなった

143 ：

状況によってはPresenter設けてもいいと思う
Viewのサイズや表示位置、グリッドのソート順や列の表示・非表示等を構成ファイルに保存/読み込みさせるのに独立したPresenter設けても可

144 ：

Presenterの役割定義が昔に比べて広いものを指すようになってきている気がするのは俺だけ？
IHogeViewを実装しているビューなら、それがWPFだろうがWindows FormsだろうがConsoleアプリだろうが、
HogePresenterから操作できる、みたいなのがMVPのイメージだったんだけど、
コードを書く = Presenterな使われ方が増えている気がするんだけど、MVPってそういうものだったの？
ビュー間にまたがるものやアプリケーション横断的な処理の記述箇所については、
Presenterといわずに別の定義をした方が良いんじゃねと思ったんだけど。

145 ：

>>140
ありがとう。
Livet 関係なくできたのか、
ぐぐっても出ないわけだ・・・。

146 ：

>>142
V->VMが密結合にならないのがコードビハインドとは違うところ
実際やるかどうかは別にしてVMの差し替えが可能

147 ：

NVPVMはあくまでMVVMの派生パターン
特殊なコンポーネント使っててViewの負荷が異常に高い場合、有効なパターンだよ

148 ：

じゃぁViewにプロパティを提供する入力検証の一部をする以外の、
VMでやっていることを考えてみよう。
非常にめんどくさいコーディングスタイルのコントローラじゃないのか？

149 ：

それでいいんだろ
一つのViewを異なる使い方で使いまわすときに
VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う

150 ：

>>149
> 一つのViewを異なる使い方で使いまわすときに
> VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
え？
一つのViewModelを異なるアーキテクチャで使いまわすときに
Viewごと入れ替えるのは無駄が多いから
の間違いじゃね？

151 ：

MVPVMのサンプルも、VM−Mのコンビは汎用性持たせ、Pで差分吸収するサンプルに思えたが

152 ：

両方だろ
VがVM、VMとビジネスロジックがそれぞれ密結合しないことでVとVMの再利用性を高めるのがねらい

153 ：

こういう意見もありますが
ttps://gist.github.com/2041069

154 ：

2chの煽りと変わらんだろw
ugayaはこういう説明の仕方を見習うべき
www.global-webnet.net/blogengine/post/2010/02/05/MVPVM-Model-View-Presenter-View-Model-the-natural-evolution.aspx

155 ：

VがVMに密結合してしまってるのが問題だといってたぞ。
U氏も遷移を切り離すならしっくりくると書いてある。
VMから遷移を切り離したら何が残るの？
Viewにプロパティを提供する入力検証の一部をする位じゃないの？

156 ：

>>155
VがVMに密結合するのはコードビハインドな
それをPに切り出してPを差し替え可能にしてるから密結合しない

157 ：

Viewで相互運用使うならMVPVM有りとの話もあるが、実際作業するとコードビハインドしか逃げようがないんだよなぁ〜

158 ：

コードビハインドってPじゃねえの？

159 ：

質問。
VMの第一の目的って、Mの構造をVでバインディングしやすい形に変換した形で持つ事っていうのであってる？
例えば、DBの2次元表の構造を、複雑なViewにバインディングするためLINQで変換する、とか。
なので、Mの構造そのままを表示するようなVだと、VMは単純なラッパに見えてしまう。

160 ：

Mの構造そのまま表示できる場合においてはVMは不要

161 ：

実際に作ってみりゃわかるけど
純粋にＭのプロパティだけでインターフェースは作れない
タブやエキスパンダの状態とか環境設定とかの話ね
めんどくせぇから全部詰め込むってのもありだけど
無駄に一緒にするのは保守性を悪くする
どうせそこらへんはほとんどラッパなんだから
書くのがめんどくさい部分は全部Ｔ４使えとＴ４

162 ：

T4使いづらいって印象しかないんだが、なんか間違ってる？

163 ：

外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ
複数ファイルの処理が面倒なのはわかるが

164 ：

>>162
俺も同じ印象だ。
結局MsBuildタスクで、
http://d.hatena.ne.jp/okazuki/20110116/1295166605
の様な属性からコードを生成するようにしたよ。

165 ：

どうもこうも
ViewModelBase<T>から派生してたら
partialでTのプロパティを全部ラップしてやればいいのさ
簡単だろ？
Ｔ４で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら
調べろとしかいいようがないが

166 ：

リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね

167 ：

> Ｔ４で自分のプロジェクトからリフレクション
このあたりは、みんなどの方法を採用してる気か聞いてみたいね。
俺はWPFのコンパイルプロセスを見習って、
自分自身を一度ビルドしてからCecilでアセンブリにアクセスしてる。
他にも
Cecilではなく普通のリフレクションAPIを使ったり、
ビルドせずにRoslynやNRefactoryを使ったりという方法もあるけど
こっちを使ってる人もいるのかな？

168 ：

>>166
アセンブリがアンロードできない・・・と来れば、あとはわかるな？
そう、AppDomainの出番だ。

169 ：

>>168
おい、やめろ
AppDomain芸をよりにもよってT4でとか地獄過ぎる
RoslynはまだCTPだしT4上で現実的なところで言えばCecilだろうな
コード生成じゃなくてポストプロセスでのIL書き換えでよければPostSharpなんかも選択肢に入るが

170 ：

うん、AppDomainは無い
まだ別プロセスを起動した方がマシ

171 ：

PostSharpとか使ってやるのがお手軽？
自前でTaskを作ってビルドプロセスに追加する方が良い？

172 ：

一番手軽なのは某氏のDSL

173 ：

Castle.DynamicProxyでいいわ
コード生成だるい

174 ：

>>172
えむなうさんの？あれってC#専用だよね？

175 ：

T4使ったら、少なくともテンプレートのコードが
コンパイルされた結果のアセンブリはロードされるはずだろ
だからもともと別AppDomainで実行されるようになってるから
普通にロードして問題ないんじゃないの?

176 ：

>>174
VB.NETやF#とか茨の道だし、C#で普通に使えれば問題ないだろ？

177 ：

必要ならVB作れってCodePlexかBlogでリクエストすればいい。
まさかJavaScriptやF#じゃないよな。

178 ：

リフレクションでやるんならわかるけど、いちいちDSLでプロパティ定義するんだったら
public virtual int Hoge { get; set; }
としといてCastleのDynamicProxyで変更通知を自動実装させればいいと思うよ

179 ：

>>176
VB.NETは茨の道でもなんでもないんだが？

180 ：

>>178
プロパティ追加・Hoge・int の3ステップでできる。
赤シャツの嫌いなAOPで実装することもあるまい。

181 ：

VB続けたい奴がXAMLに手を付けるのが不思議だわ

182 ：

>>181
それは偏見。いまのVBはC#と比べて大差ない程機能強化されとる

183 ：

>>176
むしろすべてF#で作りたいんだが。
VMまではF#でやってる。

184 ：

MS自身はVBにも力を入れてるけど、周りが付いてきていない。
サンプルがC#でのみ提供ってのもよく見るし、
MonoはVBコンパイラを非サポートにしつつあるし。

185 ：

F#は面白そうだね。
計算式で上手くリアクティブプログラミングができたら
相当VMが作りやすくなりそうな予感がする。
けど、茨の道には違いないだろう。
IDEの支援は弱いし、ライブラリの中にはC#の文法で使うことが前提のようなものもあるし。

186 ：

VBにいくら機能を追加しても言語仕様が腐ってるから駄目だよ
それにどうせ新機能が増えるたびに「冗長な予約語導入→C#より利便性が下がる」って悪循環でしょ

187 ：

VBのラムダ式とか狂った文法だし、機能面だけはC#と対等にしてるけど、もはやボロボロでしょ

188 ：

言語がどうの以前に、MVVM的インフラとして
他人のコードが重要になるから少数派は厳しい

189 ：

>>186
予約語増えるたびIDEが支援強化するからあまり不便に感じないのも事実
XAML開発の場合、IDEがどれだけその言語をサポートしているかが最重要
そういう意味でF#は終わってるとしかいいようがない

190 ：

VBはVB2005のように、厨言語と呼ばれてもいいから
VBらしさを重視していた頃のほうが健全だった
C#のクローンに成り下がったVBに存在意義はもう無い

191 ：

>C#のクローンに成り下がったVBに存在意義はもう無い
そんなことばかり言うからC#厨は嫌われるんだよ
おまえが存在意義感じなくても俺には必要なの！引っこんでろタコ！

192 ：

VBはクラシックVBとの互換性を維持したいのかしたくないのかよくわからないはじまり方をしたのが最大の失敗だったな
せっかくのしがらみを捨てる最大のチャンスを逃してしまった

193 ：

>>191
でもまぁ今から.Net始める場合はVB.NetじゃなくてC#選ぶんちゃう？

194 ：

>>192
言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい
とはいえVB６との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない

195 ：

>>193
VB.NETに移行する案件、山ほどあるんだが

196 ：

VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな

197 ：

>>196
でしょｗ　でも変にForms覚えてる奴より
「こ　れ　が　.NET　じ　ゃ　定　番　だ　か　ら」
と言えば、素直に話を聞いてくれるのから嬉しい

198 ：

Forms直に行ってデフォルトインスタンス触られるよりいいのか

199 ：

>>194
開発に使う分には問題ないが、言語チームがかなり苦労してそうなのが構文とかからにじみ出てくるぜ・・・

200 ：

VB（.NETじゃない方）も未だに元気だからなぁ
PHPがじわじわ下がってきてVBと逆転してしまった。
今はまだ一時的な物だけど今後数ヵ月かけて順位が入れ替わりそうだとか何とか。
http://www.tiobe.com/index.php/content/paperinfo/tpci/

201 ：

実はMVVMってしっくりこないんです！
わたしはこれまで、C/C++、Visual Basic、最近になって Java、C# などの言語を使ってきた。
「自分でViewModelを作ってMVVMっぽいことをしている」なんてことはまったくない。
特に「Visual Studioでポトペタ開発ができる」ということ知ってからは、従来のVB6のように開発している。
共有変数も、pubulic staticで宣言する。したがってプロパティなんて作らない。
自称上級者のコードを見ると、いちいちM・V・VMのクラス分けをしているので笑ってしまう。
データベースにアクセスするアプリケーションをを書いているのだが、Visual Studioが供給している
機能を使えばMVVMなど使わなくてもできてしまうのだから。

202 ：

なにおじさん？

203 ：

何のコピペだっけそれ

204 ：

懐かしいなｗ

205 ：

オブジェクト指向か

206 ：

VMのコストが高いのは事実

207 ：

Livet で Drag and Drop やりたいんだけど、どこかにサンプルないですか？

208 ：

時間の無駄だと思わないの?
お前がMVVM教の修験者か何かでないならコードビハインドを使え

209 ：

Dropイベントを処理したいだけなら>>139-140

210 ：

イベントだけ拾っても仕方ないでしょ
素直にコードビハインドを書くか、
Dropイベントを受け取って引数にデータ入れてバインドしたVMのコマンドを呼ぶ
ビヘイビアを作りましょう

211 ：

MVVMって誰が提唱しだしたの？

212 ：

MSの中の人

213 ：

ビヘイビアに書くと再利用性が上がるってだけで中身はコードビハインドと大して変わらんしな
まあD&Dはどっちにしても面倒だが

214 ：

コードビハインド書くと、VからVMアクセスするでしょ？
それがかっこ悪いのよね〜

215 ：

VからVMにアクセスするのはコマンドも一緒だと思うが…

216 ：

つーかほぼすべてVからVMへのアクセスだろが。

217 ：

VMはVを知らないがVはVMを知っている

218 ：

こんにちは！VMさん。
あなたは、Vさんにフォローされてます。
Vさんをフォローしますか？
　する
→しない

219 ：

MVCのCとMVVMのVMって何が違うの？
データを扱うMと画面を扱うVがいて、それらを制御するCでしょ？
VMもCもいっしょじゃん。

220 ：

>>219
ASP.NET MVCを想像してみろよ
あれはCとVMの両方を持つが、どう見ても同じものじゃないだろ

221 ：

>>220
それが理解できていれば聞かずに済んでいるんだ、無能ですまん。

222 ：

VMってのは、Vから扱いやすいインターフェイスを備えたMのラッパーだよ
Vを制御したりなんかしない

223 ：

Vを制御するのは誰？
簡単な話、Viewにある文字をModelでなんかした結果で変えたいみたいな。

224 ：

V自身がバインディングで変える

225 ：

MVCだとVは入力を扱わない

226 ：

Mの状態でフォーカス位置を変えたりするのがめんどい

227 ：

SとMの関係を一言で言うと？

228 ：

rot(M, -π) = S

229 ：

Vを制御するのはVMだろ
Vの状態を持つためのMなんだから

230 ：

VMがVを制御しないんならVを制御する別のオブジェクトが必要だな
そうだなープレゼンターとかいう名前にするといいんじゃね？

231 ：

「MVVMパターンで学ぶGUIアーキテクチャパターン」? .NETラボ勉強会で話してきました！
http://ugaya40.net/architecture/mvvm_to_mvc.html

232 ：

Mのプロパティをラップすることがあるのは、MVVM関係なく、隣人とだけ話せっていうOOPの作法だよな
MVVM的には別にどっちでもよくて、やっぱりVMの本質はVの状態を持つことだよ

233 ：

従来のウェブアプリ（Ajaxアプリ除く）、
ウェブフレームワークといったらいいかな？
で、MVVMを使うメリットある？

234 ：

JSのか？

235 ：

JS関係なくて、普通のフォーム使った
ウェブアプリ。

236 ：

数ある既存の素晴らしいMVC系フレームワーク(あくまでWebでいうMVCね)
に乗せられるというメリットを捨ててまで使うほどのメリットは無いと思う

237 ：

ASP.NET MVCにはViewModelと呼ばれるものがあるけど
ステートレスでただVと1対1なだけのデータの入れ物だからMVVMとは別物だと思う

238 ：

MVVMはVが入力を扱う場合において威力を発揮する
WebのサーバサイドだとVは入力を扱わないし、MVCはVではなくCが入力を扱う

239 ：

あと選択状態とかだろ
ステートレスなVMはただのMだ

240 ：

そもそもウェブアプリってMVCじゃないだろ？
データとってきてテンプレートに入れるだけじゃん。

241 ：

何を突然スレ違いなことを

242 ：

>>233でウェブアプリの話してるじゃん。
ちゃんと読まないでレスするの良くないよ。

243 ：

ここはMVCのスレではないし、クライアントとWebのMVCが同一だと言ってる奴も居ないけど

244 ：

このスレの1/10には
MVCという単語が含まれているが？
MVCのスレじゃなくても
MVCと比較するのだからなんの問題もないだろ。

245 ：

コミュ障って生きていくの大変そうだな。

246 ：

そうだな。そういうことにしておけば？

247 ：

そこはもちょっと親身に相談に乗ってあげなきゃ
245が自殺でもしたら大変だろ

248 ：

ちょっと死にたい

249 ：

コードビハインドさえ書かなければ死なない

250 ：

いや、別に責務さえはっきりしていれば、別にコードビハインド書いてもいいんだよ。
MVVM≠コードビハインドはよくある誤解なので、ご注意を。

251 ：

>>250が≠の意味を誤解しているのは分かった

252 ：

LivetってPrismにあるようなナビゲーションスタイルのアプリケーションには対応してないよね
アホみたいに時間かかってる割には全体的に…

253 ：

お前は何を言っているんだ

254 ：

>>253
ウインドウ内で画面遷移するやつ(PrismのRegionみたいなの)
できるなら教えてほしい

255 ：

個人製作のフレームワークがごく限られたケースにしか対応してないのはよくあること
配慮してくれないと

256 ：

ContentControlでも使ってろ

257 ：

Livetの中の人、ついったーがキモい・・・

258 ：

WebMVC
http://d.hatena.ne.jp/yojik/touch/20091019/1255963600

259 ：

>>153みたいなことしちゃうアレな人だからな

260 ：

いやなら反論してみればいいんじゃね

261 ：

例の人は目先の細かい実装に囚われすぎなんだよ
>>154で説明されているような
・VMをビジネスロジックに依存させないことによるVMの再利用性の向上
・VをVMに依存させない(つまりVMを直接触るようなコードビハインドを書かない)ことによるVの再利用性の向上
・Pは差し替え可能
・DIとの相性
と言ったことに全く触れられていない

262 ：

直接言って来いよ
ここでやんな

263 ：

技術的な話はここでいいだろ。
性格批判は向こうでどうぞ。

264 ：

そうそう、そのためのスレなんだから
MVPVMのサンプル見ると、三つのプラットホームでVMを共通化してる
VとVMの疎結合のためにPを設けてるわけだが、
現実的に考えると、VMの共通化を図る要件って実際あり得るのだろうか？

265 ：

>>154のリンク先の例にあるような、同じV-VMペアを別の用途で使いまわすっていうのは
割とあるんじゃないかと思う

266 ：

VMの共通化は無い派。
デバイスが変われば見た目も変えたくなるし、全てのデバイスで使えるスーパーセットのVMもどうかと思う。
Mが可能な限り共有できればそれでよいと思う。

267 ：

要件によるけど、スーパーセットのVM使えるところも多々あるんじゃない？
使えないところだけVMを個別作るとかが望ましいなぁ

268 ：

最近客に「文字大きくしてくれ」って言われてVだけコピペしたよ

269 ：

ねぇ。これがどうウェブアプリに使えるの？

270 ：

ステートフルなGUIを作るためのものだからサーバーがHTML吐くだけのアプリには無意味
SilverlightやAjaxなら普通に使える

271 ：

うがやって彼女いるの？
24時間キモイことつぶやいてるよね 。
さっきも、アスペルガー丸出しだった。
彼女どころか友達いなそう。

272 ：

個人攻撃に走るのはいかがなものか。

273 ：

>>272
今Twitter見てみ？
完全にアスペだぜ？

274 ：

何言ってるのかはみてないが24/7ではなかったな
日付が飛んでたから

275 ：

技術的な突込みならともかく、スレに関係ない話で個人攻撃はいくない

276 ：

個人の話がしたければヲチ板へ。
アスペの話がしたければメンヘラ板へ。

277 ：

ウガヤ氏に罵倒された勘違いMVVMerなんですね。わかります(´・ω・｀)

278 ：

あれも２ちゃんでの話に文句があるなら２ちゃんでいえばいいのにな

279 ：

煽り耐性ゼロだから2ch無理とか言ってたけど
正直あのエントリに比べたらここやWPFスレの方がマイルドw

280 ：

いやさすがにそれはない

281 ：

ム板は煽られても他人の振りが出来るからなあ

282 ：

ここってJavaFXの話題もあり？

283 ：

ありじゃね

284 ：

JavaFXが最初に世に出た当時はなんでXMLじゃなくてわざわざ独自スクリプトなんだ
ボケカスと言われてたが、デザイナとプログラマの分業なんて幻想であって
ある程度ビューに振る舞い書けた方が便利だということを見越した判断だったんだな
XAMLのビヘイビア地獄よりははるかにマシだわ

285 ：

今FXやるぐらいならSLでいいわ

286 ：

ビヘイビア地獄ってなんだよ
そんなに地獄に感じるならコードビハインドにコード書いたっていいんだぞ

287 ：

.triggerを手で書くのはうぜぇっていうのは同意するが
あれはblendで書く物だろ

288 ：

ビヘイビアもトリガーもｲﾝﾌﾗが整った環境じゃないとまともに使えん
自力で整えようとすると相応の労力が強いられる
遊びや自己学習でする分には良いけど、サクッと作りたいときや仕事だと２の足を踏むなー
Blendみたいな環境が無いと本気で使おうとは思わない
コードビハインドでもMVVM自体は可能だから手っ取り早く作りたいときはコードビハインドで良いだろ

289 ：

MVVMってプラガブルMVC劣化させたのと同じじゃねぇの？
プラガブルMVC劣化版と何が違うの？

290 ：

XAMLのこと知らないなら黙ってろ

291 ：

非同期処理ってモデルでSynchronizationContextとか使って面倒見たほうがいい?
それともやっぱりモデルの状態が複雑になるのは避けてVMでスレッド動かす?

292 ：

ポリシー次第じゃない？
モデルまではそのへんを気にせずガンガン使う→VMで考慮
VMはシンプルに作りたい→上で考慮
自分は前者だな。

293 ：

モデルで非同期してVMではメインスレッドが普通じゃない？
ViewからVM呼ぶんだし

294 ：

UIにアクセスするとことか内部の状態を変えるとかだけVMでContextで同期取ればいいやん

295 ：

DIコンテナは何がいい?
UnityとNinjectとAutofac試してAutofacが気に入ったんだけど

296 ：

>>290
なんの関係が？

297 ：

Livetの新しいの公開されたけど、これ、
旧バージョンインストールして作ってたアプリある場合、
新しいLivet入れても問題ないのかな?
旧バージョンのままじゃないと動かなくなるとかだと困る

298 ：

Livetのプロジェクトテンプレート使ったんならLivet.dllのローカルコピーがあるべ。

299 ：

それだと古い方のdllも残しておかないといけないってこと?
新しい方に差し替えたらそのまま動かないのかな…
新しいPCにVisualStudioとLivetの新しいのだけ入れたら、
旧バージョンで作ったアプリの修正とかはできなくなる?
上書きインストールしていいのかとか、
そこら辺、公式サイトに何も書いてないから怖くて入れられない

300 ：

>>299
ここに書くよりも直接連絡しろよｗ

301 ：

Livetのテンプレート使って作ったプロジェクトならInfrastructureAssembliesフォルダにいままでのLivet.dllはそのままあるし
参照設定もそれを参照しているから自分で明示的に置き換えない限り新しいバージョンのLivetを入れてもそいつのバージョンはそのまま
自分でProgram FilesにあるLivet.dllに参照設定してたらアップデートしたらアップデートしたバージョンのものになる
また新しいものに差し替えたとしても破壊的変更があるものはそのままでは動かないし、特定バージョン参照してたらたとえ破壊的変更がなくともリビルドが必要
Livetに限らずライブラリ使うときの基本的なことだと思うが

302 ：

>>300
諸般の事情で直接連絡したくない場合もあるんだよ
そのための2chだろうが

303 ：

んなわけねーだろ
捨てアカで報告してこい

304 ：

MVVMerなら即VS2012にするよな？

305 ：

それはあんまり関係ないな

306 ：

MVVMerとかフルMVVMとか、日本だけの造語が目立つな

307 ：

2012というか.NET4.5だとXP切り捨てになるのが

308 ：

>>307
です。
VB6ランタイムはWin8でも動くと言うのに酷い話だ。

309 ：

MVVMはWindows7以降用技術です

310 ：

いいえ、ウェブ技術(JavaScript)です。
http://ameblo.jp/ca-1pixel/entry-11298459074.html
knockout.js (http://knockoutjs.com/)
knockout.jsはMVVM（Model-View-ViewModel）パターンのフレームワークです。
双方向データバインディングやアイテムテンプレート等の機能があり、SilverlightやWPF開発者にはかなりとっつきやすいフレームワークだと思います。

311 ：

Win8でも動作するし、VB6でのMVVMまだ？

312 ：

パターンにまだ？って言われても
自分でやることじゃねーのか

313 ：

vb6でも普通にMVVMできるだろう
Observerやビヘイビア作るのが難儀な気がするからコードビハインド主体になりそうだけど

314 ：

おまいら、なにか根本的に勘違いしてるだろ

315 ：

誰に言ってんの
何を言ってんの

316 ：

MVVMの定義に相当するものはVB6ではできんだろ。
MVPも厳しい。
おとなしく、モジュール分割をちゃんとした昔ながらのC/Sシステムっぽくやっていろ。
…っという話かな？

317 ：

クラスをちゃんと定義すりゃできるだろ
ライブラリで用意されてるインフラ全部自分で作らにゃならんけど

318 ：

VB6の仕様だけでインフラ作るのは厳しくないかね？
いや、API使ってフックレベルからやれば、そりゃ出来るだろうけど

319 ：

MVVMのどういう場面だ？

320 ：

VBだとクラスモジュールから
イベント送信できるんだから
MVVMは実装しやすい方法言語だよ。

321 ：

可能性とかで語られてもな。
実際にそれを VB6 でやる気になるかい？ って話も重要だろ

322 ：

「VB6　を　やる気にならない」が正解

323 ：

VBってまだ絶滅してないのか
何のためにMSはC#出したんだ

324 ：

MSほど多様な製品を長期に渡ってサポートしてくれるとこは他にない。
VB6が世に出てから14年経つがWin8でも公式にサポートされた。
リプレースするにも金がかかるから動く限りは保守しながら使いたいって客は案外多いよ。

325 ：

そういう用途ならhost側で動かなくてもVMで動いてくれりゃ充分なんだが

326 ：

VB早く消えてなくならないかなー
MSもサクッと切ればいいのに

327 ：

リプレースに金がかかるかもしれないが保守にも金がかかる

328 ：

案外金が掛かった方が良いのかも知れない
払ってくれる相手なら

329 ：

VB6からC#へのリプレースおいしいです

330 ：

んで MVVMでアプリつくってるやついるの？？？
まじでいらねぇんだが．

331 ：

一つの画面でいろいろやるタイプのアプリには向かないのは事実

332 ：

一つの画面で色々やるというか、Vの作り込みの比重が多いアプリだとあんま活躍しないわな。

333 ：

ツール類には向かんわな
せいぜい複雑なダイアログがあればそこに使う程度

334 ：

複雑なウィンドウなら複数のコントロールに分割すればいい話じゃね

335 ：

メモリリークする原因がわからない

336 ：

イベント

337 ：

>>335
メモリを使っている人がいるんじゃないかな

338 ：

徐々にウェブの世界でも
MVVMが浸透してきたな。
MVCだけじゃ、いろいろ足りない。

339 ：

>>335
こういうのでは？
https://www.google.co.jp/search?q=mvvm+メモリーリーク&ie=UTF-8&oe=UTF-8&hl=ja

340 ：

>>338
Ajaxとかだるすぎ
WebはサーバーでHTMLを垂れ流すだけという低脳さが良いのに

341 ：

>>340
テンプレート使ったこと無いの？
サーバーでテンプレートに渡す値を
値そのまま渡せばそれがAjaxになる。
サーバーサイドアプリ - テンプレート処理
なのだから、確実にAjaxの方が簡単になってる。；

342 ：

意味がわからない
テンプレートって普通サーバーで使うもんだろ? クライアント側でテンプレート使うってこと?
それがサーバーでやるより簡単だと言える根拠は?

343 ：

どっちも簡単だろ。
jQueryみたいなライブラリが充実してきて笑えるぐらい簡単になった。
これが難しいってム板に居られる資質がないとしか思えん。

344 ：

>>342
サーバの負荷の関係上、サーバでテンプレートエンジン使わない方がいいとかもあるんだけど、
最近は、サーバから戻ってくるのはJSONオブジェクトとテンプレートで、クライアントでテンプレート
エンジンかましてページを生成する方が良いような気がしてるよ。基本Ajaxで。
受けとったJSONオブジェクトを元に、自力でDOMを書き換えても良いし。

345 ：

クライアントが以前より負荷が高くなるという問題もあるけれど、
以前というのはもう十数年前だったら問題になるというレベルで
今はクライアントは十分な性能を持ってるしね。
ブラウザ自体も速くなった。
それに比べるとネットワークはまだまだ遅いわけで、
テンプレートはローカルにキャッシュしておいて
データ量を減らすほうが得策かな。
サーバー負荷も低くなるし。
これぐらいだれでも思っていることで、
普通サーバーでやるもんだろで終わってる人ってのは
何も考えてないとしか思えないけどｗ

346 ：

一方Twitterは以前API直接たたいてJSONからDOM生成してたのが最近生成済みのhtml片を鯖から受け取るようになった

347 ：

完全なAjaxができるならいいが、
普通そうはいかないもんな
どうせサーバーで生成しなきゃいけないならなるべくサーバーにまとめちゃった方が楽

348 ：

どっちみちAjaxは使わないといけないんだから
クライアントにまとめちゃったほうが楽

349 ：

Ajaxはオプションだろ
利便性のためにクライアントでAjax使ってバリデーションしたとしても、
どのみちサーバーでもやらないといけない

350 ：

Ajaxはバリデーション以外で使うものって
わからないのか？ｗ
バリデーションなら単なるJavaScriptで良い

351 ：

>>350
JavaScriptでもいちいちバリデーションするの？
バカ？

352 ：

JavaScriptでバリデーションが通ったら
サーバーでは検証せずにそのままDBに入れちゃうの?
やばくねそれ

353 ：

話し理解できてないの？ｗ
バリデーションをAjaxで行う＝サーバーで通信して行うから、
そのバリデーションはサーバーでやってる事になるだろうって話だ。
あと、サーバーでやらないなんて一言も言ってない。
なんでこんなに文章読めないの？馬鹿なの？

354 ：

サーバとJavaScript両方でバリデーションするの？
マジキチ？

355 ：

>Ajaxはバリデーション以外で使うもの
>バリデーションなら単なるJavaScriptで良い
さっきと言ってることが180度違うけど

356 ：

うーん？
> Ajaxはオプションだろ
>>349が
オプションでやるって書いてあるじゃん。
みんな最初っから、両方でやるという前提で話してるんだが。
両方でやるのは、レスポンスを早くしてユーザビリティを上げ
無駄な通信を削減するため。言わなくても常識だと思っているが。

357 ：

>>355
そりゃ、さっき言った人俺は別人だからねｗ

358 ：

みんなって誰？
マジキチは一人で十分なんだがｗ

359 ：

>>358
みんな＝お前以外

360 ：

ああ、別人という設定なんですね、わかります

361 ：

鯖とJS両方で検証するだろうよ
検証はカスタム属性から自動生成でもしたらいいってかそういうのすでにある

362 ：

一人だけ、程度の低い人が居ますね

363 ：

>>362
自己紹介は結構です

364 ：

今時Ajaxだるいと言って済ませられるような、簡単なお仕事をしているぬるま湯な環境うらやましす
コストをかけずにAjaxやJSでのMVVMをどう実現するか試行錯誤している人が多い中で

365 ：

×今時Ajax
○いまさらAjax

366 ：

クライアントにまとめるとか言って鯖から全件投げつけてクライアント側で検索やらせる奴とかが現れませんように

367 ：

>>366
それはさすがに見た事ないけど
ページングせずに数万件の検索結果のレコードを送り付けてくるやつなら見た事がある。

368 ：

そのうちJavaScriptでクラサバやるわけですね

369 ：

node.js最強

370 ：

>>366
ASP.NET素人だとクライアント側にViewStateで全データを保管して、サーバー側でページングとか日常茶飯事だぜ？

371 ：

まーた、なんか低レベルの流れになってんなー

372 ：

下見てもつまらないよ

373 ：

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 ：

なんか最近尾上の言うことがぶれすぎ
先月ぐらいから少しずつさりげなくぶれ始めてたんだが
なにがあったんだ？
コードビハインドとか頭おかしくなったのか？
その内容自体は宗教だからどうでもいいが
さんざん自分の考えと違うやつを罵倒してきた人間が
そこまでころっと価値観変えてどうなんだ？

375 ：

コードビハインドを無理に排除しようとすると、どうしても
特定のビュー専用のビヘイビアがしばしば出てくる。
その場合無駄に煩雑になるだけで実質何のメリットもない。
彼も気付いちゃったんだよ。

376 ：

単に自分の考えが甘かった、自分の見える世界だけしか見ていなかった事に気がついただけだろ。
ああいうキャラの人間はだいたいそんなもん。

377 ：

MVVMやっててWPFの仕組みがわかってくると、
意外とWPFのコードビハインドってよくできてることに気付くよね
正直、ビヘイビアは再利用できるものだけに限定して積極的にコードビハインド使うのがベストだと思う

378 ：

メッセージも多くの場合Vがインターフェイスを実装すれば十分
ﾒﾓﾘﾘｰｸｶﾞｰとか言うけど、そんな大したことじゃないだろ。
参照管理の問題なんてどうせWPF関係ないところでも常に付きまとうのに、
それをコードビハインドの問題であるかのように大袈裟に騒いで、
WPFがまだよくわかってない人に変な先入観を植え付けている。

379 ：

MVVMというより、Blend至上主義みたいな話になっちゃってるような所があったからな。

380 ：

本人はBlendを第一に考えてるようだしその辺だろうな

381 ：

Blend 2012まだかよ

382 ：

ViewModelのインターフェイスって意味ある？

383 ：

Mや各種サービスからのコールバックに使うとか
コードビハインドでVからVMのメソッドを呼ぶときにV->VMを密結合させたくないとか
そういうときには意味ある

384 ：2012/11/02

まあ通常は継承ベースでいいと思う