MVVMについて語ろう

■ このスレッドは過去ログ倉庫に格納されています
2012/06/06(水) 11:03:33.21
WPF/Silverlight/WinRT開発の必須技術、MVVMについて語ろうではないか！
2012/11/15(木) 10:53:44.15
>>442
そんなことでリークするわけない。動的に生成された要素は、XAMLでイベントハンドラが登録されたままでも
ツリーから外れた時点でGC対象になる。XAMLではなくコードビハインドなどから追加した場合は当然
WPF管理外のため、イベントハンドラによる強参照が当然残るのでそれがマズい場合があるだけ。
つまりWPF自身の問題などでは決してなく、あくまで愚かな人間によるミス。
例の宗教はあえてそのあたりをぼかす(信者の多くはそもそも理解してないまま復唱してるだけだろうが)
ことによって恣意的なイメージ操作を行っている。
2012/11/15(木) 10:57:08.02
そもそもWindow自体を解放する手段ないだろ
449447
垢版 |
2012/11/15(木) 11:01:14.57
ItemsTemplate/DataTemplateの中のコントロールのイベントに対して
コードビハインドのイベントハンドラを登録したときの話な
試してみたら分かるが、要素を削除した後にGCが走れば
ちゃんとコントロールのファイナライザが呼び出される。
2012/11/15(木) 11:25:23.41
メッセージに応答してダイアログを開いたりする汎用的なビヘイビアって本当に必要?
VMからダイアログ開きたいんだったら、IoCでVMからIOpenFileDialogServiceのような
インターフェイスを通してメソッドを呼び出せばいいだけの話だと思うんだけど。
わざわざメッセージ投げてVで処理するなんて複雑だしXAMLも無駄に汚れるしタイプセーフじゃないし。
特定のビューでしか使わないようなサービスにするまでもない処理ならメッセージもアリだと思うけど
その場合ビヘイビアにする意味はなく(再利用しないんだから)、コードビハインドで受けて処理すればいい話だよな。
2012/11/15(木) 17:05:54.35
テスト
2012/11/15(木) 20:05:32.67
行き過ぎたBlend主義。
俺もサービスにするかな。
2012/11/15(木) 22:36:46.09
VMからのメッセージでアニメーションを開始させたいときなんかにはビヘイビアが便利かも
と思ったけどそんなビューの細かいことをVMで意識するのも本末転倒な気がするな
そこはメッセージとXAMLは直接繋がないと割り切った方がいいのかも
2012/11/15(木) 22:46:23.39
俺はビヘイビアで済ませたほうが楽かな
2012/11/15(木) 22:52:24.24
Livet教のMVVM…ドカタMVVM
IoC使うPrism系のMVVM…JavaっぽいMVVM
2012/11/15(木) 23:15:07.41
MVVM Light…光のMVVM
2012/11/17(土) 00:05:50.69
よく話にでるlivetってライブラリ落としてみたけどクラス名にまでlivetって入ってんのね。
ダサすぎる。
2012/11/17(土) 00:08:09.15
てゆーか、9割以上がPrismとMVVM light toolkitのパクリコードってのはどうなの？
Ugayaはずいぶんえらそーなことを言ってたがただのパクリライブラリじゃんか。
2012/11/17(土) 06:32:58.08
そうだなC#はJavaのパクリだもんな

つーかソース見たことはないが本当にパクリなら大問題だしそれならここで言ってないで大々的に批判すればいいんじゃないか
2012/11/17(土) 09:52:41.30
>>459
見ればわかるがおおざっぱに言えばLivetの独自部分でメソッドキャッシュとT4コンバーターぐらいじゃね？


C#っつーか.NET Frameworkだろ
1.0のころはパクリだったんじゃないの？
実際Javaがなければ今と同じ1.0は生まれてなかった
2012/11/17(土) 10:11:39.47
なんだコード盗用とかじゃなくて概念の話だったのか
2012/11/17(土) 11:07:14.48
>>461
>>458はコードと言ってるな
2012/11/17(土) 12:09:36.74
>>461
綺麗に言えば、車輪の再発明？
ぱくりライブラリと言われても仕方がない代物ではある
何を目的にやってるのか分からないところもあるし

インフラを乱立させたって混乱するだけだし
ドキュメントやサンプル充実させて裾野を広げるってわけでもないし
尾上が自身の狂った思想から少しでもずれてる意見を発見すると
死ぬまで粘着されるしな

尾上は自分が日本での唯一のMVVM啓蒙者になるために
他人がおいそれと語れないようにしてるだけ

完全に癌でしかない
2012/11/17(土) 12:14:26.42
MVVMの土台として画面遷移は極めて重要だと思うが、そこがいい加減なのはいただけない
同期ダイアログによる遷移のみってWinFormsかよw WinRTじゃそんなもん使えないぞ?
2012/11/17(土) 12:30:02.96
>>464
MVVMはMSが本気で取り組まない限り無理。
言語、.NET Framework、IDEが三位一体で対応しないと今はまだ欠陥が多すぎる。
2012/11/17(土) 12:38:05.90
>>465
WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
IDEでどうするもんでもないだろう
Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
2012/11/17(土) 13:33:39.79
U氏に親殺されたやつ多すぎだろ
2012/11/17(土) 14:04:28.46
>>467
叩かれてる奴に「氏」付けるのは本人だけ
ってだいぶ前に小学生の妹が言ってたよ。
2012/11/17(土) 14:08:17.71
画面遷移についてはMVVMと絡めてもっと真剣に議論されるべきだと思うぞ?
U氏関係なく。自称MVVMインフラではたいてい完全スルーされてるが(Livetでもおまけ程度)
どうしてもインフラ的なコードを書くことになる部分だし、MVVM使ってるなら画面遷移の設計も
それに強く影響されることになる。
2012/11/17(土) 14:08:19.65
>>466
> WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
WPFの話じゃなくてMVVMな
> IDEでどうするもんでもないだろう
IDEにどれだけ恩恵受けてるかわかってないの？
MVVMだってフレームワークだけではどうにもならないことがある
> Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
Prismがもっと使いやすく標準で.NET Fxに乗らないと無理ってこと
2012/11/17(土) 14:44:14.95
コードビハインド前提のMVVMフレームワークが出てきたら少しは前進すると思う。
Livetがダメなのは作者がコードビハインド完全否定してることと
>>458が言う通り、既存フレームワークの単なる2番煎じで
MVVMの問題点を克服するものではないから。

コードビハインドいいと思うんだけどな。
うがやのサイト見ていると分業とか書いてるが
Vをデザイナーに別注してるチームってあるのか。
デザイナーとデベロッパーの分業なんて幻想じゃないのかな。
XAMLをフルに理解してるデザイナーなんて一人もいないと思うよ。
2012/11/17(土) 14:57:27.23
>>471
その点に関してはすでに奴は考え改めてコードビハインドの有無はどうでもよくなってるみたいだぞ
2012/11/17(土) 15:03:53.77
VMの処理中にユーザの入力を求めたくなった場合とかかね画面遷移は
ぶっちゃけどのライブラリも何かあるたびにクラスやらインターフェイスやら増やさないとならなかったりして面倒だわ
MSはMVVMを推奨するんならASP.NET MVCくらい充実させるべき
2012/11/17(土) 16:41:52.99
>>473
そういう遷移はビューだけで完結するのでほとんどMVVM関係ない。
ビューの実装の詳細だ。
設計に大きく影響するのはVMごと遷移するやつな。
2012/11/17(土) 17:27:45.79
具体的な例で言ってくれよ
2012/11/17(土) 17:34:46.35
例も何も、無理にVMくつけなきゃ 一覧画面 <-> 編集画面 とか大概の画面遷移はVMごと遷移だろ
ダイアログベースならそんなに意識しないだろうけどさ
2012/11/17(土) 17:43:10.77
それならDataContextにVM突っ込んでもらうだけでよくね
2012/11/17(土) 17:54:24.04
そのコードをどこに書くのかとかいろいろ問題があるよ
本来、一覧画面VMで　画面遷移しろ("編集ビュー", selectedItemId); だけで済むはずで
一覧画面のVMやVが遷移先の画面のVやVMのクラスを知っている必要は全くないけど
そう書けるようにするためには結局インフラがいるんだよね
2012/11/17(土) 18:03:52.82
railsのscaffoldみたいにサクッとアプリを作れるようなインフラが欲しい・・・
2012/11/17(土) 19:28:02.12
>>472
どうでもいいわけないよね？
氏のMVVMサイト見てくれば。
2012/11/17(土) 20:46:12.52
プロ粘着なら奴のツイッターも観察すべき
2012/11/17(土) 23:51:38.42
>>481
前はフォローしてたんだけどね。
自分とちょっとでも意見が違うと噛みついて粘着のパターンが多すぎて
ずいぶん前にフォロー解除したよ。
あの人ちょっとアスペ入ってるよね。
ちょっとというかかなり。
高卒で会社員経験なし、ってとこで人間の底が知れるわ。
483デフォルトの名無しさん
垢版 |
2012/11/18(日) 00:01:26.49
と２ちゃんねるで批判するガキｗｗｗ
2012/11/18(日) 00:03:44.32
>>483
ugayaの負けず嫌いもここまで来ると褒めたくなるなｗ
せっかく社会人になれたんだから2chで自演擁護とかやめたら？ｗｗｗｗｗ
2012/11/18(日) 00:09:01.67
>>484
まともな社会人は多少の煽りには反応しねーんだよ
お前みたいな無職のクズとは違うんだよ
分かったらとっとと寝ろ
2012/11/18(日) 00:11:32.55
ugayaは2chの煽りにtwitterやブログでキレまくってたけどなw
2012/11/18(日) 00:17:22.53
>>486
いいから早く寝ろよ
2012/11/18(日) 00:20:54.13
反応はしてたけど別にキレまくってたってほどじゃなかったろ
2012/11/18(日) 00:24:44.54
MVPVMの(Uによる)煽りはひどかった
2012/11/18(日) 01:06:10.42
お前ら本当に暇なんだな
文句があるなら一度でいいからGoogleの検索トップになってみろよ
U氏のサイトはMVVMで検索すると余裕でトップなんだが
2012/11/18(日) 01:10:17.68
そんなんだと宗教に騙されるぞ
U氏も言ってるだろ? 「MVVMだからこうしなければならない」じゃなくて目的を考えろと
2012/11/18(日) 01:14:55.07
>>491
自分の考えた最強の目的しか許さず
その目的を達成するにはこうするしかないと決めつける
そこから外れたツイートを見つけると相手が黙るまで粘着ツイート
相手が黙ると「都合が悪くなると無視かよ、これだからクズは困る」的なツイートで〆

尾上さんのそこにシビれる！あこがれるゥ！
2012/11/18(日) 01:15:09.27
目的を考えろと言ってる本人が一番権威主義を煽ってる元凶という皮肉
2012/11/18(日) 01:19:48.67
尾上を擁護してるのはいったい誰なの？
誰がどう見てもアスペルガーじゃん。

尾上にへこへこ媚び売って家畜に成り下がってる奴って
高野将かぐらばくぐらいなもんだろ？
2012/11/18(日) 01:40:50.56
相手を擁護と認定してしまえばどんな誇大を使って過激に叩いても正当化できて安心だもんな
2012/11/18(日) 01:49:36.48
文句があるなら同じMVVMの土俵で反論すればいいじゃないか。
このスレに持論を垂れ流すだけでも人格攻撃よりはマシだしまともな議論なら歓迎だぞ。
考え方に関してはここはわりとU氏に反発してる人が多いみたいだし(俺もその一人だが)。
497デフォルトの名無しさん
垢版 |
2012/11/18(日) 07:01:25.21
MVVMの思想に関してはいい加減多少は理解したから、
そろそろMVVMの実装について語って欲しいなぁ、
498デフォルトの名無しさん
垢版 |
2012/11/18(日) 07:25:20.92
とりあえずインフラ使っとけっていう風潮？って
MVVMじゃなくてMVVMライブラリの使い方を憶える事になる
危険性高い気がするのよね。

MVVMインフラが解決しているであろう、
様々な問題を自力で解決できるように成らないと
ほんとうの意味でMVVMやXAML環境を理解したとは言わない気がする。

MVVMの啓蒙者ならそのぐらいまでやってくれないと片手落ちだろって思う。



ところでMVVMインフラってどんな問題を解決してるの？
2012/11/18(日) 13:25:29.40
コードビハインドのこともそうだしModelの責務の話もそうだけど
言ってることがコロッと変わるのはどうにかならないものなのか

なんか昨日もフォーカス制御をModelでとか唐突に言い始めるわけですよ
それが正しいかどうかは別として
ざんざん大声で他人を罵倒してまで言い続けてたことを
ちょこちょこ小出しでさりげなく路線変更してくる卑怯なところが俺が気に入らないところ
といういか、それがうがやが叩かれる原因じゃね？
2012/11/18(日) 15:58:45.35
>>499
やっぱ大学もいってないし、会社員としての経験もほぼ0でしょ？
どう考えても性格、人格が歪んでるというか問題があるんでしょう。
完全にアスペだよ、アスペ。
2012/11/18(日) 16:01:06.83
お前アスぺの意味やその性質わからずに罵倒語として使ってるだけだろ
2012/11/18(日) 16:06:22.21
人格の話は別の板でやれ。
2012/11/18(日) 16:17:28.34
私怨ならヲチでやれ
2012/11/18(日) 18:51:48.91
ここって元々WPFスレを正常化するための隔離スレッドだからいいんだよ。
便所の落書きスレッドで。

いやなら見るなｗ
by 岡村
2012/11/18(日) 18:59:24.39
まあアスペには違いない
2012/11/18(日) 20:26:20.24
尾上さんは
「日本でMVVMを正しく語れる人間は自分以外にいないッ！！」
って断言してたしスレ名を「尾上について語ろう」に修正してもよいと考えられる
2012/11/18(日) 20:52:02.11
ここMVVMやってる奴はキチガイだらけという見本のスレか
2012/11/18(日) 20:58:34.33
そもそもMVVMって何だよ
ぐぐってもクソみてーなサンプルコード乗せただけの記事しか出てこないしまともに概念を解説してるやついねーのな
コマンド(笑)とか冗長すぎてもうね
509デフォルトの名無しさん
垢版 |
2012/11/18(日) 21:04:18.24
わからないならこれでも勉強しろ

JavaScript製のMVVMフレームワーク「Knockout」
http://www.moongift.jp/2010/11/2010110212/
2012/11/18(日) 22:37:36.36
>>508
尾上さんのサイト見れば簡単に理解できる。
簡単に言うとPDS的にコードビハインドを記述しないで開発する手法だよ。
2012/11/18(日) 22:40:25.76
一応言っておくとPDSは一般的な用語じゃないから通じないと思うぞ。
512デフォルトの名無しさん
垢版 |
2012/11/18(日) 22:41:17.17
一般的にはフリーソフトで通じる
2012/11/18(日) 23:36:11.21
>>511
自分が知らないことは一般的じゃないと考える根拠は何だろうね
自分の無知を晒しているだけと気が付かない人には何を言っても無駄ではあるが、助言だけはしておくかな
2012/11/18(日) 23:39:05.83
Wikiにないから一般的じゃないと推定される
2012/11/18(日) 23:40:30.50
どこのWikiだよ
516デフォルトの名無しさん
垢版 |
2012/11/18(日) 23:42:35.17
PDS
http://ja.wikipedia.org/wiki/PDS
パブリックドメインソフトウェア(Public domain software)
かつてのドイツの政党である民主社会党(Partei des Demokratischen Sozialismus)。合併し、現在は左翼党 (ドイツ)に。
FTTHにおけるネットワーク構成（ネットワークトポロジー）の一つ。(Passive Double Star)
毛利元貞が考案した護身術パーソナルディフェンスシステムの略。
テレビ番組の制作会社の名称。PDS (制作プロダクション)を参照。
先駆動システム(Pre Driving System)
プラン・ドゥー・シー(Plan Do See) PDCAサイクルを参照。
アップルが採用していた拡張スロット。(Processor Direct Slot)
2012/11/18(日) 23:44:53.19
海外
http://en.wikipedia.org/wiki/PDS
2012/11/18(日) 23:48:19.69
>>510
PDSという概念があるよということなら納得できる
ただしPDSという言葉が一般的というのは賛同しかねる
2012/11/18(日) 23:51:14.50
で、そのPDSとMVVMに何の関係が？
520518
垢版 |
2012/11/18(日) 23:57:05.51
MVVMは、XAML系フレームワークにおけるP(resentation層)の問題を解決するもの
その前提としてPとD(omain層)の分離がある
521518
垢版 |
2012/11/18(日) 23:59:12.80
とはいえこれはあくまでパターンであり、絶対の解法ではない
その証拠として、MicrosoftもXAML系コンポーネントベンダーもMVVMを推奨してないという事実がある
522518
垢版 |
2012/11/19(月) 00:02:35.76
WPF・Silverlight・RTの公式ドキュメントで、一ヶ所でもMVVM必須と謳っている箇所があるだろうか？
また国内だとGrapeCity・Infragistics等のベンダーがXAML系コンポーネントを販売している
これらベンダーのマニュアルにも、MVVMを必須・提唱しているドキュメントは全く見当たらない
2012/11/19(月) 00:07:49.16
MがちゃんとしててVMはぺらっぺらになるのがMVVMの設計としては理想だからな
Web MVCではいくらぺらっぺらでもC無しというわけにはいかないが
VMがぺらっぺらになっていき、ついに無くなるのは別に問題ない
微妙に矛盾したパターンだよ
2012/11/19(月) 00:07:57.56
そりゃ必須なわけがない
MSDNマガジンやChannel9とかで適度に触れられている程度だな

あと「推奨していない」だと非推奨と主張しているように聞こえるから注意だ
「触れていない」あたりでいい
525518
垢版 |
2012/11/19(月) 00:08:10.96
勘違いしてはいけないのは、パターンはあくまでパターンであり、絶対の解法ではないことだ
逆にパターンに振り回されてその本質を見失えば、返って障害が発生する場合もある
MVVMを使わずに開発できるのならそれでよし
2012/11/19(月) 00:09:31.95
VMとテスト
2012/11/19(月) 00:11:53.87
>>526
MがちゃんとしててMのテストだけで済むならそれに越したことはない
2012/11/19(月) 00:12:18.51
>>524
どうかな？
「MVVMが必須」という誤ったイメージが蔓延し過ぎて参入障壁が上がり過ぎると
Microsoftや周辺ベンダーしては返って喜ばしくない事態になると思う
・・・いやすでになっているな

「触れていない」というより、いまとなっては「触れたくない」が正解だと思う
529518
垢版 |
2012/11/19(月) 00:15:52.43
かくいう私はどうかといえばMVVMは割と好きなパターンであるし、
実際これでかなり問題を解決できているのも事実だ
しかし、使えない、理解できない、開発速度が極端に落ちて苦痛に感じるくらいなら、
そこまで無理に使う必要もないと思う
2012/11/19(月) 00:28:44.37
VMがわかりにくいのって、CとかPとかと違ってVMにはこれといって
Mとの間に役割の違いが無いことだよ
特定のVとバインドすることを意識して作ったMってだけだからな
531デフォルトの名無しさん
垢版 |
2012/11/19(月) 00:53:44.94
なにいってんだ？
ビューの状態を表すモデルデータという
役割があるだろ。
2012/11/19(月) 00:58:48.11
別に選択状態持つためのMを設けてもいいんだぜ?
533デフォルトの名無しさん
垢版 |
2012/11/19(月) 01:02:55.31
それはもはやMではない。

Mの役割としては、GUIアプリではなく
CUIアプリからでも普通に使えるようなものを
目指すべきだ。

そんなGUIに依存した機能を持たせるべきじゃない。
2012/11/19(月) 01:04:56.93
その選択状態がGUIとしてあらわす際に必要となる選択状態なのか、
そのプログラムの動作自体を構成するにおいて存在する必然性のある選択状態なのかによるね
2012/11/19(月) 01:19:56.04
画面ごとのVMはいいけど、モデルごとのVMはめんどい
2012/11/19(月) 10:20:32.56
>>532
GUIの選択状態を維持するためのモデルをViewModelという
2012/11/19(月) 22:03:23.29
グリッドのボタン付けるときとかの
行ごとにVM作る派と作らない派の比率が知りたい
2012/11/19(月) 22:15:46.48
行って何の話だよ
2012/11/19(月) 22:20:34.86
WPFでデータグリッド使ったら負けだろ
それならWinForms使うわ
WPFならテンプレートで作れ
2012/11/19(月) 22:29:30.62
普通コンボボックスの項目毎VM作るだろ
2012/11/19(月) 23:23:02.89
グリッドって何かと思ったらDataGridのほうか
2012/11/20(火) 13:30:22.35
>>540
？？？
コンボボックスにモデルのコレクションをバインドするだけでええやん
2012/11/20(火) 13:54:25.91
HeaderedItemsControlとかをこねくり回すのは常套手段なのか
2012/11/28(水) 11:11:37.09
考え増やしたいから、
MVVM の各レイヤーの具体的な責務を教えてください

以下、テンプレ

M:
V:
VM:
2012/11/28(水) 11:22:45.65
>>544
> M:
ビューに関係無いデータ構造など変更部分。いわゆるモデル。UIスレッドと分離されてる事が望ましい。
> V:
ビューの見た目。極力もらったデータを表示したりインプットを上にあげるだけで何もしない。
> VM:
その両者を繋ぐもの。そのビューに関係するコーディネーター。ユニットテストできること。スレッド間の調整をここで吸収。
2012/11/28(水) 11:22:46.45
Set-Location : ドライブが見つかりません。名前 'M' のドライブが存在しません。
2012/11/28(水) 11:34:44.90
一番ありそうな間違いは、WebMVCの典型的な間違った使い方のように
M: データ
VM: ロジック
としてしまうことだな
注文画面のMは注文処理クラス。VMはあくまでインターフェイスの差を吸収するだけ。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況