TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
【node.js】サーバサイドjavascript 5【Nashorn】
【JavaScript系】 NILScript 【AutoHotkey風】
動的言語で大規模開発
次世代言語12 Go Rust Swift Kotlin TypeScript
Boost C++ Libraries Sandbox
[特設]サマータイム対応相談室
Visual Studio IDE環境
【マック】Macintoshプログラミング質問箱
△△もっとStruts2の良さを教えてくださいSsssion6
【安定版】ActiveBasicその12【4.24】
MVVMについて語ろう
- 1 :2012/06/06 〜 最終レス :2019/11/01
- 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 :
- このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。
アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。
京都大学霊長類研究所
- 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
じゃあ何て略したらいいんだよw
- 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
それはすげー思うw
- 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って名前なんだから何々であるべきなんだ!!1なんて話はナンセンス
- 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 :
- ほらw
>>45の意見なら、このスレですべきは>>36みたいな話であって、>>32みたいな話は別途
WPF/MVVMおけるアプリケーション構造について語ろう、みたいなスレを立てろって話になるし。
- 48 :
- >>45
それは>>32でいう2つめを見てるだけであって、実際のアプリを作るには1も3も必要だろ。
- 49 :
- >DBとのやり取りやAsync、Rxなど含めたアプリケーションロジック的な部分。
ってMVVMとどう関係あるの?
洋の内外問わず、これについて論じてるMVVMの記事って見たことないんですがw
- 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 :
- スレのあり方を議論するだけで終わりそうだw
- 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
難読化でいちばん隠したい部分がまる見えになるからオススメできない
プロパティ多すぎて書きたくねぇ!ってならT4
- 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 :
- 実際に作ってみりゃわかるけど
純粋にMのプロパティだけでインターフェースは作れない
タブやエキスパンダの状態とか環境設定とかの話ね
めんどくせぇから全部詰め込むってのもありだけど
無駄に一緒にするのは保守性を悪くする
どうせそこらへんはほとんどラッパなんだから
書くのがめんどくさい部分は全部T4使えとT4
- 162 :
- T4使いづらいって印象しかないんだが、なんか間違ってる?
- 163 :
- 外部のコードジェネレータを逐一呼び出すよりはT4でやった方が楽だろ
複数ファイルの処理が面倒なのはわかるが
- 164 :
- >>162
俺も同じ印象だ。
結局MsBuildタスクで、
http://d.hatena.ne.jp/okazuki/20110116/1295166605
の様な属性からコードを生成するようにしたよ。
- 165 :
- どうもこうも
ViewModelBase<T>から派生してたら
partialでTのプロパティを全部ラップしてやればいいのさ
簡単だろ?
T4で自分のプロジェクトからリフレクションする方法がわかりませんっていうなら
調べろとしかいいようがないが
- 166 :
- リフレクション使ったらVSのプロセス終了するまでアセンブリ掴みっぱなしじゃね
- 167 :
- > T4で自分のプロジェクトからリフレクション
このあたりは、みんなどの方法を採用してる気か聞いてみたいね。
俺は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
言語チームは切りたかったらしいが、マーケット部門から横やり入れられたらしい
とはいえVB6との互換部分は無視すればいいだけの話。実際MVVMアプリ開発しててなんの支障も感じない
- 195 :
- >>193
VB.NETに移行する案件、山ほどあるんだが
- 196 :
- VB6開発者と共にMVVMプロジェクト移行とか素敵すぎるな
- 197 :
- >>196
でしょw でも変に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 :
- 懐かしいなw
- 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 :
- あれも2ちゃんでの話に文句があるなら2ちゃんでいえばいいのにな
- 279 :
- 煽り耐性ゼロだから2ch無理とか言ってたけど
正直あのエントリに比べたらここやWPFスレの方がマイルドw
- 280 :
- いやさすがにそれはない
- 281 :
- ム板は煽られても他人の振りが出来るからなあ
- 282 :
- ここってJavaFXの話題もあり?
- 283 :
- ありじゃね
- 284 :
- JavaFXが最初に世に出た当時はなんでXMLじゃなくてわざわざ独自スクリプトなんだ
ボケカスと言われてたが、デザイナとプログラマの分業なんて幻想であって
ある程度ビューに振る舞い書けた方が便利だということを見越した判断だったんだな
XAMLのビヘイビア地獄よりははるかにマシだわ
- 285 :
- 今FXやるぐらいならSLでいいわ
- 286 :
- ビヘイビア地獄ってなんだよ
そんなに地獄に感じるならコードビハインドにコード書いたっていいんだぞ
- 287 :
- .triggerを手で書くのはうぜぇっていうのは同意するが
あれはblendで書く物だろ
- 288 :
- ビヘイビアもトリガーもインフラが整った環境じゃないとまともに使えん
自力で整えようとすると相応の労力が強いられる
遊びや自己学習でする分には良いけど、サクッと作りたいときや仕事だと2の足を踏むなー
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
ここに書くよりも直接連絡しろよw
- 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 :
- クライアントが以前より負荷が高くなるという問題もあるけれど、
以前というのはもう十数年前だったら問題になるというレベルで
今はクライアントは十分な性能を持ってるしね。
ブラウザ自体も速くなった。
それに比べるとネットワークはまだまだ遅いわけで、
テンプレートはローカルにキャッシュしておいて
データ量を減らすほうが得策かな。
サーバー負荷も低くなるし。
これぐらいだれでも思っていることで、
普通サーバーでやるもんだろで終わってる人ってのは
何も考えてないとしか思えないけどw
- 346 :
- 一方Twitterは以前API直接たたいてJSONからDOM生成してたのが最近生成済みのhtml片を鯖から受け取るようになった
- 347 :
- 完全なAjaxができるならいいが、
普通そうはいかないもんな
どうせサーバーで生成しなきゃいけないならなるべくサーバーにまとめちゃった方が楽
- 348 :
- どっちみちAjaxは使わないといけないんだから
クライアントにまとめちゃったほうが楽
- 349 :
- Ajaxはオプションだろ
利便性のためにクライアントでAjax使ってバリデーションしたとしても、
どのみちサーバーでもやらないといけない
- 350 :
- Ajaxはバリデーション以外で使うものって
わからないのか?w
バリデーションなら単なるJavaScriptで良い
- 351 :
- >>350
JavaScriptでもいちいちバリデーションするの?
バカ?
- 352 :
- JavaScriptでバリデーションが通ったら
サーバーでは検証せずにそのままDBに入れちゃうの?
やばくねそれ
- 353 :
- 話し理解できてないの?w
バリデーションをAjaxで行う=サーバーで通信して行うから、
そのバリデーションはサーバーでやってる事になるだろうって話だ。
あと、サーバーでやらないなんて一言も言ってない。
なんでこんなに文章読めないの?馬鹿なの?
- 354 :
- サーバとJavaScript両方でバリデーションするの?
マジキチ?
- 355 :
- >Ajaxはバリデーション以外で使うもの
>バリデーションなら単なるJavaScriptで良い
さっきと言ってることが180度違うけど
- 356 :
- うーん?
> Ajaxはオプションだろ
>>349が
オプションでやるって書いてあるじゃん。
みんな最初っから、両方でやるという前提で話してるんだが。
両方でやるのは、レスポンスを早くしてユーザビリティを上げ
無駄な通信を削減するため。言わなくても常識だと思っているが。
- 357 :
- >>355
そりゃ、さっき言った人俺は別人だからねw
- 358 :
- みんなって誰?
マジキチは一人で十分なんだがw
- 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 :
- まあ通常は継承ベースでいいと思う
- 385 :
- >>383
コードビハインドってViewって認識なの?
否定じゃなくて単純に質問。
- 386 :
- Viewとみなすのがふつう
ビヘイビアもコードビハインドの一形態なので同じくView
- 387 :
- 結局
vmに置かれるviewに強く関係するけど
共通ロジックの置き場がない
- 388 :
- 共通ロジックならUTILとかに置けばいいだろ?
- 389 :
- >>386
Viewとみなすのは分かったんだけど
VMじゃななくてVとみなす理由はなんなのかな?
- 390 :
- >>389
ビューと不可分だから
- 391 :
- >>390
WinFormsのコードビハインドなら不可分といえなくもないけど
WPFはそうともいえないんじゃね?
- 392 :
- >>391
この場合の不可分は「単体テスト可能かどうか」な。
ユーザーコントロールやウィンドウのクラスに対してXAMLを差し替えることは普通はできないし
無理矢理読み込むファイルを変えたとしてもコードビハインドからコントロールを直接触ってるから
結局ビューを表示して実際に操作してみないとテストできないわけ。
だからコードをビューから分離してビューなしでテストできるようにしましょうっていうのがVM。
- 393 :
- >>392
なるほどねー
- 394 :
- >>387
ViewModelsってフォルダにそういう機能のクラスを作ればええんや
まーそもそも、Views、ViewModels、Modelsってフォルダ群もなんだかなーって気もするが
そのほかのフォルダ構成でやってるやつおる?
- 395 :
- フォルダ分けない方が楽な気はするがその3つにしてるな
- 396 :
- М氏も「MVVM=コードビハインド無し」みたいな誤解撒き散らしてたし
「フルMVVM」って造語が誤解生んだのも事実
でもだからなんなの?勝手に誤解してずっこけたの本人のせいじゃん
お前が元信者だから裏切られた感強いだけだろ
- 397 :
- dynamicを積極的に使うのはどうだろう
VMがdynamic型でVへの参照を保持して動的にVのメソッドを呼ぶようにすれば、
メッセージやインターフェイスを介さなくてもVM->Vの密結合が避けられる。
dynamicなら完全に透過的なプロキシが使えるから、たとえばメモリリークの恐れがある箇所は
WeakReferenceでビューへの参照を持ち、ビューがGCされたらnullオブジェクトとして振る舞う
ようなプロキシを利用すれば、メモリリークの問題もコードの見た目を全く汚さずに解決。
型無しがダメだというならメッセージだって同じようなもんだよね。
(Vが当該メッセージをサポートしているかどうかはコンパイル時にチェックされないという意味で)
- 398 :
- マルチキャストが必要な場合(メモリリークを避けるためにイベントを置き換えるとき)もこんな感じで
class HogeModel {
//弱参照で複数のリスナへの参照を持つ複合プロキシ
private WeakCompositeProxy listeners;
public void AddListener(dynamic listener) { listeners.Add(listener); }
private void RaiseSomethingHappened() {
//登録された全てのリスナのOnSomethingHappenedメソッドを呼び出す
//リスナがOnSomethingHappenedメソッドを持たない場合は何もしない
((dynamic)listeners).OnSomethingHappened();
}
}
- 399 :
- MVVMってメトロになってもやること変わらんの?
技術的にはあっちが本流だと思うんだけど
- 400 :
- どうしてデザパタが環境によって変化すると思うんだw 技術じゃないぜ。概念だろ。
- 401 :
- この手の概念って「ある一定の規則とか法則に名前をつける」
だけの話だからね。
- 402 :
- コーディング段階は結構変わるがな
- 403 :
- >>401
概念の話と
概念に名前をつけるって
話がごっちゃになってるよ。
概念に名前をつけるのは重要なことだが、
もちろん概念そのものも重要なことだぞ。
- 404 :
- すいません、よかったら教えてください
MVVM Light Toolkitで遊んでるんですが、テンプレートから作成されるModelの
IDataServiceのメソッドがActionを渡して結果をコールバックさせる形になっています
普通に戻り値や例外を返せばいいと思うのですが、あえてコールバックさせているのはなぜなんでしょう?
考えても理由がちっとも思いつかないので、もしわかったらお教えください
よろしくお願いします
- 405 :
- >>401
MVVM以前からMVVM的な物が存在していたということ?
- 406 :
- >>404
処理に時間がかかる場合にGUIが固まるのを防ぐためだろ
Webからデータを取ってくるような場合は言うまでもないが、
ローカルなファイルやデータベースからちょっと取ってくるくらいでも結構固まる
- 407 :
- >>406
それはasync、awaitの非同期処理はModel内部で行ってServiceのメソッドをasync宣言しない方がよい
ということでしょうか?
Serviceのメソッド自体が非同期メソッドであれば画面が固まったりしないですよね?
そこら辺も初めてさわったのでトンチンカンなこと言ってたらすいません
- 408 :
- あ、MVVM Light Toolkitは別にasync、awaitのサポート環境を限定してないからかな?
逆にいうとasync、awaitが使える環境ならば別にコールバックさせる必要はないってことでいいんでしょうか??
- 409 :
- >>407
いやMVVM Light Toolkitは結構昔からあって、当時はasyncが無かっただけ
U氏はasyncは内部で使うものであってインターフェイスに使うなとか
思い込みだけで頓珍漢なことを言ってたが
今からasync前提で作るなら普通に使っていいよ
- 410 :
- >>409
なるほど、納得しました
サービスレベルでasyncにしてコールバックは利用しない方法でいってみます
いろいろありがとうございました
- 411 :
- >>409
うがやは、C#というか言語や.NETに関して知識なさすぎだからな。
ライブラリ設計者としてのセンスもない。
- 412 :
- MVVMでユーザコントロール使う場合のお作法?で質問があります
Page内に異なるユーザコントロールが2種類AとBがあります
Aはリストを表示するコントロールでBはその明細を表示するコントロールです
AとBにはそれぞれ専用のVMを作ってバインドしています
この時、A内のリストで選択されたものをBに渡したいのですがどう実装するのがスマートなんでしょうか?
現在は、PageのVMの中にAVMとBVMを保持していて、AVMのPropertyChangedイベント
をPageのVMの中で拾ってBVMのプロパティに設定しています
が・・・なんかいまいち感が
他にいいアイディアってあるのでしょうか?
- 413 :
- ListBoxのItemsSourceにVMたくさん入ったコレクションセットして
ContentControlのContentか任意のViewコントロールのDataContextにListBoxのSelectedItemをバインドするのが楽じゃね
- 414 :
- あぁそっか、そういうやり方があるんですね
勉強になります
ありがとうございました
もしよかったらもう一つ教えてください
実はAで選択されたItemをまた別のコントロールに今度は単一を設定するのではなくて
どんどん追加もしたいんですが・・・
そういう場合はどうするのが良いのでしょうか?
一つ一つの機能は徐々にわかってきたんですが、合わせ技になると発想がついてこないっす
- 415 :
- SelectedItemは同意だけど、VM自体はPage用1つだけでいいと思う
「AB両方の表示用を子プロパティとして持つクラス」のコレクションを
VMがプロパティとして公開して、Aがそれにバインド、
BがAのSelectedItemにバインド、が一番すっきりかな
- 416 :
- >>415
なるほど、そういうやり方もあるのか
そこで一つ疑問が出てきてしまったんですが・・・
WebでMVVMのユーザコントロールのサンプルをいくつか見たところ
たまたま?すべてのサンプルがユーザコントロール毎に定義されていて
それを鵜呑みにしてたんですが・・・
親になるビューだけがVMを持つのとコントロールも独自にVMを持つケース
どういった感じで使い分けたらいいのでしょうか?
ちなみに今回の場合、AもBも表示するだけではなくて、それなりに個々の
コントロールに機能を持っています
Aはソート順を変えたり絞り込んだり、Bは詳細を編集したりなどです
- 417 :
- >>416
俺は複数のWindowでControl使いまわしてるから、Controlに専用のViewModel持たせてるよ
- 418 :
- Model側でコレクションを持つ場合、そのVMも子ModelのVMのコレクションを持つようにしてるかな
この場合Model側もObservableCollection的な通知機能付コレクションを使うことになるが
子ModelがVM持つほどの意義がない場合は親Modelのコレクションそのまま使ったりもする
- 419 :
- 414は単純に、「別のコントロール」側のItemsSourceになってるコレクションに
Addしてやればいいだけだと思う…
単純過ぎるので質問の意味取り違えてるかも知れないけど
416についてはケースバイケース
どうするのが、開発や保守しやすいか。それ次第でしょう
- 420 :
- 昨日はレスいただいたのに返事できずにすみません
>>417-418
コントロールは再利用するつもりなので、今回はコントロールにVM持たせてみます
子もVMに入れてみようと思います
- 421 :
- >>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 :
- >>421
あまり参考にならないかもですけど、
もし俺が、そういうPage,A,Bの3つのVMでやるとしたら
Aのコンストラクタの引数で、デリゲートを受け取れるようにしておく
AではPropertyChangedのハンドラで、その受け取ったデリゲート呼ぶようにしておく
PageからA,Bをインスタンス化する際に、
BのAddItemを呼び出す処理や、Pageでやるべき処理もあればまとめて、
Aのコンストラクタに全部、ラムダ式で渡す
これで後は、AのPropertyChanged内だけで、PageやBの処理も全て完結
って感じにするかな…。
- 423 :
- >>422
ふむふむ、なるほど
レス読ませてもらって考えているうちに思ったんですが、AVMにItemが選択された
ことを通知するイベントを定義して、そこにラムダ式突っ込んであげれば良いのかな?
って気がしてきました
何が気持ち悪かったって、AVMにはほかにプロパティもあるわけで、PropertyChangedを
ハンドルしていると、別にPageには興味がないプロパティも飛んでくるわ
プロパティの名前をAVMで定数定義してAVMからもPageVMからも参照しようとすると、
MVVM Light ToolkitでVMのインスタンスを生成するときにエラーで落ちちゃって
プロパティ名をAとPageの双方に文字列で指定してた所なんで、一番キモイ所は解決された気がします
ただなんか手法が古臭いような気がしないでもないですがw
XAMLでこう書いてああ書いてすればサクっとできちゃうよ!的な解決策はさすがにないですよね?w
- 424 :
- @ugaya40: 難しいとかいってる人はコードビハインドでMVVMしましょ
コイツ、MVVMでコードビハインド使うのはMVVMを理解していない無能のすること とか散々ほざいてたくせしてなに言っちゃってんのって感じなんだが。
「難しいとか言ってる人」とかつけ加えてて誤魔化してんじゃねーよ。
難しいとか難度の問題じゃないってわかんねーのかな?
- 425 :
- コードビハインドを使用したものは神の怒りに触れ
永久にメモリリークの責め苦を受けるんじゃなかったのかw
- 426 :
- テンプレートにハンドラつけた場合じゃねそれ
- 427 :
- 自作のライブラリーをコードビハインドに対応させるって言ってたし完全に方向転換したんじゃないのかな?
それ自体はいい事だとは思うけどね
ただ、間違った持論でMVVMの概念をめちゃくちゃにした罪は大きいよね
きちんと間違ってたことを認めればいいけど、あの歪んだ性格じゃ無理だろうな…
- 428 :
- 必死にPSDって略語を流行らせようとしてるのに誰も使ってないのが泣ける、というか笑えるw
- 429 :
- PDS言ってるのは知ってるがPSDは知らんな
- 430 :
- DPSならしってる。全部知ってる。DPS全部
- 431 :
- 社内ではよく使うがネットで使う機会が無い
- 432 :
- 本人もあれだけど最近はアンチのがウザいな
直接煽られたことある人はそうなるのか
- 433 :
- 面白がってアンチに乗じてアンチごっこしてるやつが一番うざいし役に立たない
- 434 :
- MSの将来が不安なのでAndroidのMVVM環境教えてください
- 435 :
- JavaScriptでよければ
KnockoutがMVVMのフレームワークだよ
- 436 :
- Androidでバインディングは無理だと思う
コントロールがそれぞれ独自にXML読むクソ設計なんだぜ?w
- 437 :
- AndroidのフレームワークでバインディングやるならActivityのコード側でsetBindingみたいなメソッド呼んで
実装はリフレクションで頑張るしかないだろうけど
そんなことするくらいならPassive Viewの方がいいと思う
- 438 :
- さすがに今年中にBlend出してくれんとしんどいわMSさん
- 439 :
- Expression Studio 5まだー?
- 440 :
- android binding があるでしょ
- 441 :
- @ugaya40: 俺はWin8デスクトップにはスタートメニューが必要だと思うけど、シノフスキーさんの辞任と現時点で結びつけたりするわけもなく。ただその反対意見もまた極端なのが散見してるな。どっちもアホじゃないですか。
散々、極端なことを言ってたのはお前だろ?w
自分で自分がアホって自覚がちゃんとあるんだな。
- 442 :
- >>426
メモリーリークするの?
メンドクサイからテンプレートから呼ぶようにしたんだけど・・・
- 443 :
- >>441
お前さん、うがやのこと大好きなんだな
- 444 :
- そのうちVSスレのキチみたいに発狂しちゃうんだろうな
- 445 :
- さすがに粘着が過ぎる
- 446 :
- まぁ、こういう個人攻撃はネットウォッチ板でやるもんだな
- 447 :
- >>442
そんなことでリークするわけない。動的に生成された要素は、XAMLでイベントハンドラが登録されたままでも
ツリーから外れた時点でGC対象になる。XAMLではなくコードビハインドなどから追加した場合は当然
WPF管理外のため、イベントハンドラによる強参照が当然残るのでそれがマズい場合があるだけ。
つまりWPF自身の問題などでは決してなく、あくまで愚かな人間によるミス。
例の宗教はあえてそのあたりをぼかす(信者の多くはそもそも理解してないまま復唱してるだけだろうが)
ことによって恣意的なイメージ操作を行っている。
- 448 :
- そもそもWindow自体を解放する手段ないだろ
- 449 :
- ItemsTemplate/DataTemplateの中のコントロールのイベントに対して
コードビハインドのイベントハンドラを登録したときの話な
試してみたら分かるが、要素を削除した後にGCが走れば
ちゃんとコントロールのファイナライザが呼び出される。
- 450 :
- メッセージに応答してダイアログを開いたりする汎用的なビヘイビアって本当に必要?
VMからダイアログ開きたいんだったら、IoCでVMからIOpenFileDialogServiceのような
インターフェイスを通してメソッドを呼び出せばいいだけの話だと思うんだけど。
わざわざメッセージ投げてVで処理するなんて複雑だしXAMLも無駄に汚れるしタイプセーフじゃないし。
特定のビューでしか使わないようなサービスにするまでもない処理ならメッセージもアリだと思うけど
その場合ビヘイビアにする意味はなく(再利用しないんだから)、コードビハインドで受けて処理すればいい話だよな。
- 451 :
- テスト
- 452 :
- 行き過ぎたBlend主義。
俺もサービスにするかな。
- 453 :
- VMからのメッセージでアニメーションを開始させたいときなんかにはビヘイビアが便利かも
と思ったけどそんなビューの細かいことをVMで意識するのも本末転倒な気がするな
そこはメッセージとXAMLは直接繋がないと割り切った方がいいのかも
- 454 :
- 俺はビヘイビアで済ませたほうが楽かな
- 455 :
- Livet教のMVVM…ドカタMVVM
IoC使うPrism系のMVVM…JavaっぽいMVVM
- 456 :
- MVVM Light…光のMVVM
- 457 :
- よく話にでるlivetってライブラリ落としてみたけどクラス名にまでlivetって入ってんのね。
ダサすぎる。
- 458 :
- てゆーか、9割以上がPrismとMVVM light toolkitのパクリコードってのはどうなの?
Ugayaはずいぶんえらそーなことを言ってたがただのパクリライブラリじゃんか。
- 459 :
- そうだなC#はJavaのパクリだもんな
つーかソース見たことはないが本当にパクリなら大問題だしそれならここで言ってないで大々的に批判すればいいんじゃないか
- 460 :
- >>459
見ればわかるがおおざっぱに言えばLivetの独自部分でメソッドキャッシュとT4コンバーターぐらいじゃね?
C#っつーか.NET Frameworkだろ
1.0のころはパクリだったんじゃないの?
実際Javaがなければ今と同じ1.0は生まれてなかった
- 461 :
- なんだコード盗用とかじゃなくて概念の話だったのか
- 462 :
- >>461
>>458はコードと言ってるな
- 463 :
- >>461
綺麗に言えば、車輪の再発明?
ぱくりライブラリと言われても仕方がない代物ではある
何を目的にやってるのか分からないところもあるし
インフラを乱立させたって混乱するだけだし
ドキュメントやサンプル充実させて裾野を広げるってわけでもないし
尾上が自身の狂った思想から少しでもずれてる意見を発見すると
死ぬまで粘着されるしな
尾上は自分が日本での唯一のMVVM啓蒙者になるために
他人がおいそれと語れないようにしてるだけ
完全に癌でしかない
- 464 :
- MVVMの土台として画面遷移は極めて重要だと思うが、そこがいい加減なのはいただけない
同期ダイアログによる遷移のみってWinFormsかよw WinRTじゃそんなもん使えないぞ?
- 465 :
- >>464
MVVMはMSが本気で取り組まない限り無理。
言語、.NET Framework、IDEが三位一体で対応しないと今はまだ欠陥が多すぎる。
- 466 :
- >>465
WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
IDEでどうするもんでもないだろう
Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
- 467 :
- U氏に親殺されたやつ多すぎだろ
- 468 :
- >>467
叩かれてる奴に「氏」付けるのは本人だけ
ってだいぶ前に小学生の妹が言ってたよ。
- 469 :
- 画面遷移についてはMVVMと絡めてもっと真剣に議論されるべきだと思うぞ?
U氏関係なく。自称MVVMインフラではたいてい完全スルーされてるが(Livetでもおまけ程度)
どうしてもインフラ的なコードを書くことになる部分だし、MVVM使ってるなら画面遷移の設計も
それに強く影響されることになる。
- 470 :
- >>466
> WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
WPFの話じゃなくてMVVMな
> IDEでどうするもんでもないだろう
IDEにどれだけ恩恵受けてるかわかってないの?
MVVMだってフレームワークだけではどうにもならないことがある
> Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
Prismがもっと使いやすく標準で.NET Fxに乗らないと無理ってこと
- 471 :
- コードビハインド前提のMVVMフレームワークが出てきたら少しは前進すると思う。
Livetがダメなのは作者がコードビハインド完全否定してることと
>>458が言う通り、既存フレームワークの単なる2番煎じで
MVVMの問題点を克服するものではないから。
コードビハインドいいと思うんだけどな。
うがやのサイト見ていると分業とか書いてるが
Vをデザイナーに別注してるチームってあるのか。
デザイナーとデベロッパーの分業なんて幻想じゃないのかな。
XAMLをフルに理解してるデザイナーなんて一人もいないと思うよ。
- 472 :
- >>471
その点に関してはすでに奴は考え改めてコードビハインドの有無はどうでもよくなってるみたいだぞ
- 473 :
- VMの処理中にユーザの入力を求めたくなった場合とかかね画面遷移は
ぶっちゃけどのライブラリも何かあるたびにクラスやらインターフェイスやら増やさないとならなかったりして面倒だわ
MSはMVVMを推奨するんならASP.NET MVCくらい充実させるべき
- 474 :
- >>473
そういう遷移はビューだけで完結するのでほとんどMVVM関係ない。
ビューの実装の詳細だ。
設計に大きく影響するのはVMごと遷移するやつな。
- 475 :
- 具体的な例で言ってくれよ
- 476 :
- 例も何も、無理にVMくつけなきゃ 一覧画面 <-> 編集画面 とか大概の画面遷移はVMごと遷移だろ
ダイアログベースならそんなに意識しないだろうけどさ
- 477 :
- それならDataContextにVM突っ込んでもらうだけでよくね
- 478 :
- そのコードをどこに書くのかとかいろいろ問題があるよ
本来、一覧画面VMで 画面遷移しろ("編集ビュー", selectedItemId); だけで済むはずで
一覧画面のVMやVが遷移先の画面のVやVMのクラスを知っている必要は全くないけど
そう書けるようにするためには結局インフラがいるんだよね
- 479 :
- railsのscaffoldみたいにサクッとアプリを作れるようなインフラが欲しい・・・
- 480 :
- >>472
どうでもいいわけないよね?
氏のMVVMサイト見てくれば。
- 481 :
- プロ粘着なら奴のツイッターも観察すべき
- 482 :
- >>481
前はフォローしてたんだけどね。
自分とちょっとでも意見が違うと噛みついて粘着のパターンが多すぎて
ずいぶん前にフォロー解除したよ。
あの人ちょっとアスペ入ってるよね。
ちょっとというかかなり。
高卒で会社員経験なし、ってとこで人間の底が知れるわ。
- 483 :
- と2ちゃんねるで批判するガキwww
- 484 :
- >>483
ugayaの負けず嫌いもここまで来ると褒めたくなるなw
せっかく社会人になれたんだから2chで自演擁護とかやめたら?wwwww
- 485 :
- >>484
まともな社会人は多少の煽りには反応しねーんだよ
お前みたいな無職のクズとは違うんだよ
分かったらとっとと寝ろ
- 486 :
- ugayaは2chの煽りにtwitterやブログでキレまくってたけどなw
- 487 :
- >>486
いいから早く寝ろよ
- 488 :
- 反応はしてたけど別にキレまくってたってほどじゃなかったろ
- 489 :
- MVPVMの(Uによる)煽りはひどかった
- 490 :
- お前ら本当に暇なんだな
文句があるなら一度でいいからGoogleの検索トップになってみろよ
U氏のサイトはMVVMで検索すると余裕でトップなんだが
- 491 :
- そんなんだと宗教に騙されるぞ
U氏も言ってるだろ? 「MVVMだからこうしなければならない」じゃなくて目的を考えろと
- 492 :
- >>491
自分の考えた最強の目的しか許さず
その目的を達成するにはこうするしかないと決めつける
そこから外れたツイートを見つけると相手が黙るまで粘着ツイート
相手が黙ると「都合が悪くなると無視かよ、これだからクズは困る」的なツイートで〆
尾上さんのそこにシビれる!あこがれるゥ!
- 493 :
- 目的を考えろと言ってる本人が一番権威主義を煽ってる元凶という皮肉
- 494 :
- 尾上を擁護してるのはいったい誰なの?
誰がどう見てもアスペルガーじゃん。
尾上にへこへこ媚び売って家畜に成り下がってる奴って
高野将かぐらばくぐらいなもんだろ?
- 495 :
- 相手を擁護と認定してしまえばどんな誇大を使って過激に叩いても正当化できて安心だもんな
- 496 :
- 文句があるなら同じMVVMの土俵で反論すればいいじゃないか。
このスレに持論を垂れ流すだけでも人格攻撃よりはマシだしまともな議論なら歓迎だぞ。
考え方に関してはここはわりとU氏に反発してる人が多いみたいだし(俺もその一人だが)。
- 497 :
- MVVMの思想に関してはいい加減多少は理解したから、
そろそろMVVMの実装について語って欲しいなぁ、
- 498 :
- とりあえずインフラ使っとけっていう風潮?って
MVVMじゃなくてMVVMライブラリの使い方を憶える事になる
危険性高い気がするのよね。
MVVMインフラが解決しているであろう、
様々な問題を自力で解決できるように成らないと
ほんとうの意味でMVVMやXAML環境を理解したとは言わない気がする。
MVVMの啓蒙者ならそのぐらいまでやってくれないと片手落ちだろって思う。
ところでMVVMインフラってどんな問題を解決してるの?
- 499 :
- コードビハインドのこともそうだしModelの責務の話もそうだけど
言ってることがコロッと変わるのはどうにかならないものなのか
なんか昨日もフォーカス制御をModelでとか唐突に言い始めるわけですよ
それが正しいかどうかは別として
ざんざん大声で他人を罵倒してまで言い続けてたことを
ちょこちょこ小出しでさりげなく路線変更してくる卑怯なところが俺が気に入らないところ
といういか、それがうがやが叩かれる原因じゃね?
- 500 :
- >>499
やっぱ大学もいってないし、会社員としての経験もほぼ0でしょ?
どう考えても性格、人格が歪んでるというか問題があるんでしょう。
完全にアスペだよ、アスペ。
- 501 :
- お前アスぺの意味やその性質わからずに罵倒語として使ってるだけだろ
- 502 :
- 人格の話は別の板でやれ。
- 503 :
- 私怨ならヲチでやれ
- 504 :
- ここって元々WPFスレを正常化するための隔離スレッドだからいいんだよ。
便所の落書きスレッドで。
いやなら見るなw
by 岡村
- 505 :
- まあアスペには違いない
- 506 :
- 尾上さんは
「日本でMVVMを正しく語れる人間は自分以外にいないッ!!」
って断言してたしスレ名を「尾上について語ろう」に修正してもよいと考えられる
- 507 :
- ここMVVMやってる奴はキチガイだらけという見本のスレか
- 508 :
- そもそもMVVMって何だよ
ぐぐってもクソみてーなサンプルコード乗せただけの記事しか出てこないしまともに概念を解説してるやついねーのな
コマンド(笑)とか冗長すぎてもうね
- 509 :
- わからないならこれでも勉強しろ
JavaScript製のMVVMフレームワーク「Knockout」
http://www.moongift.jp/2010/11/2010110212/
- 510 :
- >>508
尾上さんのサイト見れば簡単に理解できる。
簡単に言うとPDS的にコードビハインドを記述しないで開発する手法だよ。
- 511 :
- 一応言っておくとPDSは一般的な用語じゃないから通じないと思うぞ。
- 512 :
- 一般的にはフリーソフトで通じる
- 513 :
- >>511
自分が知らないことは一般的じゃないと考える根拠は何だろうね
自分の無知を晒しているだけと気が付かない人には何を言っても無駄ではあるが、助言だけはしておくかな
- 514 :
- Wikiにないから一般的じゃないと推定される
- 515 :
- どこのWikiだよ
- 516 :
- 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 :
- 海外
http://en.wikipedia.org/wiki/PDS
- 518 :
- >>510
PDSという概念があるよということなら納得できる
ただしPDSという言葉が一般的というのは賛同しかねる
- 519 :
- で、そのPDSとMVVMに何の関係が?
- 520 :
- MVVMは、XAML系フレームワークにおけるP(resentation層)の問題を解決するもの
その前提としてPとD(omain層)の分離がある
- 521 :
- とはいえこれはあくまでパターンであり、絶対の解法ではない
その証拠として、MicrosoftもXAML系コンポーネントベンダーもMVVMを推奨してないという事実がある
- 522 :
- WPF・Silverlight・RTの公式ドキュメントで、一ヶ所でもMVVM必須と謳っている箇所があるだろうか?
また国内だとGrapeCity・Infragistics等のベンダーがXAML系コンポーネントを販売している
これらベンダーのマニュアルにも、MVVMを必須・提唱しているドキュメントは全く見当たらない
- 523 :
- MがちゃんとしててVMはぺらっぺらになるのがMVVMの設計としては理想だからな
Web MVCではいくらぺらっぺらでもC無しというわけにはいかないが
VMがぺらっぺらになっていき、ついに無くなるのは別に問題ない
微妙に矛盾したパターンだよ
- 524 :
- そりゃ必須なわけがない
MSDNマガジンやChannel9とかで適度に触れられている程度だな
あと「推奨していない」だと非推奨と主張しているように聞こえるから注意だ
「触れていない」あたりでいい
- 525 :
- 勘違いしてはいけないのは、パターンはあくまでパターンであり、絶対の解法ではないことだ
逆にパターンに振り回されてその本質を見失えば、返って障害が発生する場合もある
MVVMを使わずに開発できるのならそれでよし
- 526 :
- VMとテスト
- 527 :
- >>526
MがちゃんとしててMのテストだけで済むならそれに越したことはない
- 528 :
- >>524
どうかな?
「MVVMが必須」という誤ったイメージが蔓延し過ぎて参入障壁が上がり過ぎると
Microsoftや周辺ベンダーしては返って喜ばしくない事態になると思う
・・・いやすでになっているな
「触れていない」というより、いまとなっては「触れたくない」が正解だと思う
- 529 :
- かくいう私はどうかといえばMVVMは割と好きなパターンであるし、
実際これでかなり問題を解決できているのも事実だ
しかし、使えない、理解できない、開発速度が極端に落ちて苦痛に感じるくらいなら、
そこまで無理に使う必要もないと思う
- 530 :
- VMがわかりにくいのって、CとかPとかと違ってVMにはこれといって
Mとの間に役割の違いが無いことだよ
特定のVとバインドすることを意識して作ったMってだけだからな
- 531 :
- なにいってんだ?
ビューの状態を表すモデルデータという
役割があるだろ。
- 532 :
- 別に選択状態持つためのMを設けてもいいんだぜ?
- 533 :
- それはもはやMではない。
Mの役割としては、GUIアプリではなく
CUIアプリからでも普通に使えるようなものを
目指すべきだ。
そんなGUIに依存した機能を持たせるべきじゃない。
- 534 :
- その選択状態がGUIとしてあらわす際に必要となる選択状態なのか、
そのプログラムの動作自体を構成するにおいて存在する必然性のある選択状態なのかによるね
- 535 :
- 画面ごとのVMはいいけど、モデルごとのVMはめんどい
- 536 :
- >>532
GUIの選択状態を維持するためのモデルをViewModelという
- 537 :
- グリッドのボタン付けるときとかの
行ごとにVM作る派と作らない派の比率が知りたい
- 538 :
- 行って何の話だよ
- 539 :
- WPFでデータグリッド使ったら負けだろ
それならWinForms使うわ
WPFならテンプレートで作れ
- 540 :
- 普通コンボボックスの項目毎VM作るだろ
- 541 :
- グリッドって何かと思ったらDataGridのほうか
- 542 :
- >>540
???
コンボボックスにモデルのコレクションをバインドするだけでええやん
- 543 :
- HeaderedItemsControlとかをこねくり回すのは常套手段なのか
- 544 :
- 考え増やしたいから、
MVVM の各レイヤーの具体的な責務を教えてください
以下、テンプレ
M:
V:
VM:
- 545 :
- >>544
> M:
ビューに関係無いデータ構造など変更部分。いわゆるモデル。UIスレッドと分離されてる事が望ましい。
> V:
ビューの見た目。極力もらったデータを表示したりインプットを上にあげるだけで何もしない。
> VM:
その両者を繋ぐもの。そのビューに関係するコーディネーター。ユニットテストできること。スレッド間の調整をここで吸収。
- 546 :
- Set-Location : ドライブが見つかりません。名前 'M' のドライブが存在しません。
- 547 :
- 一番ありそうな間違いは、WebMVCの典型的な間違った使い方のように
M: データ
VM: ロジック
としてしまうことだな
注文画面のMは注文処理クラス。VMはあくまでインターフェイスの差を吸収するだけ。
- 548 :
- >>547
まさにこれw
- 549 :
- 使う側ならそれでいい
- 550 :
- Mのビジネスロジックがバックエンドに移って
結果的にMがデータだけになることはあるだろうけど
VMから見たら特に関係ない話。VMにビジネスロジックを書いてるわけじゃない。
- 551 :
- プレゼンテーションに関わるものとしてVMに置いとくべきデータやロジックがあるって意見も耳にするけど
自分には区別が難しいので極力Mに持たせるわ。
- 552 :
- 永続化しないデータとか?
- 553 :
- MVVM界隈の話はVMが強調されすぎるきらいがあるよな。
本当はMの方が遥かに重要なのに。どちかか省くなら迷わずM。
VMはMVVMパターンのアイデンティティだから仕方がないけど。
- 554 :
- 間違えた省くならVM
- 555 :
- プレゼンテーションにかかわるものはVに書くんじゃないのか
- 556 :
- VMは、抽象的な、表示する「ための」データだな
例えば、VでItemsSourceにバインドして表示する一連のデータのコレクションとか
特定のデータを、手段は特定しないからとにかく強調表示しろ、ということを示すプロパティとか
Vは、具体的な、表示「の仕方」だな
同じVMからでも、同じコレクションを表示させる方法はListBoxだったりDataGridだったり単なるテキストだったり
どんな形で表示するのかはVが決めることでVMは手を出せない
また、強調表示の仕方にしても、単なる色変化だったり太字だったり、その部分だけ無意味にアニメーションさせたり
表示の仕方もVに任せられててVMは手を出せない
- 557 :
- VBでペタポトプログラミングしか経験ない奴にパターン教えても一向に概念理解してくれない
ましてMVVMなんか到底無理無理
- 558 :
- そんな動けばいいという考えの奴に何をいってもダメだ。
平気でModel部分にフォームやコントロール(UI)のインスタンスを食わそうとしたりするからな。
- 559 :
- MVVMって従来のASP.NETやWindowsフォームに慣れた人に説明するなら、
V Aspxファイル/フォーム
VM コードビハインドのcs
M 業務ロジック
と対応してて、従来のASP.NETやWindowsフォームとの大きな違いは、
ViewとViewModelがバインディングを介すると言う制約があるので分離しやすい、
と言う理解なんだけど大体合ってるかな?
- 560 :
- 全然
- 561 :
- 大体合ってるみたいですね。
VB6脳なPGとJava/Struts脳なPG、どっちがMVVM覚えるのに向いてますかね?
- 562 :
- >>561
全然違うと言われてんだろ
概念がそもそも違うがそれが分からない人間でも
・コードビハインドは画面と同一クラスだがVMは別クラス
・コードビハインドとViewは一対一だが、View:VMは1:n
・VSでコントロールをダブルクリックしてもコマンドが作られて自動的にバインドされたりしない
・そもそもコードビハインドはコードビハインドで存在するだろ
と、上げ出したらきりが無い
MVVM使うならちゃんとMVVMの概論くらいは理解させないとあとで自分が地獄行きだぞ
- 563 :
- 的外れな回答()キター
- 564 :
- いまだにVB6脳なんて他のこと何も向いてないだろ
- 565 :
- 違うって言われてるのに合ってると受け取っちゃうのはどこにも向いてないな。
- 566 :
- 全然合ってるかもしれない
- 567 :
- 559は大体あってるよね?
というより562が間違いすぎw
・コードビハインド(各種イベントで呼び出される関数)は
手動で設定すれば Viewとは別のクラスにすることは可能だし
・V:VM は 一つのデータを別表現で表示することがあるので V:VM = n:1
・デザイナでダブルクリックしても自動で出来ない
→細かい処理を行いたければデザイナに任せずに手動で操作するのは当たり前。
・そもそもコードビハインドはコードビハインドで存在するだろ
→別にイベントで関数呼び出しても、
CommandやActionのバインディングで関数呼び出してもよくね?
- 568 :
- そういえば、データバインディングって
ほんの少し MFCのValue変数とDDX_〜 に似てないか?
- 569 :
- >>568
ほんの少しな( ´Д`)y━・~~
- 570 :
- @Grabacr07 いままでのオレオレICommandの正しい実装基底クラス
Prismのパクリなのになんでこんなに偉そうなの?
- 571 :
- 心底どうでもいい
- 572 :
- MVVMライブラリはすべてPrismのパクリだからな
いまさらだろ
- 573 :
- 別に偉そうじゃない件について
どれだけコンプレックス感じてんだよw ダッセーやつw ぷげら
- 574 :
- 実際やってみたらMVVMではなくWPFやSilverlight固有の部分でかなり躓いた
初見でXAMLを自由自在に扱える奴とかいるのか?
- 575 :
- 固有の約束事を理解しないといけないのはWinFormsだってASP.NETだって
PHPとかのWebフレームワークだって一緒だ
- 576 :
- パネル使ったレイアウトに慣れてないだけじゃね?
- 577 :
- >>574
ちなみに躓いたのどこら編?
- 578 :
- ControlTemplateとか初見でMSDNだけで使いこなせたら神だわ
- 579 :
- Templateカスタマイズする時点で折れるな
- 580 :
- >>573
別にウガヤが考えたロジックじゃあないのに
まるで自分で考案したような口ぶりが臭いだけじゃろ。
特にcommandのweakeventなんてprismのアイデアそのまんまだし。
++c++やneueと違って.NETやC#(言語)の知識は薄っぺらいのに
ビックマウスだから余計に臭い。
- 581 :
- >>580
詳しくは知らんが咀嚼して自分のライブラリとしてまとめ上げて、それを採用してくれてるとこもあるんだから、口だけ番長のお前より遥かにまし。
リアルでフルボッコにされたの?悔しいのぅ悔しいのぅ。
- 582 :
- 奴が自分で考案したみたいなことを言っているのは見たことないが
どの辺で言ってたのか気になるな
- 583 :
- 別に好きでも嫌いでもないが、世の中のMVVMフレームワークは全てLivetより下と言ってるように取れる文書ならみた
MVVMが普及しないのは既存のインフラが不十分なせいで、Livetがそれを解決するんだとか
確かアンチMVVMに反論する記事だったかと思う
- 584 :
- 現場でMVVMゴリ押しして使ったら大失敗したからアホにも使えるように作ったんだっけ?
部下も可哀想だな
- 585 :
- まあ既存のが不十分なのはあってるな
ただLivetが必要十分かと言うとそうでもない
- 586 :
- Javascriptエンジン組み込んでknockout.jsを逆移植するのがいいと思う
ビューに振る舞いを書けた方がいいのは、それを最初否定してたMVVM自身によって証明されたし
VMも静的言語で書くのは面倒な単純作業すぎる
- 587 :
- ReactiveExtensions絡めて作ってるがすこぶる楽だし見通し良くなってイイよ。
まぁ向き不向き有るかもしれんが。まだ試しで作ってるだけなので後でいろいろはまるのかもしれんけど。
内部の状態遷移など含めて綺麗に落とし込みたいんだけどまだそこまで出来とらん。
- 588 :
- MVVMとリアクティブプログラミングの相性は非常にいいね。
ただ、ReactiveExtensionsは記述が冗長になるので
人にはお勧めできないな。
async,awaitみたいにコンパイラ支援があればいいんだけど。
- 589 :
- >>588
非同期として扱うだけなら冗長になるかもしれんがその以上やるならあんなもんじゃない?どの変が気になる?
F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
- 590 :
- MVVMって何ですか?
- 591 :
- wwwwみたいなAAの一種
- 592 :
- >>588
俺は非同期についてはasync,awaitを使ってるから気にしてなくて、
リアクティブプログラミング本来の "関係性を記述する" って部分で冗長性が気になる。
例えば、
int A { get { return B ? C : D.E; } }
って単純な関係性を記述するだけでも、それなりの量になる。
> F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
F#の計算式は羨ましいね。
async, awaitがTask<T>を生成するのと同じように、
計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。
- 593 :
- >>592
> int A { get { return B ? C : D.E; } }
> って単純な関係性を記述するだけでも、それなりの量になる。
自分もまだそこまで突っ込んで触ってないのでなんだが、自分で用途に合わせた複数要素を取れるZipみたいな物とか作らないと記述が冗長になりそうな気はしてる。
Zip重ねてとかでもいいけど見た目的にも身微妙な気がしなくもない。
> 計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。
その辺でSelectManyとかSwitchで上手く合成出来ると綺麗に書けるんかね( ´Д`)y━・~~
- 594 :
- 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 :
- >>594
自分が言ってるのはQueryExpressionsの方。
使ってる例としてはこんな感じ。
http://mnajder.blogspot.jp/2011/09/when-reactive-framework-meets-f-30.html
これはクエリ式への直接変換的な感じだけど、望みのクエリ式を追加できるので独自のDSL的に定義できる。
- 596 :
- 従来型のほうがいいだろ
誰かさんにプレゼント
優れた言語より流行ってる言語
優れたフレームワークより使われてるフレームワーク
- 597 :
- アプリケーションで、各種バー表示のon/offや配置等の、GUIに関する設定がよくあると思いますが
そういう設定の保存・読み込みロジックはVMでいいんですよね?
MVVMの概念がまだあやふやで確信が持てません。
- 598 :
- 一番使われてるフレームワークが一番、ってのなら、
一番のラーメンはインスタントラーメンだぜ?
- 599 :
- Haskell大流行だもんな
- 600 :
- >>598
フレームワークとラーメンとが置換可能であることを証明できれば完璧だな。
イグノーベル賞がんばれよ。
- 601 :
- COBOL最高だろうが
- 602 :
- >>597
Vでしょ
というかそういう作り込みが必要な画面にMVVMを適用するのは不適切だと思うよ。
大してメリットがなく面倒なだけ。使うならダイアログとかで使う。
- 603 :
- メニューとか(共有の)ツールバーとかウィンドウ制御のようなシェル的な部分に
MVVMを適用しようと考えてはいけない
そういうのはインフラとしてMVVMの枠外で実装して、その中で扱うドキュメントには
必要に応じてMVVM適用するのがスマート
- 604 :
- あくまでVの都合だしな
MVVMは本体処理とUIの組み合わせ方のパターンでしかないので、ウィンドウのサイズ保存とかはロジックとは無関係
- 605 :
- >>602
え?Modelじゃないの?
煽りじゃなくて、真面目な質問です
- 606 :
- あぁ、確かにビジネスロジックではないのか
- 607 :
- あえてシェルにMVVMを適用するんならMだろうな
どちらにしろGUIに閉じた話であって、ビジネスロジックの世界とは分けて考えるべき
- 608 :
- >>597
VMで正しいよ。
ビューモデルというのは、ドメインモデルとビューとのギャップを埋めるラッパーの役割をするもので、
まさに>>597のようなビュー固有のデータを扱うのに適している。
Vに置くのは(少なくともこのスレにおいては)間違いだから>>602は気にしなくていい。
- 609 :
- >>608
それこそビジネスロジックとUIがごっちゃになってね?
もともとビジネスロジックから見たらVの実装の詳細にすぎないことで、
それが少々複雑になるからMVVM適用しようってんなら
GUIの設定情報を持つためのMを使うのが適切だと思うよ
- 610 :
- アプリケーションモデルというやつですか。
- 611 :
- そもそもそんなロジックに直接関係なくてGUIに閉じた混みいった制御と
金,人間,住所,データベース,入力フォーム云々を一緒にして扱うのがおかしい
そこ明確に分けるのが一番大事だろ
- 612 :
- そんなめんどくさいことせんでも、VBで画面にぽちぽちボタンとか張って、
ダブルクリックしてイベント追加したら、その中に全部処理書けばええやろww
- 613 :
- PrismだとShellに対してVとVMがあって、ShellのVMのプロパティに
入力画面とかのVM渡して、ShellのVの中でその画面開いて、ツールバーなども
Shellが管理するようになってたはず。サンプルではShellに対するMは無かったけど、
ツールバーの細かい設定入れるとしたら当然この設計ではShellのMになるよね。
ShellのVMが本当に必要かどうかはかなり怪しいが。
- 614 :
- >>609
ビジネスロジックというのを定形的に捉えすぎてね?
アプリケーションシェルと言った物の実装も対象が違うだけでビジネスロジックの実装と変わらんだろ。
MVVMはロジックとビューをブリッジ介して分離する仕組みでその対象がシェルでも構わんと思うけどね。
他の実装がしやすいなら無理に適応する必要はないけど。
- 615 :
- >>609
ドメインモデル(ビジネスモデル)からはビューモデルに対して一切関知することはなく、完全に独立している。
ビューモデルからはドメインモデルを(継承やコンポジションなどの形で)参照することになるが、
当然ながらドメインの詳細には立ち入らないため、ごっちゃになることはない。
> GUIの設定情報を持つためのMを使うのが適切だと思うよ
ここではモデル(M)をドメインモデルとビューモデルとに明確に区別しているわけで、このGUIの設定情報と
いうのがまさに表示のためのモデルであり、ビューモデルだと>>608で書いたつもり。
なんか噛み合ってないかな?
- 616 :
- >>614-615
うん。だからシェルの抽象化がVMだしシェルのロジックやデータがMとするなら
Mじゃないかってことが言いたかった。省くならVMを省くべきじゃない?
バインディングもあんまり役に立たなそうだし。
- 617 :
- ViewModelHelper.ReadOnlyDispatcherCollectionのソース見てるんだけど
Dispatcher経由でViewModelのDisposeしなくていいの?
- 618 :
- WeakReferenceがなんとか
- 619 :
- だからコードビハインドのあるなしとMVVMに何の関連もないと何度言ったら。。。最近コードビハインド付のMVVMしかしてない
おがやさん以前は、コードビハインドはMVVMの癌、肯定してる人は糞みたいなニュアンスのこと言ってませんでしたっけ?
この人若年性健忘症なのかな?
- 620 :
- そーとー昔じゃないかな?それ
- 621 :
- いくら昔でも180度真反対に勘違いするほどの痴呆症を患った高齢の方には見えなかったもので。
- 622 :
- >>621
ようするにやせ我慢だったと。そういう事です。
コードビハインドなんて所詮MS界隈でしか使われないローカル技術仕様の用語に過ぎず
モデル云々を語る抽象的な概念にはほど遠い。
単に趣味と程度の問題を高尚っぽく語りたい人が散見されるだけ。
- 623 :
- >>622
MS以外でも使われてるだろ
もっと幅広い知識を持たないといかんよ。
- 624 :
- 例
- 625 :
- MS以外のコードビハインドkwsk!
- 626 :
- >>625
knockout.js
- 627 :
- なんかデータバインディング持っているフレームワークなら何でもコードビハインドだとでも
言いたそうな勢いだなw
UIの画面設計の宣言的定義とUIロジックの手続き的記述を分けて書けるフレームワークなんて
MS以外にもいくらでもあるし、データバインディングもそのための定番手法の一つではあるが
knockout.js含めて「コードビハインド」という用語がMS関連以外の文脈で使われることなんて
ほとんどね〜よ。手続き的記述の部分をMSが独自にそう呼んでいるだけの話。
- 628 :
- 日本語だと分離コードになるのか。
確かにMS関連しかその言葉聞かないし、ぐぐってもMS関連しか出てこない
- 629 :
- 似たようなものだと、コードビハインドという単語ではないけどJSFの管理ビーンとか似た雰囲気
- 630 :
- Adobe FlexのMXML+ActionScript3がかなり似ているというか洗練されていると思う。
MXMLでのV定義は単純にAS3でのクラス定義の別記法なので、AS3でのクラス定義と
同様に実装するinterfaceを指定出来る。VMにもinterfaceを定義してあげればVとVMが
互いの実装を知らずにinterfaceだけを通してやり取りが出来る。
VMのinterfaceの先頭にBindableとアノテーションをつければ勝手にgetter・settetが
バインド可能になるのでデータバインディングでVMの値をVにはり付けるのも簡単。
- 631 :
- やっぱダイアログや画面遷移はView Serviceにするのが好きだな。
- 632 :
- 同意
共通に使えるものにメッセージ使うのはアンチパターン
というかメッセージいらない
- 633 :
- MVVMの意図するところはこんな認識で合ってる?
・V<->VM の依存関係はバインディングに任せましょ
・VM はデータの加工と操作 (コマンド) の提供に専念しましょ
- 634 :
- 大雑把にはあってるんじゃないか
- 635 :
- MとV&VMを別プロジェクトにして問題ある?
- 636 :
- >>635
ないって言うかむしろしろ(´・ω・`)
- 637 :
- よっぽど小規模でない限り分けるだろ
- 638 :
- 開幕迎える前にグッバイ・モーガンになるんか?
- 639 :
- livet 詳しい人いたら教えてくれ。
ttps://github.com/karno/Mystique/blob/master/Mystique/Views/Dialogs/SettingSub/ColoringConfig.xaml
ここの200行あたりにある感じで、ConfirmationDialogInteractionMessageAction を使う、MenuItem を作った。
でもこの方法だと、MenuItem の IsEnabled に ListenerCommand の CanXXXX が反映されない。
IsEnabled に反映させるにはどうしたらいいんだろうか?
- 640 :
- MenuItemに直接アクション持たせてIsEnabled管理も別プロパティでやるか、
CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ
- 641 :
- せっかく教えてもらったが、いってることがわからんズラ
「MenuItemに直接アクション持たせて」とはどのようすればいいんだろうか?
サンプルのサイトがあったら張ってもらえないだろうか。
「CommandのCan〜状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ」
これをやるためには、MenuItem の Command にバインディングする必要があるだろうが、ダイアログの表示はコード・ビハインドでやるという理解でよいでしょうか?
質問ばかりですまんです。
- 642 :
- MenuItemのIsEnabledにコマンドの可否状態が反映されないって言うからMenuItemにコマンドはバインドした状態で反映されないって言ってるんじゃなかったの?
それともコマンドをMenuItemにバインドせずにMenuItemに反映されないって言ってるの?
ダイアログの表示ならコマンドで叩かれたVMからVへメッセージ飛ばしてやるんだろ
そのために確認用のトリガとアクション書いたんじゃないのか
- 643 :
- 質問の仕方がまずかったかな。
IsEnabled と具体的なプロパティを書くのではなくて、
MenuItem の活性・不活性に CanXXXX が反映されない
と書けばよかった。
コードはリンク先に書いてあるのとほとんど同じ。
"Interaction.Triggers"に設定していあるのであって、
MenuItem の Command にはバインドされてない。
質問をかえれば、リンク先のようなコードを書いたが、
これでは SetDefaultColorCommand の CanSetDefaultColor
が MenuItem の状態(活性・不活性)に反映されません。
どうしたらいいでしょうか?
って感じです。
- 644 :
- >>643
MenuItemはLivetのメッセージ機構なんて知らないし
DirectInteractionMessageにもコマンドの状態を反映させる仕組みは無いから
自分でやらなきゃならんだろうな。
VMにプロパティを用意してIsEnabledにバインドするとか
コマンドの状態をIsEnabledに反映させるBehaviorでも書けば?
- 645 :
- LivetのCommandにはCanExecuteプロパティあるからIsEnabledにそれをバインドするのがいいだろう
- 646 :
- >>645
ありがとう。できた。
シンプルな解決策だね。
- 647 :
- Livetの0.98辺りの時に書いてたソースコード、
今のバージョンだとそのまま使えないんだな…
DispatcherCollectionとかWindowMessageActionとか、
コンストラクタに渡せるパラメータの型とか順番とか、すっかり変わっちゃってる
- 648 :
- Livet .NET4.5で、読み取り専用のスレッドセーフなコレクションをModelに持たせたいんですけど
ObservableSynchronizedCollectionをラップするクラスを自作するしかありませんか?
- 649 :
- MVVMだのスレッドセーフだの言う前にマルチスレッドをちゃんと理解しろよ
読み取り専用ならスレッドセーフだからReadOnlyCollection<T>でいい
- 650 :
- 読取専用のコレクションは変更されないわけじゃないぞ
- 651 :
- さすがにそれは無理があるだろ…
それに、随時少しずつ変更されるんじゃなくて時々ゴソっと入れ替わるだけなら
Observable*使わなくてもコレクションごと差し替えてしまえばいい
- 652 :
- っていうか作法的には>>651のやり方の方が正しく「スレッドセーフ」だと思う
Observable*使うと、連続してコレクションを変更するときに変更途中の変な状態が晒されちゃうよ
決してObservableSynchronizedCollectionなら解決するという問題ではなく
- 653 :
- 一括で変化させるのではなく、逐一反映させたいのです。
その為読み取り専用ラッパもINotify〜でないといけません。
- 654 :
- Livetプロジェクトを作った時にできるInfrastructureAssembliesフォルダは何のためにあるの?
- 655 :
- すいません。必要なDLLとクイックヒントのXMLっぽい事は分かりました。
でもLivet.Design.dllが何の役割があるのか分かりません。
- 656 :
- >>648
ReadOnlyObservableCollection
- 657 :
- 昔の0.9xのLivetで開発してたもので、画面描画が完了したタイミングでアニメーション開始させるために
DispatcherHelper.BeginInvoke(action, DispatcherPriority.Render);
みたいに書いてたのがあるんだけど(actionはアニメーション開始させる処理)、
今のLivetだと「BeginInvokeは古い形式です」とかいう警告になってしまう。
まぁ、警告だからコンパイルできるし実行もできるんだけど…
警告出ない、古くない形式ってどう書けばいいんだろう?
- 658 :
- UIDispatcherプロパティからBeginInvokeだったと思う。
- 659 :
- >>658
それでOKみたいですね どうもでした
0.9xと1.xで、結構変わってるとこ多いですねー
- 660 :
- MVVMでの非同期処理をする場合について質問なんですが
MはUIスレッドを意識せずプロパティやコレクションを変更し
それを監視してるVMが適宜UIスレッドにディスパッチする
という感じでするのでしょうか?
- 661 :
- UIスレッドというものはView側の都合だからそんな感じだな
VかVMあたりだろう
- 662 :
- Livetの公式ページが404 File Not Foundになってる…
- 663 :
- よくあること
- 664 :
- よくあるのか
たまにしか見に行かないから、この1年半くらいで初めてだった
そのうち直るのかな
- 665 :
- @merancronと@ugaya40のサイレントバトルがかなり面白い
- 666 :
- Livetのページ、1週間以上経ってもまだ404 File Not Foundなんだが閉鎖しちゃった?
それとも移転したのか?
閉鎖にしても移転にしても何かその旨書いといて欲しい
しかしユーザー困るな
- 667 :
- >>666
たぶんサーバーの料金払ってないだけ
- 668 :
- MVPなんだからAzureの無料枠ぐらいもらってるだろうに……
- 669 :
- や ら な い か
- 670 :
- kon
- 671 :
- Uにリムーブされていることに気がついたw
まあ、ちょくちょく揉めてたからなw
- 672 :
- Vにバインドしたコマンドの内部で非同期操作を呼び出したときのお作法ってあるんですかね?
- 673 :
- 俺は気にしてないが、VMでは特に気にしなくていいんでね?
- 674 :
- >>672
同じコマンドを複数回読んだ場合、場合によっては順序が変わる可能性あるからその辺に注意ぐらいかのー
- 675 :
- いい加減日本語の書籍を出してほしい。
- 676 :
- ModelがINotifyPropertyChangedを実装する理由は
Mを操作した結果、プロパティが変化したことを通知する
という理解でいいですか?
- 677 :
- OK
- 678 :
- >>676
OnPropertyChanged で渡すプロパティ名が間違っていると View への通知が
正しく行われない。当たり前の話だけど、この種のつまらないトラブルが
多いから注意してね。
- 679 :
- >>394
ちょっと前の書き込みだけど、フォルダ分けみんなどうやってるかが気になる。
やっぱ、View/ViewModel/Modelって分けてるのかな?
なんか、画面が大量にある場合とかに、V/VMのクラスが大量にできて、対応するV/VMのペアが、IDEから辿りにくいんだよなぁ。。
V/VMがたくさんあるような時って、機能とかグループごとにサブフォルダでまとめた方がいいのかな。
こんな風に、、
・グループ1フォルダ
・View
ここにグループ1のViewを複数入れる
・ViewModel
ここにグループ2のViewModelを複数入れる
・グループ2フォルダ
・View
・ViewModel
- 680 :
- 俺も最初に参考にしたサンプルが
View/ViewModel/Model みたいにフォルダ作ってたので
それに倣ってそんな感じにしたけど、サンプル程度のクラス数ならいいんだけど
数が2桁くらいになってくるといまいちだよね。サブフォルダまで作っても。
むしろ、特定の機能のフォルダ作っちゃって、そこに
それに関連したView/ViewModel/Modelをセットで入れる、みたいなのも
逆にそこだけで完結しないで複数にまたがるのが分類しにくかったり。
- 681 :
- >>680
俺もそれが妥当と思う
- 682 :
- 少なくともView内は分けない方がいいと思う
- 683 :
- 昔はフォルダで分けてたけど、今はこんな感じ↓
ソリューション
- ModelLayerプロジェクト
- ViewModelLayerプロジェクト
- ViewLayerプロジェクト
- UnitTestプロジェクト
- Commonプロジェクト
- 684 :
- 書き忘れたけどもう一つ、ソリューション名と同名のプロジェクトが有るな
(仮にMainプロジェクト)
MainプロジェクトとUnitTestプロジェクトは、アプリケーションプロジェクトで
V/VM/M及びCommonプロジェクトは、クラスライブラリプロジェクト
- 685 :
- C#の場合自動生成される名前空間にフォルダ階層が付加される仕様がこういう場合鬱陶しい
- 686 :
- 複数の機能(サブシステム)から構成されるようなアプリなら、俺も680派。
「レイヤ」よりも「機能」の方が凝集度高いんだし。
1機能内でもまだ画面が多いようなら、/機能/の下にView/ViewModelとかを作っても良いけど。
そこまででなければ、少なくともViewとViewModelはセットで。
Modelは、機能固有のものならセットにしても良いけど、だいたいはアプリケーションレベルで
考えるものな気もするので、別配置。
- 687 :
- ModelはともかくViewとVMは一対一で対応してること多いからなあ
- 688 :
- Modelはフォルダどころか別プロジェクトだろ
- 689 :
- >>680,686
機能ごとに分けて、そのフォルダの中にV/VMを突っ込むのよさそうだね。
VとVMは一緒にいじること多くて、近くに置いておきたいし。
ありがとう!!
すごく参考になった。
- 690 :
- VMが扱うモデルは1つとは限らないわけで、そういうのは無理があると思うけどね
- 691 :
- ん?
- 692 :
- >>690
機能単位でまとめるのはVとVMまでにして、モデルは別フォルダとか別プロジェクトにまとめる、でいいんんじゃないかな?
- 693 :
- Mの設計にいまいち確信が持てないんだけど
例えばChromeみたいなタブブラウザを作る場合、開いてるページのコレクションはMで持つの?
- 694 :
- >>693
MVVMはそんなに厳密に考えんでいいと思うけどね。
VMをVIEWを軽くするためのロジック移し場所ぐらいに考えてモデルを分ける必要あるなら作ると。そのモデルは一つでも複数でもいい。
Chromeの例なら自分なら開いてるタブやその他の状態を持つアクター一個作るかな。
- 695 :
- MVVMの設計に関しては、
まずアプリケーションをVとMに分ける。
次にVをVとVMに分ける
くらいの考えでいいと思う
- 696 :
- 今はMVVMPCEARELS
- 697 :
- test
- 698 :
- 普及している感じがしない
- 699 :
- >>699のような手合いは一度ふぁうらー先生の本でも読んだらいいよ
関心事の分離とフレームワーク依存がわかってない
- 700 :
- PoEAAは読んでるけど、どこがわかってないのかわからないので、教えてくれ。
- 701 :
- >>699
今迄一度もViewでこのデータが必要だからここに持たそうとかやったことのないものだけが石を投げなさい(。-_-。)
- 702 :
- >>699
マジでなにがどうわかってないんだか教えて欲しいんだがな。
- 703 :
- PoEAAのMVCの説明って意味不明だよな
- 704 :
- >>702
[ModelがViewを意識]と[Modelの責務]は次元の異なる問題ではないだろうか
- 705 :
- >>703
翻訳文が意味不明なんだろうな
- 706 :
- >>704
だからモデルの債務になるものでビューのことを一切意識しないで扱えるものがどんだけあんだよ。
ビューでこういう使い方するからこういう風に元のデータは持とうとかいちどもやったことないの?
- 707 :
- >>706
それはModelのデザインの話であって、責務とは別の話だろうよ
デザインと責務がごっちゃになってない?
いすれにせよ>>699の非難は的外れだけどね
- 708 :
- 大きな切り口としてアプリケーションをプレゼン層とドメイン層に分ける
プレゼン層=ビュー、ドメイン層=モデルだから当然責務は違う
しかし>>706のいうとおり、モデルがビューの使い方を意識した設計になるのは
開発の都合上当然の話だと思うな
- 709 :
- ReactiveProperty良さげなんだけど使ってる人います?
週末にでも遊んでみよう。
- 710 :
- Livet1.3キタ
- 711 :
- WPF MVVMでアプリ作ってる人いるんだろうかと思えるくらい過疎っぷりだな
ほんと情報少なくて困ってる
- 712 :
- こんなスレあったのか。今まで気が付かなかった。
MVVMは机上の空論っていうか筋が悪いの一言に尽きると思う。
これは過去にオブジェクト指向が攻撃されたような批判者の理解不足に基づく誤解では必ずしもない。
- 713 :
- とオブジェクト指向の時にも同じようなことを言っていた人はいた。
- 714 :
- >>712
具体的にはMVVMのどこらへんが実情に即していない机上の空論で、筋の悪さなの?
可能であれば、古典的MVCやMVPとの比較も交えながら論じてみてほしい。
- 715 :
- >>713
オブジェクト指向は筋が悪かったからな
- 716 :
- 結局どんな設計がいいの?
Rxに傾倒したけど、上手く使いこなせてない
- 717 :
- 匿名通信(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 :
- >>716
fluxとかかな。まだよく分かっていないけど。
状態を一箇所に集約する
- 719 :
- fluxのデータフロー見てたらApache Strutsを再発明したかったのかなって思た
- 720 :
- MVVMって保守性が悪いよね。
WPF自体がそういう傾向が強いけど、MVVM使うと輪を掛けてそうなる。
他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。
MVVMで保守性が高くなるんだ!って喧伝してる人がいるのは知ってるけど、
正直裸の王様を褒めてるようにしか思えない。
- 721 :
- 結局正解はなくて最適解があるだけなんだけどさ
よくある失敗はMVC、それも頭でっかちなコントローラーをVMに置き換えているだけパターン
この場合ビューモデルが主役で、テンプレートエンジンのビューと1:1の対となる入れ物の箱モデル
を量産することになる
ちょこっとイベントハンドラーをコードビハインドに書いたら、あとは全部ビューモデルにお任せ
という中央集権国家が誕生、疎結合どこいったって話だな
- 722 :
- >>720
>他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
>ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。
これって単に慣れてないからってだけじゃなくて?
- 723 :
- 昔のようなデバッグして追いづらいってのはあるな。
- 724 :
- やっぱりrails系は偉大だったってことかなー。
どこにどんなコードを置くのかフレームワークとして強制するって大事だね。
iOSとかUIKitってだけだから特にファイル構成に対する強制がなくて悩む。
- 725 :
- お前らがMVVM頑張っても
画面設計者がMVVM理解者とは限らないから
どこかは破綻するんやで
- 726 :
- MV)o¥o(VM
- 727 :
- データを格納したdatatableをdatagridにバインドして表示させてます。
この場合、datatableはVMですか?Vですか?
- 728 :
- 他のフレームワークに比べてMVVMが有用なケースって、WPF以外だとどんなのがありますか?
- 729 :
- >>728
Xamarin.Forms
vue.js
- 730 :
- UWPみたいな大きい画面から小さい画面までサポートする奴。
UIとロジック分けられないとRる。
- 731 :
- modelからViewModelに通信の結果を返すときに、
Rxとか使わずに、interfaceを渡してコールバックを返すようにするのは何かマズいんでしょうか
- 732 :
- Rxも結局インターフェースだしいいんじゃ?
- 733 :
- modelは状態の公開と戻り値のないメソッドの提供のみするそうですが、
状態の公開っていうのは要はpublicなfieldってことなんでしょうか
getterで提供したらなんで駄目なんでしょうか
c#のことはよくわかりませんandroid javaを想定しています
- 734 :
- >>733
メソッドの戻り値をvoidにする、setterを提供しないのはMVVM由来ではなく、非同期な作りをしたい場合に起因します。
これは非同期な作りの場合、メソッドを呼び出しても直ちに状態が変更されるとは限らないから。
なので、状態の変更が完了した時点でMが通知し、受信側がgetterを介して状態を取得することを推奨しているに過ぎない。
逆に同期的な呼び出ししかしないのであれば、setterやメソッドの戻り値も好きにすればいいと思います。
- 735 :
- がや氏の戻り値返すなとかはCQRSやReactみたいに処理の流れを固定しろってのが本質と思うが本人もアーキによって返しますよとかいってるからじゃああの煽りはなんだったの感もありよくわかんね
- 736 :
- 本人の中では色々な蓄積もあってその上で言ってんだろうけど、間を飛ばすから外から見たらよくわからん事になってるという印象
- 737 :
- とりあえず御大の言うことはスルーしておいて、Flux、Reduxなんかについて調べてから、自分で答えを出せばよろし
- 738 :
- C#で状態の公開というとプロパティを使うわけだけど、
javaにはプロパティがないからgetter使うしかないだろうし…
そもそもMVVMではgetter使っちゃダメなんて話があるの…?
- 739 :
- 状態の公開が何でpublicなfieldになんのか分からん
オブジェクト指向もっかい勉強した方がいい
- 740 :
- いや返り値のないメソッドしかテイギシタラ駄目っていう縛りがあると思ってたから、
getterも駄目なのかと
- 741 :
- MVVMの提唱がMSからだし、MSが作った言語にはプロパティがあるから…
…javaのgetterが駄目ならプロパティ使うのも駄目になるはず
- 742 :
- ゲッターかプロパティかは本質じゃないだろう。
ゲッターをフィールドっぽく見せてるのがプロパティなだけなんだし。
- 743 :
- AndroidでMVVMやりたいだけなのに
C#でのMVVMとFluxとReduxとクリーンアーキテクチャと
databindingとRxとretrolamdaと全部学ばないといけないわけ?
敷居高杉ませんか
- 744 :
- MVVM含めアーキテクチャごっこをやること自体が目的なら全部学べよ。
Androidで開発しやすくしたいというのであれば、まずはData Bindingを使うことと、
APIの戻り/公開メンバとしてObservableを使ってみるところから始めろ。
DroidKaigiのアプリあたりを参考にしながら。
- 745 :
- build 2017と関係あるのかわからないけど、UWP関連でこんなもんが
https://github.com/Microsoft/WindowsTemplateStudio
https://developer.telerik.com/topics/net/announcing-windows-template-studio/
- 746 :
- droid kaigiですね。ありがとうございます。
他にMVVMの参考になる小規模なソースコードのgithubリンクとかないっすか
- 747 :
- Android java MVVMで検索したら色々出てくるけど…
- 748 :
- 画面遷移の処理とか結局viewでしかできないから、
view -> viewModel -> view
で行ったり来たりしてるのとかみると糞だなあと思う
- 749 :
- Presentation Coordinator
Navigation Service
なお、画面遷移の話とは別に、Androidの場合どうしてもActivity/Fragmentに
依存してしまう部分は出てくるから、その辺はあまり厳密に考えない方がいい。
- 750 :
- VMとMの分割についてきちんと説明してくれてるサイトってあまりないけど、
基本的には全部Mに入れてVMはプロパティとしてMだけを持ってそれをVにバインドするってことでいいの?
大抵のサイトでは全部VMに入ってるけど
- 751 :
- サイトは知らんが、一番しっくりくるなーと思う考えの一つは
MはDBなどのデータを格納する何か、もしくはデータそのもの。
VMはMからのデータを加工するものとVewとの橋渡しを分けてVMへ。
VはVewそのもの。
ってのが個人的に一番しっくりくる。
- 752 :
- viewそのものだとactivityがviewになるのは違和感がないか
- 753 :
- 違和感ある。
VMに入れたい。
- 754 :
- MVCだろ
M はDB以外のことは出来るだけしない
V は表示するだけ
C(VM) で色々する
概ね >>751 さんに同意
- 755 :
- VMがactivityの参照を持ったらだめだと聞いたが。。
Xamarinだとpageか
- 756 :
- C=VMだとMVCと変わらんだろうが
- 757 :
- イメージとしてはCより広い範囲のものをぶち込んでMやVに余計な物置かないのがVMって思ってる。
基本MVCと変わらん。
Cじゃないのはどこに置くとか名前から混乱してる人多かったから、VでもMでも無いのは全部VMってした方が混乱は少ない。
- 758 :
- MVVMのVはMVCのV+Cだよ
MVPのVとかと同じ
- 759 :
- MVVMのVって左から3番目のVのことですか
- 760 :
- 2番目だよ
- 761 :
- めちゃ効率悪い作り方
- 762 :
- MVVMってMVCより明確にしたもの
VMはCという漠然とした者じゃなくて
Viewに対応するオブジェクトそのもの。
だからVMのプロパティを変更することでViewに反映されるし
Viewで何か変更するとVMのプロパティに反映される。
双方向バインディングを使って実現する。
- 763 :
- 全然進化してないな
- 764 :
- >>761
効率求めたらガチガチにVewと結びつくからな。
Vewが固定ならMVCもMVVMも要らない。
デスクトップやモバイルで中身同じだけどVewだけ違うとかだからMVCやMVVMが必要になる。
デスクトップとモバイルで同じ処理を別々に書くよりは全体では効率が良くなる。
特にモバイルが画面の大きさや画面比率が多様化してる昨今では。
- 765 :
- >>763
強いて進化と言ったらMVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したままで、updateで更新しないと値を更新しなかった。
MVVM独自かは不明だが、MSでは相互に値の更新を自動通知し合う仕組みが出来た。
>>762が言ってるのはそういう事。
- 766 :
- >>765
そんなもん独自のわけないだろ
- 767 :
- MVVMにおいてactivityはviewでいいんだよな?
- 768 :
- 更にいうとMVVMをさらに発展と言うか破綻しづらいようにしたのが
flux。MVVMのVMは双方向バインディングだけど
fluxの場合は、Viewの変更は直接VMに反映しない方針。つまり片方向バインディングに限定した。
その代わりVMへの変更関連をActionに集約して
Action -> State(VMに対応) -> View ->Action
と片方向への情報の流れに限定したのがflux
- 769 :
- >MVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したまま
糞Windowsだけだろω
- 770 :
- 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
USCRF
- 771 :
- QIC
- 772 :
- USCRF
- 773 :
- LivetとPrismとはなんだったのか
- 774 :
- Livetは使った事ないから知らんがWPF開発には色々便利なものあったらしいしPrismも便利なとこあるんじゃないの
自分は使わんけど
- 775 :
- 知らんなら答えなくて良いんじゃね?
- 776 :
- 評判は聞いてたからその範囲で教えてあげてんだけど?
無知すぎるボンクラは逝ってどうぞ
- 777 :
- Prism.Unityは、UWP版のほうがシンプルでかつ十分な機能で良いんだけど
wpf版もあっち基準に改善したら良いのにな
- 778 :
- https://teratail.com/questions/140681
MVVMやってるのこんなのばっかりだからな死滅すればいいよ
- 779 :
- ハイハイ理解できないから終了ね
- 780 :
- >>776
知らないなら答えなくていいんじゃね?
ぼんくらはR
- 781 :
- >>776
知らんなら答えなくて良いんじゃね?
過疎スレで無駄に煽るボンクラ
- 782 :
- 無知が顔真っ赤にしてテラワロス
- 783 :
- >>782
無知が顔真っ赤にしてテラワロスっておまw
そんなんがほんとに面白い人とかいるのかね
MVVMはどこいったのw
スレタイと何も関係ない書き込みしちゃって頭おかしくないのボンクラwwww
- 784 :
- いやテラワロスってのはMVVMなんだろうな
無知なのでわからんわ
- 785 :
- >>778
>INotifyPropertyChanged はバインド専門ではありません。
これって詭弁だよね
MVVM使う時点で通常のモデルにすると不便だからINotifyPropertyChanged使うだけ
- 786 :
- MVVMじゃない設計で作られた モデル、ビジネスロジックがあってそれをMVVMで使う場合どうすんの?ってことなんだろうけど
もう一層外からくるんだだけじゃうまくいかないからほとんどを作り直しすることになるんじゃないかな?
- 787 :
- >>783
何日も前のに突然どうしたw
>>785
MMV間は好きにすればいいかと
自分はわざわざMでINotifyPChangedなんか使わんけど
- 788 :
- 俺なんかMVCすらよくわかんないな
Webは兎も角、それ以外はMVCだと言われてるアプリを見てもCからVを書き換えてるのだらけに見えちゃうんだな
これでいいんか?それとも世の大半が間違えてるのか?どっちなんだ
- 789 :
- Cからvだけでしかないってのはダメだと思うが、結局その場合にちょうどいい程度に疎結合になってればいいと思うけどね
自分はMVにロジックも詰め込んで、でかくなってきたらMにする程度でやってる
- 790 :
- いつも疑問なんだけどMVVMでダイアログ表示するときなんでVMでShowDialog()しちゃいかんの?
MessengerでViewに送ってコールバックでってやるよりもVMをDataContextにぶっこんで直接操作したほうがわかりやすくない?
- 791 :
- >>790
MVVMのVMは、UIへの依存を排除することを試みるパターン。
なので、直接呼んで良いかと問われればNo
UIの知識に起因する処理を行いたいのであれば、UIから提供されたインターフェースを介してUI操作を行うMVPの採用を検討する。
結局のところ、MV*の違いは責任範囲の違いだけであり、MVPがMVVMよりV寄りに広いパターンなので、MVVMをベースにMVPにしても構わない。
ただしその場合、混乱の元なのでMVVMとは呼称すべきではない。
- 792 :
- >>790
ぶっ込んで直接操作が何を指してるのかわからん。
そのダイアログを表示がらみだと思うけどもうちっと具体的に言ってくれ。
元のViewと対応したVMがあったとして、そこからダイアログ表示させる場合でいいんだよね?
- 793 :
- >>792
すまん、説明が悪かったかも
あと無意識にWPFを前提に話してしまっていた
MainWindow
MainWindowViewModel
MainWindowModel
DialogWindow
DialogWindowViewModel
があったとしてMainWindowのボタン押下をトリガーにDialogWindowを表示したいとする
でWPFの昨日でVMにコマンドバインディングしていたボタンの処理の中で
DialogWindowのDataContextにDialogWindowViewModelを入れる
→MainWindowViewModelの中でDialogWindowのインスタンスを生成する
みたいな感じ
- 794 :
- VMからVを直接生成するのは禁じ手かと
てスタビリティーが担保できない
- 795 :
- 7年前から何も状況変わってなくてワロス
- 796 :
- https://teratail.com/questions/74961
わからないやつは使うな!
でほんとに使わなかったケースが多かっただけみたいだな
ユーザーの質がほんとひどい
難しい案件でだけ使えばいいがな
- 797 :
- 自分は自分で作るちょいアプリでも使ってるけどな
といってもVM膨らませてMもそこでやってて、ややこしくなったら分離させてるだけだけど
- 798 :
- WPF+MVVMはテストがつらい
M、VMでテストが出来てても実際にVでうまく動くかは全然わからない
- 799 :
- >>798
ん?それほかのUIフレームなら出来るん?
- 800 :
- アプリケーションのテストとしてはVM-M間で十分だと思うがな。
V-VM間はデータバインディングが意図通りか確認する程度だし。
少なくともFormsよりだいぶUIに近いところまで自動テストできるようになった。
- 801 :
- >>798
ViewはMVの状態をそのまま表示するだけってのが理想だからね
セレニウムだっけ?WEBでのUIテスト出来る奴とかあるかもだけど、自動テストでそこまでの工数かけるのちときつくね?
VMのテストならプログラム的にしやすいからまだわかる
- 802 :
- >>698
バカには使えないありがたいアーキテクチャなので
普及とかはどうでもいい話だった
- 803 :
- VisualWorksのPluggable MVCとどう違うのだろうか?
- 804 :
- Pluggable MVCとはだいぶちがうだろう
Application Modelの間違い?
- 805 :
- >>804
ValueHolder、AspectAdaptor、PluggaleAdaptorとか
- 806 :
- ああ、そういうことか
もっと古典的でプリミティブなものを指しているのかと思った
http://aokilab.kyoto-su.ac.jp/documents/MVC/page4.html
- 807 :
- 結局、ビュー寄りのモデルを作るという発想は90年代初頭にVisualWorksで提唱されていたんじゃないかと。
- 808 :
- まあその結論で合っているんだけど
ただValueHolderとかのアダプターはあくまで
ApplicationModelのプロパティでデータバインドを実現するための道具に過ぎないので
https://matarillo.com/general/uipatterns.php#p3
MVVMとの類似性に言及するのであれば
Pluggable MVCではなく「ApplicationModelアーキテクチャ」と表現する方が誤解が無くてよいと思う
http://wiki.c2.com/?ModelModelViewController
- 809 :
- もともとMVCとかでごちゃごちゃしてきたところにMVVMってことなんだろうな
デスクトップアプリに当てはめるのは微妙だったよ
- 810 :
- いやそういう基本的な理解の欠如ではない
- 811 :
- デスクトップに当てはめるのが微妙ってのは何だ?仮想Dom的なものがあればおさまる話?
あとMVVMはMVCを改良したってよりもXAMLのバインディング気候に合わせたって側面の方が強いと思うがな
それを改良と言えばそうだけど
- 812 :
- もしや810はMVCとMVC2を混同してるとか?
- 813 :
- 実装者の能力不足が問題になるということは設計パターンが悪いんだろ
本当に理解してるか確認するが難しいようなのもダメだ
- 814 :
- バインディングで楽が出来れば、それで満足よ
- 815 :
- >>814
楽できるかどうかじゃなくて、
画面を直接触らずに済むかどうかの問題だろ。
- 816 :
- こりゃ天才ですわ
https://qiita.com/hiki_neet_p/items/e381c687b0644c0e4978
- 817 :
- 暇だから数年ぶりにWPFでも触ってみようかなと思ってるけど、
乱立してた結局MVVMライブラリって結局何かに統一された?
Livetは死んでしまったみたいだねw
個人的には応援してだけど
- 818 :
- >>817
統一されたかどうかは分からんが、
https://github.com/XamSome/awesome-xamarin/blob/master/README.md#mvvm
によると、ReavtiveUI, MVVVCross, Prismあたりが人気らしい
- 819 :
- >>818
typo
x MVVVCross
o MVVMCross
- 820 :
- 【出資】松本卓朗 人工知能詐欺【注意】
https://rio2016.2ch.sc/test/read.cgi/rikei/1560859403/
- 821 :
- むっちゃ初歩的なところの質問になってしまうのですが、
WPF + Prismの環境で、画像ファイル(png)をウインドウ内にタイル状に並べたいのですが、
単体でパスをSourceに指定して、Converterを通して表示、までは出来たのですが、
これをListView上でおこなおうとすると、ListviewにBindingしているObservableCollectionにAddしても、
画像が表示されません。
何かわかりやすいサンプルや、チュートリアルなどありませんでしょうか?
- 822 :
- >>821
チュートリアルは知らんが、リストにテキストやボタンは表示できるの?
出来るなら今単体でコレクションの要素とビューテワやってる関係を同じようにするだけだけど
- 823 :
- >>821
ListViewのTemplateをGridViewとしDataTemplate使うんじゃなかった? よく知らんけど。
- 824 :2019/11/01
- >>821
どんな見た目作りたいの?
【会津】パソコン甲子園2004【若松】
a4です。P2P人工知能「T」開発。
GCは失敗。メモリは自分で管理せよ! その2
【PHP】下らねぇ質問はここに書き込みやがれ 10
オブジェクト指向の活用方法を教えて下さい
Pythonのお勉強 Part56
Android開発質問スレ
文字コード総合スレ Part12
集合論に基づいた言語を作りたい
国産オープンソースDIコンテナSeasar2 その16
--------------------
男性向け・女性向けの違いについて語るスレ 131
おすすめの落語のCD/DVD 2枚目
安くてどこにでも売っている芋焼酎 11合目
【質問】同人板アンケートスレ33【複数回答】
精子婆について語ろう★13
FFvsドラクエvsテイルズvs他 どれが本当の糞シリーズ? Part15
【コカ】レモン→バニラ→○○コーラ?【ペプシ】
FS2002〜★珍機体〜★珍リペイント 紹介スレ
【NFL】49ersについて語ろう Part4
30代のファッション2
隣(の)人9
シリコンハイドロゲル総合スレ
■■ビルメンランキング Part2■■
【次々販売】きもの松葉★5着目【呉服・着物・奈良】
生駒が乃木中で語ってたダンスがどうたらって結局なんだったんだ?
軽自動車はエコカーだ
モーリー・ロバートソン「日本の自衛隊が治安維持のためデモ隊に銃口を向ける。そんなことないですよね?」 ネット「暴徒で有れば… [Felis silvestris catus★]
絡みスレ@同人板759
あの人の事本当に無理になってしまうオフ Part2
【硬貨・紙幣】貨幣コレクション・その18【古銭】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼