MVVMについて語ろう

■ このスレッドは過去ログ倉庫に格納されています
2012/06/06(水) 11:03:33.21
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
2012/06/09(土) 16:03:19.03
難読化か。難読化なら確かにラッピングは必要かもしれんが
internalなViewModelじゃだめなん？
2012/06/09(土) 22:58:26.63
ラムダ式からプロパティ名を取り出す方法なら難読化できるよ
126125
垢版 |
2012/06/09(土) 23:02:50.05
ああXAMLには影響が出るから無理か
インターフェイスが曝されるだけなら別によくない?
VMでラップしまくるのも大差ないと思うが
2012/06/10(日) 02:20:40.65
まあ全部ラッピングしたらしたでやっぱり中身の名前はそのまま出てくるわけだしな
それなら直接Model繋げた方がいい
2012/06/10(日) 19:31:10.74
ふむ。
ttp://www.mnow.jp/LinkClick.aspx?fileticket=U%2b2U8DNLxfs%3d&tabid=220&mid=867

確かにナビゲーションなんかは、MessengerやBehaivorで解決できはするんだけど、
VVMの責務としてどうなのかとか、MVVMというよりもBlend至上主義になりすぎているのではと思うことはあって。

何かしら別の層があっても良いと感じてはいたが。
それをPと呼ぶかどうかはともかく。
2012/06/10(日) 19:42:58.13
世の中にはコードビハインドというものがあってだな
2012/06/10(日) 20:08:46.96
コードで書くかと、コードをどこに書くかは全然違う話であってだな
2012/06/10(日) 20:22:58.07
ところでVS2012のデザイナはBlendベースで刷新されて前と比べ物にならないくらい良くなってるぞ
アニメーションやテンプレートやリソースの編集にはBlendがまだ必要だけど
MVVMのV作るときにはそろそろBlendいらないと思う
2012/06/11(月) 07:53:21.15
>>121 のやつ
http://en.m.wikipedia.org/wiki/KnockoutJS
http://knockoutjs.com/

SilverlightとKnockoutJSの比較
http://www.codeproject.com/Articles/365120/KnockoutJS-vs-Silverlight
2012/06/11(月) 09:04:31.43
コマンドもバインディングできて、シンプルなテンプレートも付いてるのはいいな。
なかなか使いやすそうな感じだね。これは確かにMVVMだ。

質問とかだったらWeb制作板のライブラリ質問スレが適当かな。
2012/06/11(月) 09:12:27.73
WebはWebでもJSはクライアント側でUIを扱うからMVVMなんだな
2012/06/12(火) 01:28:10.49
VS2012になると ビュー モデルは Portable Library でサポートされるそうだ、VM と M は可能な限り Portable Library に押し込んでマルチプラットフォーム化を目指せるのか。
2012/06/12(火) 02:06:46.27
VMが厚くなるな
2012/06/12(火) 02:23:38.61
MetroとWPFでVM使い回しはきついだろ
ギャップが大きすぎるから、大量のコードビハインドでVMを相当抽象化することになるか
互換性のためにどっちつかずでプラットフォームの空気を読まない不自然なUIになりそう
2012/06/12(火) 07:04:36.86
Portable Libraryは別に良いんだけど、別にVMのマルチプラットフォーム対応を目指す必要は無いと思うんだよね。
使用するビューのテクノロジーやデバイスが異なればVMに求められる構造だって変わってくるし。

WebのMVCでPCサイトとモバイルサイトで同じControllerを使う、程度には面倒で制約が多い気がする。

むしろマルチプラットフォーム化できるんならしたいのはMじゃね？
2012/06/12(火) 12:49:34.16
Livet で、Winodws.Loaded 時にコマンド発行させたいんだが、どうすればいいの？
WindowAction みたいなので、コマンドを発行するだけの Action があればいいだんけど、
見つからなかった。
自分で作るしかない？
2012/06/12(火) 13:12:31.77
>>139
i:EventTrigger
i:InvokeCommandAction
2012/06/12(火) 16:51:30.23
Portable Library に Model を押し込む努力はするべきだ。
Portable Library に押し込むには ViewModel は View にプロパティを提供するだけにせざる負えない。
と書いてどっかで聞いたなと思ったら。 MVPVMパターンあった。

Portable Library に ViewModel と Model を押し込んで View と Presennter をプラットフォーム依存にするのか。
2012/06/12(火) 17:21:46.72
で、そのPresenterってコードビハインドじゃん、ってなった
2012/06/12(火) 18:36:18.33
状況によってはPresenter設けてもいいと思う
Viewのサイズや表示位置、グリッドのソート順や列の表示・非表示等を構成ファイルに保存/読み込みさせるのに独立したPresenter設けても可
2012/06/12(火) 20:43:19.56
Presenterの役割定義が昔に比べて広いものを指すようになってきている気がするのは俺だけ？

IHogeViewを実装しているビューなら、それがWPFだろうがWindows FormsだろうがConsoleアプリだろうが、
HogePresenterから操作できる、みたいなのがMVPのイメージだったんだけど、
コードを書く = Presenterな使われ方が増えている気がするんだけど、MVPってそういうものだったの？

ビュー間にまたがるものやアプリケーション横断的な処理の記述箇所については、
Presenterといわずに別の定義をした方が良いんじゃねと思ったんだけど。
145139
垢版 |
2012/06/12(火) 22:17:28.41
>>140
ありがとう。
Livet 関係なくできたのか、
ぐぐっても出ないわけだ・・・。
2012/06/13(水) 02:37:56.25
>>142
V->VMが密結合にならないのがコードビハインドとは違うところ
実際やるかどうかは別にしてVMの差し替えが可能
2012/06/13(水) 10:57:45.00
NVPVMはあくまでMVVMの派生パターン
特殊なコンポーネント使っててViewの負荷が異常に高い場合、有効なパターンだよ
2012/06/13(水) 12:44:02.37
じゃぁViewにプロパティを提供する入力検証の一部をする以外の、
VMでやっていることを考えてみよう。

非常にめんどくさいコーディングスタイルのコントローラじゃないのか？
2012/06/13(水) 13:12:22.81
それでいいんだろ
一つのViewを異なる使い方で使いまわすときに
VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う
2012/06/13(水) 13:19:04.84
>>149
> 一つのViewを異なる使い方で使いまわすときに
> VMごと入れ替えるのは無駄が多いからっていうのが元々のアイデアだと思う

え？

一つのViewModelを異なるアーキテクチャで使いまわすときに
Viewごと入れ替えるのは無駄が多いから

の間違いじゃね？
2012/06/13(水) 13:21:02.28
MVPVMのサンプルも、VM−Mのコンビは汎用性持たせ、Pで差分吸収するサンプルに思えたが
2012/06/13(水) 13:26:43.72
両方だろ
VがVM、VMとビジネスロジックがそれぞれ密結合しないことでVとVMの再利用性を高めるのがねらい
2012/06/13(水) 13:30:43.53
こういう意見もありますが
ttps://gist.github.com/2041069
2012/06/13(水) 13:37:22.90
2chの煽りと変わらんだろw
ugayaはこういう説明の仕方を見習うべき
www.global-webnet.net/blogengine/post/2010/02/05/MVPVM-Model-View-Presenter-View-Model-the-natural-evolution.aspx
2012/06/13(水) 13:40:07.82
VがVMに密結合してしまってるのが問題だといってたぞ。
U氏も遷移を切り離すならしっくりくると書いてある。

VMから遷移を切り離したら何が残るの？
Viewにプロパティを提供する入力検証の一部をする位じゃないの？
2012/06/13(水) 13:46:36.47
>>155
VがVMに密結合するのはコードビハインドな
それをPに切り出してPを差し替え可能にしてるから密結合しない
2012/06/13(水) 13:47:19.86
Viewで相互運用使うならMVPVM有りとの話もあるが、実際作業するとコードビハインドしか逃げようがないんだよなぁ〜
2012/06/13(水) 13:49:10.29
コードビハインドってPじゃねえの？
2012/06/13(水) 15:20:15.29
質問。
VMの第一の目的って、Mの構造をVでバインディングしやすい形に変換した形で持つ事っていうのであってる？

例えば、DBの2次元表の構造を、複雑なViewにバインディングするためLINQで変換する、とか。
なので、Mの構造そのままを表示するようなVだと、VMは単純なラッパに見えてしまう。
2012/06/13(水) 15:27:06.16
Mの構造そのまま表示できる場合においてはVMは不要
2012/06/13(水) 15:45:57.26
実際に作ってみりゃわかるけど
純粋にＭのプロパティだけでインターフェースは作れない
タブやエキスパンダの状態とか環境設定とかの話ね

めんどくせぇから全部詰め込むってのもありだけど
無駄に一緒にするのは保守性を悪くする

どうせそこらへんはほとんどラッパなんだから
書くのがめんどくさい部分は全部Ｔ４使えとＴ４
2012/06/13(水) 15:51:40.10
T4使いづらいって印象しかないんだが、なんか間違ってる？
2012/06/13(水) 15:57:40.49
外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ
複数ファイルの処理が面倒なのはわかるが
2012/06/13(水) 16:36:31.97
>>162
俺も同じ印象だ。

結局MsBuildタスクで、
http://d.hatena.ne.jp/okazuki/20110116/1295166605
の様な属性からコードを生成するようにしたよ。
2012/06/13(水) 17:01:14.95
どうもこうも

ViewModelBase<T>から派生してたら
partialでTのプロパティを全部ラップしてやればいいのさ
簡単だろ？

Ｔ４で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら
調べろとしかいいようがないが
2012/06/13(水) 17:10:39.16
リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね
2012/06/13(水) 17:23:42.40
> Ｔ４で自分のプロジェクトからリフレクション
このあたりは、みんなどの方法を採用してる気か聞いてみたいね。

俺はWPFのコンパイルプロセスを見習って、
自分自身を一度ビルドしてからCecilでアセンブリにアクセスしてる。

他にも
Cecilではなく普通のリフレクションAPIを使ったり、
ビルドせずにRoslynやNRefactoryを使ったりという方法もあるけど
こっちを使ってる人もいるのかな？
2012/06/13(水) 17:36:11.05
>>166
アセンブリがアンロードできない・・・と来れば、あとはわかるな？

そう、AppDomainの出番だ。
2012/06/13(水) 17:39:54.72
>>168
おい、やめろ
AppDomain芸をよりにもよってT4でとか地獄過ぎる

RoslynはまだCTPだしT4上で現実的なところで言えばCecilだろうな
コード生成じゃなくてポストプロセスでのIL書き換えでよければPostSharpなんかも選択肢に入るが
2012/06/13(水) 18:07:49.37
うん、AppDomainは無い

まだ別プロセスを起動した方がマシ
2012/06/13(水) 20:42:48.42
PostSharpとか使ってやるのがお手軽？
自前でTaskを作ってビルドプロセスに追加する方が良い？
2012/06/13(水) 21:09:57.27
一番手軽なのは某氏のDSL
2012/06/13(水) 21:11:07.57
Castle.DynamicProxyでいいわ
コード生成だるい
2012/06/13(水) 23:33:29.53
>>172
えむなうさんの？あれってC#専用だよね？
2012/06/13(水) 23:47:53.09
T4使ったら、少なくともテンプレートのコードが
コンパイルされた結果のアセンブリはロードされるはずだろ
だからもともと別AppDomainで実行されるようになってるから
普通にロードして問題ないんじゃないの?
2012/06/13(水) 23:50:14.79
>>174
VB.NETやF#とか茨の道だし、C#で普通に使えれば問題ないだろ？
2012/06/13(水) 23:51:37.83
必要ならVB作れってCodePlexかBlogでリクエストすればいい。
まさかJavaScriptやF#じゃないよな。
2012/06/14(木) 00:07:25.99
リフレクションでやるんならわかるけど、いちいちDSLでプロパティ定義するんだったら
public virtual int Hoge { get; set; }
としといてCastleのDynamicProxyで変更通知を自動実装させればいいと思うよ
2012/06/14(木) 00:14:39.91
>>176
VB.NETは茨の道でもなんでもないんだが？
2012/06/14(木) 00:16:41.28
>>178
プロパティ追加・Hoge・int の3ステップでできる。
赤シャツの嫌いなAOPで実装することもあるまい。
2012/06/14(木) 01:42:25.17
VB続けたい奴がXAMLに手を付けるのが不思議だわ
2012/06/14(木) 08:06:59.93
>>181
それは偏見。いまのVBはC#と比べて大差ない程機能強化されとる
2012/06/14(木) 09:14:33.85
>>176
むしろすべてF#で作りたいんだが。
VMまではF#でやってる。
2012/06/14(木) 13:20:58.33
MS自身はVBにも力を入れてるけど、周りが付いてきていない。

サンプルがC#でのみ提供ってのもよく見るし、
MonoはVBコンパイラを非サポートにしつつあるし。
2012/06/14(木) 13:24:58.84
F#は面白そうだね。

計算式で上手くリアクティブプログラミングができたら
相当VMが作りやすくなりそうな予感がする。

けど、茨の道には違いないだろう。
IDEの支援は弱いし、ライブラリの中にはC#の文法で使うことが前提のようなものもあるし。
2012/06/14(木) 20:01:18.03
VBにいくら機能を追加しても言語仕様が腐ってるから駄目だよ
それにどうせ新機能が増えるたびに「冗長な予約語導入→C#より利便性が下がる」って悪循環でしょ
2012/06/15(金) 01:35:08.89
VBのラムダ式とか狂った文法だし、機能面だけはC#と対等にしてるけど、もはやボロボロでしょ
2012/06/15(金) 10:44:01.68
言語がどうの以前に、MVVM的インフラとして
他人のコードが重要になるから少数派は厳しい
2012/06/15(金) 11:55:14.41
>>186
予約語増えるたびIDEが支援強化するからあまり不便に感じないのも事実
XAML開発の場合、IDEがどれだけその言語をサポートしているかが最重要
そういう意味でF#は終わってるとしかいいようがない
2012/06/15(金) 13:19:16.42
VBはVB2005のように、厨言語と呼ばれてもいいから
VBらしさを重視していた頃のほうが健全だった
C#のクローンに成り下がったVBに存在意義はもう無い
2012/06/15(金) 13:53:34.63
>C#のクローンに成り下がったVBに存在意義はもう無い

そんなことばかり言うからC#厨は嫌われるんだよ
おまえが存在意義感じなくても俺には必要なの！引っこんでろタコ！
2012/06/15(金) 13:55:47.35
VBはクラシックVBとの互換性を維持したいのかしたくないのかよくわからないはじまり方をしたのが最大の失敗だったな
せっかくのしがらみを捨てる最大のチャンスを逃してしまった
2012/06/15(金) 13:56:55.90
>>191
でもまぁ今から.Net始める場合はVB.NetじゃなくてC#選ぶんちゃう？
2012/06/15(金) 13:59:50.60
>>192
言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい
とはいえVB６との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない
2012/06/15(金) 14:00:50.13
>>193
VB.NETに移行する案件、山ほどあるんだが
2012/06/15(金) 14:37:26.30
VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな
2012/06/15(金) 14:51:15.90
>>196
でしょｗ　でも変にForms覚えてる奴より

「こ　れ　が　.NET　じ　ゃ　定　番　だ　か　ら」

と言えば、素直に話を聞いてくれるのから嬉しい
2012/06/15(金) 14:59:21.72
Forms直に行ってデフォルトインスタンス触られるよりいいのか
2012/06/15(金) 15:15:25.52
>>194
開発に使う分には問題ないが、言語チームがかなり苦労してそうなのが構文とかからにじみ出てくるぜ・・・
2012/06/16(土) 04:16:43.61
VB（.NETじゃない方）も未だに元気だからなぁ
PHPがじわじわ下がってきてVBと逆転してしまった。
今はまだ一時的な物だけど今後数ヵ月かけて順位が入れ替わりそうだとか何とか。
http://www.tiobe.com/index.php/content/paperinfo/tpci/
2012/06/16(土) 12:32:05.90
実はMVVMってしっくりこないんです！

わたしはこれまで、C/C++、Visual Basic、最近になって Java、C# などの言語を使ってきた。
「自分でViewModelを作ってMVVMっぽいことをしている」なんてことはまったくない。

特に「Visual Studioでポトペタ開発ができる」ということ知ってからは、従来のVB6のように開発している。

共有変数も、pubulic staticで宣言する。したがってプロパティなんて作らない。

自称上級者のコードを見ると、いちいちM・V・VMのクラス分けをしているので笑ってしまう。

データベースにアクセスするアプリケーションをを書いているのだが、Visual Studioが供給している
機能を使えばMVVMなど使わなくてもできてしまうのだから。
2012/06/16(土) 12:40:31.71
なにおじさん？
2012/06/16(土) 13:20:33.52
何のコピペだっけそれ
2012/06/16(土) 14:14:46.22
懐かしいなｗ
2012/06/16(土) 17:03:22.48
オブジェクト指向か
2012/06/16(土) 17:52:59.93
VMのコストが高いのは事実
2012/06/16(土) 23:27:28.75
Livet で Drag and Drop やりたいんだけど、どこかにサンプルないですか？
2012/06/17(日) 11:27:52.39
時間の無駄だと思わないの?
お前がMVVM教の修験者か何かでないならコードビハインドを使え
2012/06/17(日) 14:45:06.19
Dropイベントを処理したいだけなら>>139-140
2012/06/17(日) 16:08:05.74
イベントだけ拾っても仕方ないでしょ
素直にコードビハインドを書くか、
Dropイベントを受け取って引数にデータ入れてバインドしたVMのコマンドを呼ぶ
ビヘイビアを作りましょう
2012/06/21(木) 18:57:52.75
MVVMって誰が提唱しだしたの？
2012/06/21(木) 19:34:30.00
MSの中の人
2012/06/21(木) 19:36:38.56
ビヘイビアに書くと再利用性が上がるってだけで中身はコードビハインドと大して変わらんしな
まあD&Dはどっちにしても面倒だが
2012/06/21(木) 22:54:05.30
コードビハインド書くと、VからVMアクセスするでしょ？
それがかっこ悪いのよね〜
2012/06/22(金) 23:26:34.40
VからVMにアクセスするのはコマンドも一緒だと思うが…
2012/06/23(土) 07:54:12.87
つーかほぼすべてVからVMへのアクセスだろが。
2012/06/23(土) 09:25:51.09
VMはVを知らないがVはVMを知っている
2012/06/23(土) 11:10:17.65
こんにちは！VMさん。
あなたは、Vさんにフォローされてます。

Vさんをフォローしますか？
　する
→しない
2012/06/23(土) 11:29:14.41
MVCのCとMVVMのVMって何が違うの？
データを扱うMと画面を扱うVがいて、それらを制御するCでしょ？
VMもCもいっしょじゃん。
2012/06/23(土) 15:06:23.66
>>219
ASP.NET MVCを想像してみろよ

あれはCとVMの両方を持つが、どう見ても同じものじゃないだろ
2012/06/23(土) 15:13:22.96
>>220
それが理解できていれば聞かずに済んでいるんだ、無能ですまん。
2012/06/23(土) 15:30:26.15
VMってのは、Vから扱いやすいインターフェイスを備えたMのラッパーだよ
Vを制御したりなんかしない
2012/06/23(土) 15:57:05.63
Vを制御するのは誰？
簡単な話、Viewにある文字をModelでなんかした結果で変えたいみたいな。
2012/06/23(土) 16:02:41.88
V自身がバインディングで変える
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況