12/11/02 14:00:24.51 .net
Mや各種サービスからのコールバックに使うとか
コードビハインドでVからVMのメソッドを呼ぶときにV->VMを密結合させたくないとか
そういうときには意味ある
391:デフォルトの名無しさん
12/11/02 14:32:57.66 .net
まあ通常は継承ベースでいいと思う
392:デフォルトの名無しさん
12/11/04 22:35:06.98 .net
>>383
コードビハインドってViewって認識なの？
否定じゃなくて単純に質問。
393:デフォルトの名無しさん
12/11/04 22:49:04.80 .net
Viewとみなすのがふつう
ビヘイビアもコードビハインドの一形態なので同じくView
394:デフォルトの名無しさん
12/11/05 20:21:18.14 .net
結局
vmに置かれるviewに強く関係するけど
共通ロジックの置き場がない
395:デフォルトの名無しさん
12/11/05 23:16:15.79 .net
共通ロジックならUTILとかに置けばいいだろ？
396:デフォルトの名無しさん
12/11/05 23:36:53.45 .net
>>386
Viewとみなすのは分かったんだけど
VMじゃななくてVとみなす理由はなんなのかな？
397:デフォルトの名無しさん
12/11/05 23:38:49.26 .net
>>389
ビューと不可分だから
398:デフォルトの名無しさん
12/11/05 23:45:04.35 .net
>>390
WinFormsのコードビハインドなら不可分といえなくもないけど
WPFはそうともいえないんじゃね？
399:デフォルトの名無しさん
12/11/05 23:51:07.82 .net
>>391
この場合の不可分は「単体テスト可能かどうか」な。
ユーザーコントロールやウィンドウのクラスに対してXAMLを差し替えることは普通はできないし
無理矢理読み込むファイルを変えたとしてもコードビハインドからコントロールを直接触ってるから
結局ビューを表示して実際に操作してみないとテストできないわけ。
だからコードをビューから分離してビューなしでテストできるようにしましょうっていうのがVM。
400:デフォルトの名無しさん
12/11/06 00:03:14.09 .net
>>392
なる
401:ほどねー
402:デフォルトの名無しさん
12/11/06 00:05:46.84 .net
>>387
ViewModelsってフォルダにそういう機能のクラスを作ればええんや
まーそもそも、Views、ViewModels、Modelsってフォルダ群もなんだかなーって気もするが
そのほかのフォルダ構成でやってるやつおる？
403:デフォルトの名無しさん
12/11/06 03:50:39.94 .net
フォルダ分けない方が楽な気はするがその3つにしてるな
404:デフォルトの名無しさん
12/11/06 15:16:09.04 .net
М氏も「MVVM＝コードビハインド無し」みたいな誤解撒き散らしてたし
「フルMVVM」って造語が誤解生んだのも事実
でもだからなんなの？勝手に誤解してずっこけたの本人のせいじゃん
お前が元信者だから裏切られた感強いだけだろ
405:デフォルトの名無しさん
12/11/06 16:34:58.61 .net
dynamicを積極的に使うのはどうだろう
VMがdynamic型でVへの参照を保持して動的にVのメソッドを呼ぶようにすれば、
メッセージやインターフェイスを介さなくてもVM->Vの密結合が避けられる。
dynamicなら完全に透過的なプロキシが使えるから、たとえばメモリリークの恐れがある箇所は
WeakReferenceでビューへの参照を持ち、ビューがGCされたらnullオブジェクトとして振る舞う
ようなプロキシを利用すれば、メモリリークの問題もコードの見た目を全く汚さずに解決。
型無しがダメだというならメッセージだって同じようなもんだよね。
(Vが当該メッセージをサポートしているかどうかはコンパイル時にチェックされないという意味で)
406:デフォルトの名無しさん
12/11/06 17:03:56.14 .net
マルチキャストが必要な場合(メモリリークを避けるためにイベントを置き換えるとき)もこんな感じで
class HogeModel {
//弱参照で複数のリスナへの参照を持つ複合プロキシ
private WeakCompositeProxy listeners;
public void AddListener(dynamic listener) { listeners.Add(listener); }
private void RaiseSomethingHappened() {
//登録された全てのリスナのOnSomethingHappenedメソッドを呼び出す
//リスナがOnSomethingHappenedメソッドを持たない場合は何もしない
((dynamic)listeners).OnSomethingHappened();
}
}
407:デフォルトの名無しさん
12/11/09 04:16:24.83 .net
MVVMってメトロになってもやること変わらんの？
技術的にはあっちが本流だと思うんだけど
408:デフォルトの名無しさん
12/11/09 09:11:57.38 .net
どうしてデザパタが環境によって変化すると思うんだｗ 技術じゃないぜ。概念だろ。
409:デフォルトの名無しさん
12/11/09 10:13:41.46 .net
この手の概念って「ある一定の規則とか法則に名前をつける」
だけの話だからね。
410:デフォルトの名無しさん
12/11/09 11:31:24.11 .net
コーディング段階は結構変わるがな
411:デフォルトの名無しさん
12/11/09 22:45:20.26 .net
>>401
概念の話と
概念に名前をつけるって
話がごっちゃになってるよ。
概念に名前をつけるのは重要なことだが、
もちろん概念そのものも重要なことだぞ。
412:デフォルトの名無しさん
12/11/11 00:32:37.19 .net
すいません、よかったら教えてください
MVVM Light Toolkitで遊んでるんですが、テンプレートから作成されるModelの
IDataServiceのメソッドがActionを渡して結果をコールバックさせる形になっています
普通に戻り値や例外を返せばいいと思うのですが、あえてコールバックさせているのはなぜなんでしょう？
考えても理由がちっとも思いつかないので、もしわかったらお教えください
よろしくお願いします
413:デフォルトの名無しさん
12/11/11 00:36:08.24 .net
>>401
MVVM以前からMVVM的な物が存在していたということ？
414:デフォルトの名無しさん
12/11/11 00:40:40.06 .net
>>404
処理に時間がかかる場合にGUIが固まるのを防ぐためだろ
Webからデータを取ってくるような場合は言うまでもないが、
ローカルなファイルやデータベースからちょっと取ってくるくらいでも結構固まる
415:デフォルトの名無しさん
12/11/11 00:53:11.62 .net
>>406
それはasync、awaitの非同期処理はModel内部で行ってServiceのメソッドをasync宣言しない方がよい
ということでしょうか？
Serviceのメソッド自体が非同期メソッドであれば画面が固まったりしないですよね？
そこら辺も初めてさわったのでトンチンカンなこと言ってたらすいません
416:406
12/11/11 00:56:51.28 .net
あ、MVVM Light Toolkitは別にasync、awaitのサポート環境を限定してないからかな？
逆にいうとasync、awaitが使える環境ならば別にコールバックさせる必要はないってことでいいんでしょうか？？
417:デフォルトの名無しさん
12/11/11 00:57:16.17 .net
>>407
いやMVVM Light Toolkitは結構昔からあって、当時はasyncが無かっただけ
U氏はasyncは内部で使うものであってインターフェイスに使うなとか
思い込みだけで頓珍漢なことを言ってたが
今からasync前提で作るなら普通に使っていいよ
418:406
12/11/11 01:01:22.02 .net
>>409
なるほど、納得しました
サービスレベルでasyncにしてコールバックは利用しない方法でいってみます
いろいろありがとうございました
419:デフォルトの名無しさん
12/11/12 00:22:58.42 .net
>>409
うがやは、C#というか言語や.NETに関して知識なさすぎだからな。
ライブラリ設計者としてのセンスもない。
420:デフォルトの名無しさん
12/11/12 20:04:14.60 .net
MVVMでユーザコントロール使う場合のお作法？で質問があります
Page内に異なるユーザコントロールが2種類AとBがあります
Aはリストを表示するコントロールでBはその明細を表示するコントロールです
AとBにはそれぞれ専用のVMを作ってバインドしています
この時、A内のリストで選択されたものをBに渡したいのですがどう実装するのがスマートなんでしょうか？
現在は、PageのVMの中にAVMとBVMを保持していて、AVMのPropertyChangedイベント
をPageのVMの中で拾ってBVMのプロパティに設定しています
が・・・なんかいまいち感が
他にいいアイディアってあるのでしょうか？
421:デフォルトの名無しさん
12/11/12 20:12:25.87 .net
ListBoxのItemsSourceにVMたくさん入ったコレクションセットして
ContentControlのContentか任意のViewコントロールのDataContextにListBoxのSelectedItemをバインドするのが楽じゃね
422:デフォルトの名無しさん
12/11/12 21:01:20.01 .net
あぁそっか、そういうやり方があるんですね
勉強になります
ありがとうございました
もしよかったらもう一つ教えてください
実はAで選択されたItemをまた別のコントロールに今度は単一を設定するのではなくて
どんどん追加もしたいんですが・・・
そういう場合はどうするのが良いのでしょうか？
一つ一つの機能は徐々にわかってきたんですが、合わせ技になると発想がついてこないっす
423:デフォルトの名無しさん
12/11/12 21:01:56.33 .net
SelectedItemは同意だけど、VM自体はPage用1つだけでいいと思う
「AB両方の表示用を子プロパティとして持つクラス」のコレクションを
VMがプロパティとして公開して、Aがそれにバインド、
BがAのSelectedItemにバインド、が一番すっきりかな
424:デフォルトの名無しさん
12/11/12 21:14:21.92 .net
>>415
なるほど、そういうやり方もあるのか
そこで一つ疑問が出てきてしまったんですが・・・
WebでMVVMのユーザコントロールのサンプルをいくつか見たところ
たまたま？すべてのサンプルがユーザコントロール毎に定義されていて
それを鵜呑みにしてたんですが・・・
親になるビューだけがVMを持つのとコントロールも独自にVMを持つケース
どういった感じで使い分けたらいいのでしょうか？
ちなみに今回の場合、AもBも表示するだけではなくて、それなりに個々の
コントロールに機能を持っています
Aはソート順を変えたり絞り込んだり、Bは詳細を編集したりなどです
425:デフォルトの名無しさん
12/11/12 23:25:58.38 .net
426:>>416 俺は複数のWindowでControl使いまわしてるから、Controlに専用のViewModel持たせてるよ
427:デフォルトの名無しさん
12/11/13 00:54:12.58 .net
Model側でコレクションを持つ場合、そのVMも子ModelのVMのコレクションを持つようにしてるかな
この場合Model側もObservableCollection的な通知機能付コレクションを使うことになるが
子ModelがVM持つほどの意義がない場合は親Modelのコレクションそのまま使ったりもする
428:デフォルトの名無しさん
12/11/13 04:42:27.67 .net
414は単純に、「別のコントロール」側のItemsSourceになってるコレクションに
Addしてやればいいだけだと思う…
単純過ぎるので質問の意味取り違えてるかも知れないけど
416についてはケースバイケース
どうするのが、開発や保守しやすいか。それ次第でしょう
429:414
12/11/13 20:36:52.73 .net
昨日はレスいただいたのに返事できずにすみません
>>417-418
コントロールは再利用するつもりなので、今回はコントロールにVM持たせてみます
子もVMに入れてみようと思います
430:デフォルトの名無しさん
12/11/13 20:43:05.86 .net
>>419
1. ItemSourceになっているコレクションに誰が値を入れるべきか？
2. ItemSourceは誰が持つべきか？
の2点で悩んでいました
Page AとBを持っている親Window
A 全てのオブジェクトをリスト表示するコントロール
B Aで選択されたものを1つずつ追加してリストに表示するコントロール
となっています。
ABはそれぞれ再利用を考えているため、個別のVMを持ち、子のVMは親のVMが持つ事としようと考えています
なので2.についてはBで持つ事にしようと思います
まだ悩んでいるのは1.でして、今のところの実装は
1) AのListのSelectedItemをAVMのプロパティにバインド
2) PageVMでAVMのPropertyChangedイベントをハンドリング
3) PageVM内のロジックでBVMで定義したAddItem（自作）を呼び出す
4) BVMのAddItemメソッドないでObservableCollectionに追加
としています。
この中の2)の部分が特にしっくりこなくて気持ち悪いというのが、質問させていただいた経緯です
431:デフォルトの名無しさん
12/11/13 21:27:06.52 .net
>>421
あまり参考にならないかもですけど、
もし俺が、そういうPage,A,Bの3つのVMでやるとしたら
Aのコンストラクタの引数で、デリゲートを受け取れるようにしておく
AではPropertyChangedのハンドラで、その受け取ったデリゲート呼ぶようにしておく
PageからA,Bをインスタンス化する際に、
BのAddItemを呼び出す処理や、Pageでやるべき処理もあればまとめて、
Aのコンストラクタに全部、ラムダ式で渡す
これで後は、AのPropertyChanged内だけで、PageやBの処理も全て完結
って感じにするかな…。
432:デフォルトの名無しさん
12/11/13 21:40:19.58 .net
>>422
ふむふむ、なるほど
レス読ませてもらって考えているうちに思ったんですが、AVMにItemが選択された
ことを通知するイベントを定義して、そこにラムダ式突っ込んであげれば良いのかな？
って気がしてきました
何が気持ち悪かったって、AVMにはほかにプロパティもあるわけで、PropertyChangedを
ハンドルしていると、別にPageには興味がないプロパティも飛んでくるわ
プロパティの名前をAVMで定数定義してAVMからもPageVMからも参照しようとすると、
MVVM Light ToolkitでVMのインスタンスを生成するときにエラーで落ちちゃって
プロパティ名をAとPageの双方に文字列で指定してた所なんで、一番キモイ所は解決された気がします
ただなんか手法が古臭いような気がしないでもないですがｗ
XAMLでこう書いてああ書いてすればサクっとできちゃうよ！的な解決策はさすがにないですよね？ｗ
433:デフォルトの名無しさん
12/11/13 23:15:36.04 .net
@ugaya40: 難しいとかいってる人はコードビハインドでMVVMしましょ
コイツ、MVVMでコードビハインド使うのはMVVMを理解していない無能のすること とか散々ほざいてたくせしてなに言っちゃってんのって感じなんだが。
「難しいとか言ってる人」とかつけ加えてて誤魔化してんじゃねーよ。
難しいとか難度の問題じゃないってわかんねーのかな？
434:デフォルトの名無しさん
12/11/13 23:18:09.19 .net
コードビハインドを使用したものは神の怒りに触れ
永久にメモリリークの責め苦を受けるんじゃなかったのかw
435:デフォルトの名無しさん
12/11/13 23:23:22.77 .net
テンプレートにハンドラつけた場合じゃねそれ
436:デフォルトの名無しさん
12/11/13 23:28:45.74 .net
自作のライブラリーをコードビハインドに対応させるって言ってたし完全に方向転換したんじゃないのかな？
それ自体はいい事だとは思うけどね
ただ、間違った持論でMVVMの概念をめちゃくちゃにした罪は大きいよね
きちんと間違ってたことを認めればいいけど、あの歪んだ性格じゃ無理だろうな…
437:デフォルトの名無しさん
12/11/13 23:33:30.98 .net
必死にPSDって略語を流行らせようとしてるのに誰も使ってないのが泣ける、というか笑えるｗ
438:デフォルトの名無しさん
12/11/13 23:39:32.37 .net
PDS言ってるのは知ってるがPSDは知らんな
439:デフォルトの名無しさん
12/11/13 23:40:55.84 .net
DPSならしってる。全部知ってる。DPS全部
440:デフォルトの名無しさん
12/11/13 23:43:51.07 .net
社内ではよく使うがネットで使う機会が無い
441:デフォルトの名無しさん
12/11/13 23:45:32.47 .net
本人もあれだけど最近はアンチのがウザいな
直接煽られたことある人はそうなるのか
442:デフォルトの名無しさん
12/11/13 23:50:31.04 .net
面白がってアンチに乗じてアンチごっこしてるやつが一番うざいし役に立たない
443:デフォルトの名無しさん
12/11/14 00:37:00.22 .net
MSの将来が不安なのでAndroidのMVVM環境教えてください
444:デフォルトの名無しさん
12/11/14 00:42:27.62 .net
JavaScriptでよければ
KnockoutがMVVMのフレームワークだよ
445:デフォルトの名無しさん
12/11/14 00:47:11.25 .net
Androidでバインディングは無理だと思う
コントロールがそれぞれ独自にXML読むクソ設計なんだぜ?w
446:デフォルトの名無しさん
12/11/14 00:59:28.17 .net
AndroidのフレームワークでバインディングやるならActivityのコード側でsetBindingみたいなメソッド呼んで
実装はリフレクションで頑張るしかないだろうけど
そんなことするくらいならPassive Viewの方がいいと思う
447:デフォルトの名無しさん
12/11/14 01:13:42.40 .net
さすがに今年中にBlend出してくれんとしんどいわMSさん
448:デフォルトの名無しさん
12/11/14 01:24:18.30 .net
Expression Studio 5まだー？
449:デフォルトの名無しさん
12/11/14 02:03:13.02 .net
android binding があるでしょ
450:デフォルトの名無しさん
12/11/14 21:26:33.41 .net
@ugaya40: 俺はWin8デスクトップにはスタートメニューが必要だと思うけど、シノフスキーさんの辞任と現時点で結びつけたりするわけもなく。ただその反対意見もまた極端なのが散見してるな。どっちもアホじゃないですか。
散々、極端なことを言ってたのはお前だろ？ｗ
自分で自分がアホって自覚がちゃんとあるんだな。
451:デフォルトの名無しさん
12/11/14 21:27:50.23 .net
>>426
メモリーリークするの？
メンドクサイからテンプレートから呼ぶようにしたんだけど・・・
452:デフォルトの名無しさん
12/11/14 21:49:40.33 .net
>>441
お前さん､うがやのこと大好きなんだな
453:デフォルトの名無しさん
12/11/14 22:08:23.42 .net
そのうちVSスレのキチみたいに発狂しちゃうんだろうな
454:デフォルトの名無しさん
12/11/14 22:12:55.52 .net
さすがに粘着が過ぎる
455:デフォルトの名無しさん
12/11/14 23:17:24.64 .net
まぁ、こういう個人攻撃はネットウォッチ板でやるもんだな
456:デフォルトの名無しさん
12/11/15 10:53:44.15 .net
>>442
そんなことでリークするわけない。動的に生成された要素は、XAMLでイベントハンドラが登録されたままでも
ツリーから外れた時点でGC対象になる。XAMLではなくコードビハインドなどから追加した場合は当然
WPF管理外のため、イベントハンドラによる強参照が当然残るのでそれがマズい場合があるだけ。
つまりWPF自身の問題などでは決してなく、あくまで愚かな人間によるミス。
例の宗教はあえてそのあたりをぼかす(信者の多くはそもそも理解してないまま復唱�
457:ｵてるだけだろうが) ことによって恣意的なイメージ操作を行っている。
458:デフォルトの名無しさん
12/11/15 10:57:08.02 .net
そもそもWindow自体を解放する手段ないだろ
459:447
12/11/15 11:01:14.57 .net
ItemsTemplate/DataTemplateの中のコントロールのイベントに対して
コードビハインドのイベントハンドラを登録したときの話な
試してみたら分かるが、要素を削除した後にGCが走れば
ちゃんとコントロールのファイナライザが呼び出される。
460:デフォルトの名無しさん
12/11/15 11:25:23.41 .net
メッセージに応答してダイアログを開いたりする汎用的なビヘイビアって本当に必要?
VMからダイアログ開きたいんだったら、IoCでVMからIOpenFileDialogServiceのような
インターフェイスを通してメソッドを呼び出せばいいだけの話だと思うんだけど。
わざわざメッセージ投げてVで処理するなんて複雑だしXAMLも無駄に汚れるしタイプセーフじゃないし。
特定のビューでしか使わないようなサービスにするまでもない処理ならメッセージもアリだと思うけど
その場合ビヘイビアにする意味はなく(再利用しないんだから)、コードビハインドで受けて処理すればいい話だよな。
461:デフォルトの名無しさん
12/11/15 17:05:54.35 .net
テスト
462:デフォルトの名無しさん
12/11/15 20:05:32.67 .net
行き過ぎたBlend主義。
俺もサービスにするかな。
463:デフォルトの名無しさん
12/11/15 22:36:46.09 .net
VMからのメッセージでアニメーションを開始させたいときなんかにはビヘイビアが便利かも
と思ったけどそんなビューの細かいことをVMで意識するのも本末転倒な気がするな
そこはメッセージとXAMLは直接繋がないと割り切った方がいいのかも
464:デフォルトの名無しさん
12/11/15 22:46:23.39 .net
俺はビヘイビアで済ませたほうが楽かな
465:デフォルトの名無しさん
12/11/15 22:52:24.24 .net
Livet教のMVVM…ドカタMVVM
IoC使うPrism系のMVVM…JavaっぽいMVVM
466:デフォルトの名無しさん
12/11/15 23:15:07.41 .net
MVVM Light…光のMVVM
467:デフォルトの名無しさん
12/11/17 00:05:50.69 .net
よく話にでるlivetってライブラリ落としてみたけどクラス名にまでlivetって入ってんのね。
ダサすぎる。
468:デフォルトの名無しさん
12/11/17 00:08:09.15 .net
てゆーか、9割以上がPrismとMVVM light toolkitのパクリコードってのはどうなの？
Ugayaはずいぶんえらそーなことを言ってたがただのパクリライブラリじゃんか。
469:デフォルトの名無しさん
12/11/17 06:32:58.08 .net
そうだなC#はJavaのパクリだもんな
つーかソース見たことはないが本当にパクリなら大問題だしそれならここで言ってないで大々的に批判すればいいんじゃないか
470:デフォルトの名無しさん
12/11/17 09:52:41.30 .net
>>459
見ればわかるがおおざっぱに言えばLivetの独自部分でメソッドキャッシュとT4コンバーターぐらいじゃね？
C#っつーか.NET Frameworkだろ
1.0のころはパクリだったんじゃないの？
実際Javaがなければ今と同じ1.0は生まれてなかった
471:デフォルトの名無しさん
12/11/17 10:11:39.47 .net
なんだコード盗用とかじゃなくて概念の話だったのか
472:デフォルトの名無しさん
12/11/17 11:07:14.48 .net
>>461
>>458はコードと言ってるな
473:デフォルトの名無しさん
12/11/17 12:09:36.74 .net
>>461
綺麗に言えば、車輪の再発明？
ぱくりライブラリと言われても仕方がない代物ではある
何を目的にやってるのか分からないところもあるし
インフラを乱立させたって混乱するだけだし
ドキュメントやサンプル充実させて裾野を広げるってわけでもないし
尾上が自身の狂った思想から少しでもずれてる意見を発見すると
死ぬまで粘着されるしな
尾上は自分が日本での唯一のMVVM啓蒙者になるために
他人がおいそれと語れないようにしてるだけ
完全に癌でしかない
474:デフォルトの名無しさん
12/11/17 12:14:26.42 .net
MVVMの土台として画面遷移は極めて重要だと思うが、そこがいい加減なのはいただけない
同期ダイアログによる遷移のみってWinFormsかよw WinRTじゃそんなもん使えないぞ?
475:デフォルトの名無しさん
12/11/17 12:30:02.96 .net
>>464
MVVMはMSが本気で取り組まない限り無理。
言語、.NET Framework、IDEが三位一体で対応しないと今はまだ欠陥が多すぎる。
476:デフォルトの名無しさん
12/11/17 12:38:05.90 .net
>>465
WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
IDEでどうするもんでもないだろう
Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
477:デフォルトの名無しさん
12/11/17 13:33:39.79 .net
U氏に親殺されたやつ多すぎだろ
478:デフォルトの名無しさん
12/11/17 14:04:28.46 .net
>>467
叩かれてる奴に「氏」付けるのは本人だけ
ってだいぶ前に小学生の妹が言ってたよ。
479:デフォルトの名無しさん
12/11/17 14:08:17.71 .net
画面遷移についてはMVVMと絡めてもっと真剣に議論されるべきだと思うぞ?
U氏関係なく。自称MVVMインフラではたいてい完全スルーされてるが(Livetでもおまけ程度)
どうしてもインフラ的なコードを書くことになる部分だし、MVVM使ってるなら画面遷移の設計も
それに強く影響されることになる。
480:デフォルトの名無しさん
12/11/17 14:08:19.65 .net
>>466
> WPF自体は様々な画面遷移のシナリオを実現するのに十分な機能を備えてるし、
WPFの話じゃなくてMVVMな
> IDEでどうするもんでもないだろう
IDEにどれだけ恩恵受けてるかわかってないの？
MVVMだってフレームワークだけではどうにもならないことがある
> Prismは画面遷移かなり頑張ってるぞ? というか画面遷移をまともに扱ってるのはPrismだけ。
Prismがもっと使いやすく標準で.NET Fxに乗らないと無理ってこと
481:デフォルトの名無しさん
12/11/17 14:44:14.95 .net
コードビハインド前提のMVVMフレームワークが出てきたら少しは前進すると思う。
Livetがダメなのは作者がコードビハインド完全否定してることと
>>458が言う通り、既存フレームワークの単なる2番煎じで
MVVMの問題点を克服するものではないから。
コードビハインドいいと思うんだけどな。
うがやのサイト見ていると分業とか書いてるが
Vをデザイナーに別注してるチームってあるのか。
デザイナーとデベロッパーの分業なんて幻想じゃないのかな。
XAMLをフルに理解してるデザイナーなんて一人もいないと思うよ。
482:デフォルトの名無しさん
12/11/17 14:57:27.23 .net
>>471
その点に関してはすでに奴は考え改めてコードビハインドの有無はどうでもよくなってるみたいだぞ
483:デフォルトの名無しさん
12/11/17 15:03:53.77 .net
VMの処理中にユーザの入力を求めたくなった場合とかかね画面遷移は
ぶっちゃけどのライブラリも何かあるたびにクラスやらインターフェイスやら増やさないとならなかったりして面倒だわ
MSはMVVMを推奨するんならASP.NET MVCくらい充実させるべき
484:デフォルトの名無しさん
12/11/17 16:41:52.99 .net
>>473
そういう遷移はビューだけで完結するのでほとんどMVVM関係ない。
ビューの実装の詳細だ。
設計に大きく影響するのはVMごと遷移するやつな。
485:デフォルトの名無しさん
12/11/17 17:27:45.79 .net
具体的な例で言ってくれよ
486:デフォルトの名無しさん
12/11/17 17:34:46.35 .net
例も何も、無理にVMくつけなきゃ 一覧画面 <-> 編集画面 とか大概の画面遷移はVMごと遷移だろ
ダイアログベースならそんなに意識しないだろうけどさ
487:デフォルトの名無しさん
12/11/17 17:43:10.77 .net
それならDataContextにVM突っ込んでもらうだけでよくね
488:デフォルトの名無しさん
12/11/17 17:54:24.04 .net
そのコードをどこに書くのかとかいろいろ問題があるよ
本来、一覧画面VMで 画面遷移しろ("編集ビュー", selectedItemId); だけで済むはずで
一覧画面のVMやVが遷移先の画面のVやVMのクラスを知っている必要は全くないけど
そう書けるようにするためには結局インフラがいるんだよね
489:デフォルトの名無しさん
12/11/17 18:03:52.82 .net
railsのscaffoldみたいにサクッとアプリを作れるようなインフラが欲しい・・・
490:デフォルトの名無しさん
12/11/17 19:28:02.12 .net
>>472
どうでもいいわけないよね？
氏のMVVMサイト見てくれば。
491:デフォルトの名無しさん
12/11/17 20:46:12.52 .net
プロ粘着なら奴のツイッターも観察すべき
492:デフォルトの名無しさん
12/11/17 23:51:38.42 .net
>>481
前はフォローしてたんだけどね。
自分とちょっとでも意見が違うと噛みついて粘着のパ�
493:^ーンが多すぎて ずいぶん前にフォロー解除したよ。 あの人ちょっとアスペ入ってるよね。 ちょっとというかかなり。 高卒で会社員経験なし、ってとこで人間の底が知れるわ。
494:デフォルトの名無しさん
12/11/18 00:01:26.49 .net
と２ちゃんねるで批判するガキｗｗｗ
495:デフォルトの名無しさん
12/11/18 00:03:44.32 .net
>>483
ugayaの負けず嫌いもここまで来ると褒めたくなるなｗ
せっかく社会人になれたんだから2chで自演擁護とかやめたら？ｗｗｗｗｗ
496:デフォルトの名無しさん
12/11/18 00:09:01.67 .net
>>484
まともな社会人は多少の煽りには反応しねーんだよ
お前みたいな無職のクズとは違うんだよ
分かったらとっとと寝ろ
497:デフォルトの名無しさん
12/11/18 00:11:32.55 .net
ugayaは2chの煽りにtwitterやブログでキレまくってたけどなw
498:デフォルトの名無しさん
12/11/18 00:17:22.53 .net
>>486
いいから早く寝ろよ
499:デフォルトの名無しさん
12/11/18 00:20:54.13 .net
反応はしてたけど別にキレまくってたってほどじゃなかったろ
500:デフォルトの名無しさん
12/11/18 00:24:44.54 .net
MVPVMの(Uによる)煽りはひどかった
501:デフォルトの名無しさん
12/11/18 01:06:10.42 .net
お前ら本当に暇なんだな
文句があるなら一度でいいからGoogleの検索トップになってみろよ
U氏のサイトはMVVMで検索すると余裕でトップなんだが
502:デフォルトの名無しさん
12/11/18 01:10:17.68 .net
そんなんだと宗教に騙されるぞ
U氏も言ってるだろ? 「MVVMだからこうしなければならない」じゃなくて目的を考えろと
503:デフォルトの名無しさん
12/11/18 01:14:55.07 .net
>>491
自分の考えた最強の目的しか許さず
その目的を達成するにはこうするしかないと決めつける
そこから外れたツイートを見つけると相手が黙るまで粘着ツイート
相手が黙ると「都合が悪くなると無視かよ、これだからクズは困る」的なツイートで〆
尾上さんのそこにシビれる！あこがれるゥ！
504:デフォルトの名無しさん
12/11/18 01:15:09.27 .net
目的を考えろと言ってる本人が一番権威主義を煽ってる元凶という皮肉
505:デフォルトの名無しさん
12/11/18 01:19:48.67 .net
尾上を擁護してるのはいったい誰なの？
誰がどう見てもアスペルガーじゃん。
尾上にへこへこ媚び売って家畜に成り下がってる奴って
高野将かぐらばくぐらいなもんだろ？
506:デフォルトの名無しさん
12/11/18 01:40:50.56 .net
相手を擁護と認定してしまえばどんな誇大を使って過激に叩いても正当化できて安心だもんな
507:デフォルトの名無しさん
12/11/18 01:49:36.48 .net
文句があるなら同じMVVMの土俵で反論すればいいじゃないか。
このスレに持論を垂れ流すだけでも人格攻撃よりはマシだしまともな議論なら歓迎だぞ。
考え方に関してはここはわりとU氏に反発してる人が多いみたいだし(俺もその一人だが)。
508:デフォルトの名無しさん
12/11/18 07:01:25.21 .net
MVVMの思想に関してはいい加減多少は理解したから、
そろそろMVVMの実装について語って欲しいなぁ、
509:デフォルトの名無しさん
12/11/18 07:25:20.92 .net
とりあえずインフラ使っとけっていう風潮？って
MVVMじゃなくてMVVMライブラリの使い方を憶える事になる
危険性高い気がするのよね。
MVVMインフラが解決しているであろう、
様々な問題を自力で解決できるように成らないと
ほんとうの意味でMVVMやXAML環境を理解したとは言わない気がする。
MVVMの啓蒙者ならそのぐらいまでやってくれないと片手落ちだろって思う。
ところでMVVMインフラってどんな問題を解決してるの？
510:デフォルトの名無しさん
12/11/18 13:25:29.40 .net
コードビハインドのこともそうだしModelの責務の話もそうだけど
言ってることがコロッと変わるのはどうにかならないものなのか
なんか昨日もフォーカス制御をModelでとか唐突に言い始めるわけですよ
それが正しいかどうかは別として
ざんざん大声で他人を罵倒してまで言い続けてたことを
511: ちょこちょこ小出しでさりげなく路線変更してくる卑怯なところが俺が気に入らないところ といういか、それがうがやが叩かれる原因じゃね？
512:デフォルトの名無しさん
12/11/18 15:58:45.35 .net
>>499
やっぱ大学もいってないし、会社員としての経験もほぼ0でしょ？
どう考えても性格、人格が歪んでるというか問題があるんでしょう。
完全にアスペだよ、アスペ。
513:デフォルトの名無しさん
12/11/18 16:01:06.83 .net
お前アスぺの意味やその性質わからずに罵倒語として使ってるだけだろ
514:デフォルトの名無しさん
12/11/18 16:06:22.21 .net
人格の話は別の板でやれ。
515:デフォルトの名無しさん
12/11/18 16:17:28.34 .net
私怨ならヲチでやれ
516:デフォルトの名無しさん
12/11/18 18:51:48.91 .net
ここって元々WPFスレを正常化するための隔離スレッドだからいいんだよ。
便所の落書きスレッドで。
いやなら見るなｗ
by 岡村
517:デフォルトの名無しさん
12/11/18 18:59:24.39 .net
まあアスペには違いない
518:デフォルトの名無しさん
12/11/18 20:26:20.24 .net
尾上さんは
「日本でMVVMを正しく語れる人間は自分以外にいないッ！！」
って断言してたしスレ名を「尾上について語ろう」に修正してもよいと考えられる
519:デフォルトの名無しさん
12/11/18 20:52:02.11 .net
ここMVVMやってる奴はキチガイだらけという見本のスレか
520:デフォルトの名無しさん
12/11/18 20:58:34.33 .net
そもそもMVVMって何だよ
ぐぐってもクソみてーなサンプルコード乗せただけの記事しか出てこないしまともに概念を解説してるやついねーのな
コマンド(笑)とか冗長すぎてもうね
521:デフォルトの名無しさん
12/11/18 21:04:18.24 .net
わからないならこれでも勉強しろ
JavaScript製のMVVMフレームワーク「Knockout」
URLﾘﾝｸ(www.moongift.jp)
522:デフォルトの名無しさん
12/11/18 22:37:36.36 .net
>>508
尾上さんのサイト見れば簡単に理解できる。
簡単に言うとPDS的にコードビハインドを記述しないで開発する手法だよ。
523:デフォルトの名無しさん
12/11/18 22:40:25.76 .net
一応言っておくとPDSは一般的な用語じゃないから通じないと思うぞ。
524:デフォルトの名無しさん
12/11/18 22:41:17.17 .net
一般的にはフリーソフトで通じる
525:デフォルトの名無しさん
12/11/18 23:36:11.21 .net
>>511
自分が知らないことは一般的じゃないと考える根拠は何だろうね
自分の無知を晒しているだけと気が付かない人には何を言っても無駄ではあるが、助言だけはしておくかな
526:デフォルトの名無しさん
12/11/18 23:39:05.83 .net
Wikiにないから一般的じゃないと推定される
527:デフォルトの名無しさん
12/11/18 23:40:30.50 .net
どこのWikiだよ
528:デフォルトの名無しさん
12/11/18 23:42:35.17 .net
PDS
URLﾘﾝｸ(ja.wikipedia.org)
パブリックドメインソフトウェア(Public domain software)
かつてのドイツの政党である民主社会党(Partei des Demokratischen Sozialismus)。合併し、現在は左翼党 (ドイツ)に。
FTTHにおけるネットワーク構成（ネットワークトポロジー）の一つ。(Passive Double Star)
毛利元貞が考案した護身術パーソナルディフェンスシステムの略。
テレビ番組の制作会社の名称。PDS (制作プロダクション)を参照。
先駆動システム(Pre Driving System)
プラン・ドゥー・シー(Plan Do See) PDCAサイクルを参照。
アップルが採用していた拡張スロット。(Processor Direct Slot)
529:デフォルトの名無しさん
12/11/18 23:44:53.19 .net
海外
URLﾘﾝｸ(en.wikipedia.org)
530:デフォルトの名無しさん
12/11/18 23:48:19.69 .net
>>510
PDSという概念があるよということなら納得できる
ただしPDSという言葉が一般的というのは賛
531:同しかねる
532:デフォルトの名無しさん
12/11/18 23:51:14.50 .net
で、そのPDSとMVVMに何の関係が？
533:518
12/11/18 23:57:05.51 .net
MVVMは、XAML系フレームワークにおけるP(resentation層)の問題を解決するもの
その前提としてPとD(omain層)の分離がある
534:518
12/11/18 23:59:12.80 .net
とはいえこれはあくまでパターンであり、絶対の解法ではない
その証拠として、MicrosoftもXAML系コンポーネントベンダーもMVVMを推奨してないという事実がある
535:518
12/11/19 00:02:35.76 .net
WPF・Silverlight・RTの公式ドキュメントで、一ヶ所でもMVVM必須と謳っている箇所があるだろうか？
また国内だとGrapeCity・Infragistics等のベンダーがXAML系コンポーネントを販売している
これらベンダーのマニュアルにも、MVVMを必須・提唱しているドキュメントは全く見当たらない
536:デフォルトの名無しさん
12/11/19 00:07:49.16 .net
MがちゃんとしててVMはぺらっぺらになるのがMVVMの設計としては理想だからな
Web MVCではいくらぺらっぺらでもC無しというわけにはいかないが
VMがぺらっぺらになっていき、ついに無くなるのは別に問題ない
微妙に矛盾したパターンだよ
537:デフォルトの名無しさん
12/11/19 00:07:57.56 .net
そりゃ必須なわけがない
MSDNマガジンやChannel9とかで適度に触れられている程度だな
あと「推奨していない」だと非推奨と主張しているように聞こえるから注意だ
「触れていない」あたりでいい
538:518
12/11/19 00:08:10.96 .net
勘違いしてはいけないのは、パターンはあくまでパターンであり、絶対の解法ではないことだ
逆にパターンに振り回されてその本質を見失えば、返って障害が発生する場合もある
MVVMを使わずに開発できるのならそれでよし
539:デフォルトの名無しさん
12/11/19 00:09:31.95 .net
VMとテスト
540:デフォルトの名無しさん
12/11/19 00:11:53.87 .net
>>526
MがちゃんとしててMのテストだけで済むならそれに越したことはない
541:デフォルトの名無しさん
12/11/19 00:12:18.51 .net
>>524
どうかな？
「MVVMが必須」という誤ったイメージが蔓延し過ぎて参入障壁が上がり過ぎると
Microsoftや周辺ベンダーしては返って喜ばしくない事態になると思う
・・・いやすでになっているな
「触れていない」というより、いまとなっては「触れたくない」が正解だと思う
542:518
12/11/19 00:15:52.43 .net
かくいう私はどうかといえばMVVMは割と好きなパターンであるし、
実際これでかなり問題を解決できているのも事実だ
しかし、使えない、理解できない、開発速度が極端に落ちて苦痛に感じるくらいなら、
そこまで無理に使う必要もないと思う
543:デフォルトの名無しさん
12/11/19 00:28:44.37 .net
VMがわかりにくいのって、CとかPとかと違ってVMにはこれといって
Mとの間に役割の違いが無いことだよ
特定のVとバインドすることを意識して作ったMってだけだからな
544:デフォルトの名無しさん
12/11/19 00:53:44.94 .net
なにいってんだ？
ビューの状態を表すモデルデータという
役割があるだろ。
545:デフォルトの名無しさん
12/11/19 00:58:48.11 .net
別に選択状態持つためのMを設けてもいいんだぜ?
546:デフォルトの名無しさん
12/11/19 01:02:55.31 .net
それはもはやMではない。
Mの役割としては、GUIアプリではなく
CUIアプリからでも普通に使えるようなものを
目指すべきだ。
そんなGUIに依存した機能を持たせるべきじゃない。
547:デフォルトの名無しさん
12/11/19 01:04:56.93 .net
その選択状態がGUIとしてあらわす際に必要となる選択状態なのか、
そのプログラムの動作自体を構成するにおいて存在する必然性のある選択状態なのかによるね
548:デフォルトの名無しさん
12/11/19 01:19:56.04 .net
画面ごとのVMはいいけど、モデルごとのVMはめんどい
549:デフォルトの名無しさん
12/11/19 10:20:32.56 .net
>>532
GUIの選択状態を維持するためのモデルをViewModelという
550:デフォルトの名無しさん
12/11/19 22:03:23.29 .net
グリッドのボタン付けるときとかの
行ごとにVM作る派と作らない派の比率が知りたい
551:デフォルトの名無しさん
12/11/19 22:15:46.48 .net
行って何の話だよ
552:デフォルトの名無しさん
12/11/19 22:20:34.86 .net
WPFでデータグリッド使ったら負けだろ
それならWinForms使うわ
WPFならテンプレートで作れ
553:デフォルトの名無しさん
12/11/19 22:29:30.62 .net
普通コンボボックスの項目毎VM作るだろ
554:デフォルトの名無しさん
12/11/19 23:23:02.89 .net
グリッドって何かと思ったらDataGridのほうか
555:デフォルトの名無しさん
12/11/20 13:30:22.35 .net
>>540
？？？
コンボボックスにモデルのコレクションをバインドするだけでええやん
556:デフォルトの名無しさん
12/11/20 13:54:25.91 .net
HeaderedItemsControlとかをこねくり回すのは常套手段なのか
557:デフォルトの名無しさん
12/11/28 11:11:37.09 .net
考え増やしたいから、
MVVM の各レイヤーの具体的な責務を教えてください
以下、テンプレ
M:
V:
VM:
558:デフォルトの名無しさん
12/11/28 11:22:45.65 .net
>>544
> M:
ビューに関係無いデータ構造など変更部分。いわゆるモデル。UIスレッドと分離されてる事が望ましい。
> V:
ビューの見た目。極力もらったデータを表示したりインプットを上にあげるだけで何もしない。
> VM:
その両者を繋ぐもの。そのビューに関係するコーディネーター。ユニットテストできること。スレッド間の調整をここで吸収。
559:デフォルトの名無しさん
12/11/28 11:22:46.45 .net
Set-Location : ドライブが見つかりません。名前 'M' のドライブが存在しません。
560:デフォルトの名無しさん
12/11/28 11:34:44.90 .net
一番ありそうな間違いは、WebMVCの典型的な間違った使い方のように
M: データ
VM: ロジック
としてしまうことだな
注文画面のMは注文処理クラス。VMはあくまでインターフェイスの差を吸収するだけ。
561:544
12/11/28 11:45:53.66 .net
>>547
まさにこれw
562:デフォルトの名無しさん
12/11/28 12:47:28.47 .net
使う側ならそれでいい
563:デフォルトの名無しさん
12/11/28 14:02:32.93 .net
Mのビジネスロジックがバックエンドに移って
結果的にMがデータだけになることはあるだろうけど
VMから見たら特に関係ない話。VMにビジネスロジックを書いてるわけじゃない。
564:デフォルトの名無しさん
12/11/28 21:50:02.31 .net
プレゼンテーションに関わるものとしてVMに置いとくべきデータやロジックがあるって意見も耳にするけど
自分には区別が難しいので極力Mに持たせるわ。
565:544
12/11/28 22:50:19.03 .net
永続化しないデータとか？
566:デフォルトの名無しさん
12/11/28 23:14:06.28 .net
MVVM界隈の話はVMが強調されすぎるきらいがあるよな。
本当はMの方が遥かに重要なのに。どちかか省くなら迷わずM。
VMはMVVMパターンのアイデンティティだから仕方がないけど。
567:553
12/11/28 23:14:52.00 .net
間違えた省くならVM
568:デフォルトの名無しさん
12/11/29 00:02:45.23 .net
プレゼンテーションにかかわるものはVに書くんじゃないのか
569:デフォルトの名無しさん
12/11/30 06:22:26.73 .net
VMは、抽象的な、表示する「ための」データだな
例えば、VでItemsSourceにバインドして表示する一連のデータのコレクションとか
特定のデータを、手段は特定しないからとにかく強調表示しろ、ということを示すプロパティとか
Vは、具体的な、表示「の仕方」だな
同じVMからでも、同じコレクションを表示させる方法はListBoxだったりDataGridだったり単なるテキストだったり
どんな形で表示するのかはVが決めることでVMは手を出せない
また、強調表示の仕方にしても、単なる色変化だったり太字だったり、その部分だけ無意味にアニメーションさせたり
表示の仕方もVに任せられててVMは手を出せない
570:デフォルトの名無しさん
12/12/11 16:23:56.96 .net
VBでペタポトプログラミングしか経験ない奴にパターン教えても一向に概念理解してくれない
ましてMVVMなんか到底無理無理
571:デフォルトの名無しさん
12/12/11 18:18:42.11 .net
そんな動けばいいという考えの奴に何をいってもダメだ。
平気でModel部分にフォームやコントロール(UI)のインスタンスを食わそうとし�
572:ｽりするからな。
573:デフォルトの名無しさん
13/01/16 20:12:33.47 .net
MVVMって従来のASP.NETやWindowsフォームに慣れた人に説明するなら、
V Aspxファイル/フォーム
VM コードビハインドのcs
M 業務ロジック
と対応してて、従来のASP.NETやWindowsフォームとの大きな違いは、
ViewとViewModelがバインディングを介すると言う制約があるので分離しやすい、
と言う理解なんだけど大体合ってるかな？
574:デフォルトの名無しさん
13/01/16 22:46:55.45 .net
全然
575:デフォルトの名無しさん
13/01/17 23:06:47.49 .net
大体合ってるみたいですね。
VB6脳なPGとJava/Struts脳なPG、どっちがMVVM覚えるのに向いてますかね？
576:デフォルトの名無しさん
13/01/18 08:37:02.03 .net
>>561
全然違うと言われてんだろ
概念がそもそも違うがそれが分からない人間でも
・コードビハインドは画面と同一クラスだがVMは別クラス
・コードビハインドとViewは一対一だが、View:VMは1:n
・VSでコントロールをダブルクリックしてもコマンドが作られて自動的にバインドされたりしない
・そもそもコードビハインドはコードビハインドで存在するだろ
と、上げ出したらきりが無い
MVVM使うならちゃんとMVVMの概論くらいは理解させないとあとで自分が地獄行きだぞ
577:デフォルトの名無しさん
13/01/18 09:03:18.93 .net
的外れな回答()キター
578:デフォルトの名無しさん
13/01/18 14:28:02.15 .net
いまだにVB6脳なんて他のこと何も向いてないだろ
579:デフォルトの名無しさん
13/01/18 14:46:29.63 .net
違うって言われてるのに合ってると受け取っちゃうのはどこにも向いてないな。
580:デフォルトの名無しさん
13/01/18 17:07:06.64 .net
全然合ってるかもしれない
581:デフォルトの名無しさん
13/01/20 07:38:18.01 .net
559は大体あってるよね？
というより562が間違いすぎｗ
・コードビハインド（各種イベントで呼び出される関数）は
手動で設定すれば Viewとは別のクラスにすることは可能だし
・V:VM は 一つのデータを別表現で表示することがあるので V:VM = n:1
・デザイナでダブルクリックしても自動で出来ない
→細かい処理を行いたければデザイナに任せずに手動で操作するのは当たり前。
・そもそもコードビハインドはコードビハインドで存在するだろ
→別にイベントで関数呼び出しても、
CommandやActionのバインディングで関数呼び出してもよくね？
582:デフォルトの名無しさん
13/01/20 07:50:01.85 .net
そういえば、データバインディングって
ほんの少し MFCのValue変数とDDX_～ に似てないか？
583:デフォルトの名無しさん
13/01/20 09:40:48.58 .net
>>568
ほんの少しな( ´Д`)y━･~~
584:デフォルトの名無しさん
13/01/22 07:57:45.76 .net
@Grabacr07 いままでのオレオレICommandの正しい実装基底クラス
Prismのパクリなのになんでこんなに偉そうなの？
585:デフォルトの名無しさん
13/01/22 19:39:17.12 .net
心底どうでもいい
586:デフォルトの名無しさん
13/01/22 21:17:29.87 .net
MVVMライブラリはすべてPrismのパクリだからな
いまさらだろ
587:デフォルトの名無しさん
13/01/25 10:23:59.51 .net
別に偉そうじゃない件について
どれだけコンプレックス感じてんだよｗ ダッセーやつｗ ぷげら
588:デフォルトの名無しさん
13/01/25 23:38:53.69 .net
実際やってみたらMVVMではなくWPFやSilverlight固有の部分でかなり躓いた
初見でXAMLを自由自在に扱える奴とかいるのか？
589:デフォルトの名無しさん
13/01/25 23:46:59.77 .net
固有の約束事を理解しないといけないのはWinFormsだってASP.NETだって
PHPとかのWebフレームワークだって一緒だ
590:デフォルトの名無しさん
13/01/26 00:00:26.99 .net
パネル使ったレイアウトに慣れてないだけじゃね？
591:デフォルトの名無しさん
13/01/26 00:07:18.85 .net
>>574
ちなみに躓いたのどこら編？
592:デフォルトの名無しさん
13/01/26 00:11:58.51 .net
ControlTemplateとか初見でMSDNだけで使いこなせたら神だわ
593:デフォルトの名無しさん
13/01/28 10:43:39.37 .net
Templateカスタマイズする時点で折れるな
594:デフォルトの名無しさん
13/01/29 02:16:53.83 .net
>>573
別にウガヤが考えたロジックじゃあないのに
まるで自分で考案したような口ぶりが臭いだけじゃろ。
特にcommandのweakeventなんてprismのアイデアそのまんまだし。
++c++やneueと違って.NETやC#(言語)の知識は薄っぺらいのに
ビックマウスだから余計に臭い。
595:デフォルトの名無しさん
13/01/29 05:30:37.24 .net
>>580
詳しくは知らんが咀嚼して自分のライブラリとしてまとめ上げて、それを採用してくれてるとこもあるんだから、口だけ番長のお前より遥かにまし。
リアルでフルボッコにされたの？悔しいのぅ悔しいのぅ。
596:デフォルトの名無しさん
13/01/29 07:57:35.12 .net
奴が自分で考案したみたいなことを言っているのは見たことないが
どの辺で言ってたのか気になるな
597:デフォルトの名無しさん
13/01/29 08:22:09.37 .net
別に好きでも嫌いでもないが、世の中のMVVMフレームワークは全てLivetより下と言ってるように取れる文書ならみた
MVVMが普及しないのは既存のインフラが不十分なせいで、Livetがそれを解決するんだとか
確かアンチMVVMに反論する記事だったかと思う
598:デフォルトの名無しさん
13/01/29 08:34:30.68 .net
現場でMVVMゴリ押しして使ったら大失敗したからアホにも使えるように作ったんだっけ？
部下も可哀想だな
599:デフォルトの名無しさん
13/01/29 08:50:43.67 .net
まあ既存のが不十分なのはあってるな
ただLivetが必要十分かと言うとそうでもない
600:デフォルトの名無しさん
13/01/29 09:18:58.54 .net
Javascriptエンジン組み込んでknockout.jsを逆移植するのがいいと思う
ビューに振る舞いを書けた方がいいのは、それを最初否定してたMVVM自身によって証明されたし
VMも静的言語で書くのは面倒な単純作業すぎる
601:デフォルトの名無しさん
13/01/29 09:31:08.32 .net
ReactiveExtensions絡めて作ってるがすこぶる楽だし見通し良くなってイイよ。
まぁ向き不向き有るかもしれんが。まだ試しで作ってるだけなので後でいろいろはまるのかもしれんけど。
内部の状態遷移など含めて綺麗に落とし込みたいんだけどまだそこまで出来とらん。
602:デフォルトの名無しさん
13/01/29 10:26:40.09 .net
MVVMとリアクティブプログラミングの相性は非常にいいね。
ただ、ReactiveExtensionsは記述が冗長になるので
人にはお勧めできないな。
async,awaitみたいにコンパイラ支援があればいいんだけど。
603:デフォルトの名無しさん
13/01/29 10:36:58.35 .net
>>588
非同期として扱うだけなら冗長になるかもしれんがその以上やるならあんなもんじゃない？どの変が気になる？
F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
604:デフォルトの名無しさん
13/01/29 12:29:20.69 .net
MVVMって何ですか？
605:デフォルトの名無しさん
13/01/29 12:40:25.22 .net
wwwwみたいなAAの一種
606:デフォルトの名無しさん
13/01/29 12:51:58.26 .net
>>588
俺は非同期についてはasync,awaitを使ってるから気にしてなくて、
リアクティブプログラミング本来の "関係性を記述する" って部分で冗長性が気になる。
例えば、
int A { get { return B ? C : D.E; } }
って単純な関係性を記述するだけでも、それなりの量になる。
> F#だとその辺を自分でクエリ構文を定義してよしなに出来なくもないけど。
F#の計算式は羨ましいね。
async, awaitがTask<T>を生成するのと同じように、
計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。
607:デフォルトの名無しさん
13/01/29 13:51:35.91 .net
>>592
> int A { get { return B ? C : D.E; } }
> って単純な関係性を記述するだけでも、それなりの量になる。
自分もまだそこまで突っ込んで触ってないのでなんだが、自分で用途に合わせた複数要素を取れるZipみたいな物とか作らないと記述が冗長になりそうな気はしてる。
Zip重ねてとかでもいいけど見た目的にも身微妙な気がしなくもない。
> 計算式で ReactiveProperty<T> を生成すると非常にすっきり書ける。
その辺でSelectManyとかSwitchで上手く合成出来ると綺麗に書けるんかね( ´Д`)y━･~~
608:デフォルトの名無しさん
13/01/29 15:41:47.19 .net
F#で計算式を使うと言っても、do!やlet!でやるのは
ReactiveProperty<T>からをT型の値を取�
609:ｾすると同時に値の監視を開始するだけだから 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#でも同程度の記述の冗長性は残るという事になる。
610:デフォルトの名無しさん
13/01/29 16:11:47.74 .net
>>594
自分が言ってるのはQueryExpressionsの方。
使ってる例としてはこんな感じ。
URLﾘﾝｸ(mnajder.blogspot.jp)
これはクエリ式への直接変換的な感じだけど、望みのクエリ式を追加できるので独自のDSL的に定義できる。
611:デフォルトの名無しさん
13/01/30 18:31:22.62 .net
従来型のほうがいいだろ
誰かさんにプレゼント
優れた言語より流行ってる言語
優れたフレームワークより使われてるフレームワーク
612:デフォルトの名無しさん
13/01/30 18:52:28.14 .net
アプリケーションで、各種バー表示のon/offや配置等の、GUIに関する設定がよくあると思いますが
そういう設定の保存・読み込みロジックはVMでいいんですよね?
MVVMの概念がまだあやふやで確信が持てません。
613:デフォルトの名無しさん
13/01/30 18:55:35.45 .net
一番使われてるフレームワークが一番、ってのなら、
一番のラーメンはインスタントラーメンだぜ？
614:デフォルトの名無しさん
13/01/30 19:04:13.88 .net
Haskell大流行だもんな
615:デフォルトの名無しさん
13/01/30 19:13:05.88 .net
>>598
フレームワークとラーメンとが置換可能であることを証明できれば完璧だな。
イグノーベル賞がんばれよ。
616:デフォルトの名無しさん
13/01/30 20:13:22.03 .net
COBOL最高だろうが
617:デフォルトの名無しさん
13/01/30 20:49:05.37 .net
>>597
Vでしょ
というかそういう作り込みが必要な画面にMVVMを適用するのは不適切だと思うよ。
大してメリットがなく面倒なだけ。使うならダイアログとかで使う。
618:デフォルトの名無しさん
13/01/30 20:55:18.66 .net
メニューとか(共有の)ツールバーとかウィンドウ制御のようなシェル的な部分に
MVVMを適用しようと考えてはいけない
そういうのはインフラとしてMVVMの枠外で実装して、その中で扱うドキュメントには
必要に応じてMVVM適用するのがスマート
619:デフォルトの名無しさん
13/01/30 22:12:56.62 .net
あくまでVの都合だしな
MVVMは本体処理とUIの組み合わせ方のパターンでしかないので、ウィンドウのサイズ保存とかはロジックとは無関係
620:デフォルトの名無しさん
13/01/30 22:13:53.89 .net
>>602
え？Modelじゃないの？
煽りじゃなくて、真面目な質問です
621:デフォルトの名無しさん
13/01/30 22:14:56.02 .net
あぁ、確かにビジネスロジックではないのか
622:デフォルトの名無しさん
13/01/30 22:45:08.78 .net
あえてシェルにMVVMを適用するんならMだろうな
どちらにしろGUIに閉じた話であって、ビジネスロジックの世界とは分けて考えるべき
623:デフォルトの名無しさん
13/01/30 22:47:03.45 .net
>>597
VMで正しいよ。
ビューモデルというのは、ドメインモデルとビューとのギャップを埋めるラッパーの役割をするもので、
まさに>>597のようなビュー固有のデータを扱うのに適している。
Vに置くのは（少なくともこのスレにおいては）間違いだから>>602は気にしなくていい。
624:デフォルトの名無しさん
13/01/30 22:56:21.08 .net
>>608
それこそビジネスロジックとUIがごっちゃになってね?
もともとビジネスロジックから見たらVの実装の詳細にすぎないことで、
それが少々複雑になるからMVVM適用しようってんなら
GUIの設定情報を持つためのMを使うのが適切だと思うよ
625:デフォルトの名無しさん
13/01/30 23:00:06.22 .net
アプリケーションモデルというやつですか。
626:デフォルトの名無しさん
13/01/30 23:07:07.58 .net
そもそもそんなロジックに直接関係なくてGUIに閉じた混みいった制御と
金,人間,住所,データベース,入力フォーム云々
627:を一緒にして扱うのがおかしい そこ明確に分けるのが一番大事だろ
628:デフォルトの名無しさん
13/01/30 23:19:21.22 .net
そんなめんどくさいことせんでも、VBで画面にぽちぽちボタンとか張って、
ダブルクリックしてイベント追加したら、その中に全部処理書けばええやろww
629:デフォルトの名無しさん
13/01/30 23:22:23.10 .net
PrismだとShellに対してVとVMがあって、ShellのVMのプロパティに
入力画面とかのVM渡して、ShellのVの中でその画面開いて、ツールバーなども
Shellが管理するようになってたはず。サンプルではShellに対するMは無かったけど、
ツールバーの細かい設定入れるとしたら当然この設計ではShellのMになるよね。
ShellのVMが本当に必要かどうかはかなり怪しいが。
630:デフォルトの名無しさん
13/01/30 23:22:30.14 .net
>>609
ビジネスロジックというのを定形的に捉えすぎてね？
アプリケーションシェルと言った物の実装も対象が違うだけでビジネスロジックの実装と変わらんだろ。
MVVMはロジックとビューをブリッジ介して分離する仕組みでその対象がシェルでも構わんと思うけどね。
他の実装がしやすいなら無理に適応する必要はないけど。
631:デフォルトの名無しさん
13/01/30 23:26:54.51 .net
>>609
ドメインモデル（ビジネスモデル）からはビューモデルに対して一切関知することはなく、完全に独立している。
ビューモデルからはドメインモデルを（継承やコンポジションなどの形で）参照することになるが、
当然ながらドメインの詳細には立ち入らないため、ごっちゃになることはない。
> GUIの設定情報を持つためのMを使うのが適切だと思うよ
ここではモデル（M）をドメインモデルとビューモデルとに明確に区別しているわけで、このGUIの設定情報と
いうのがまさに表示のためのモデルであり、ビューモデルだと>>608で書いたつもり。
なんか噛み合ってないかな？
632:609
13/01/30 23:32:29.95 .net
>>614-615
うん。だからシェルの抽象化がVMだしシェルのロジックやデータがMとするなら
Mじゃないかってことが言いたかった。省くならVMを省くべきじゃない?
バインディングもあんまり役に立たなそうだし。
633:デフォルトの名無しさん
13/02/04 00:54:01.35 .net
ViewModelHelper.ReadOnlyDispatcherCollectionのソース見てるんだけど
Dispatcher経由でViewModelのDisposeしなくていいの?
634:デフォルトの名無しさん
13/02/04 02:17:34.63 .net
WeakReferenceがなんとか
635:デフォルトの名無しさん
13/02/12 00:41:05.78 .net
だからコードビハインドのあるなしとMVVMに何の関連もないと何度言ったら。。。最近コードビハインド付のMVVMしかしてない
おがやさん以前は、コードビハインドはMVVMの癌、肯定してる人は糞みたいなニュアンスのこと言ってませんでしたっけ？
この人若年性健忘症なのかな？
636:デフォルトの名無しさん
13/02/12 00:45:23.42 .net
そーとー昔じゃないかな？それ
637:デフォルトの名無しさん
13/02/12 00:59:57.57 .net
いくら昔でも180度真反対に勘違いするほどの痴呆症を患った高齢の方には見えなかったもので。
638:デフォルトの名無しさん
13/02/15 08:39:40.77 .net
>>621
ようするにやせ我慢だったと。そういう事です。
コードビハインドなんて所詮MS界隈でしか使われないローカル技術仕様の用語に過ぎず
モデル云々を語る抽象的な概念にはほど遠い。
単に趣味と程度の問題を高尚っぽく語りたい人が散見されるだけ。
639:デフォルトの名無しさん
13/02/16 04:51:33.73 .net
>>622
MS以外でも使われてるだろ
もっと幅広い知識を持たないといかんよ。
640:デフォルトの名無しさん
13/02/16 06:51:52.98 .net
例
641:デフォルトの名無しさん
13/02/16 10:39:51.16 .net
MS以外のコードビハインドkwsk！
642:デフォルトの名無しさん
13/02/16 11:09:58.98 .net
>>625
knockout.js
643:デフォルトの名無しさん
13/02/16 15:33:08.84 .net
なんかデータバインディング持っているフレームワークなら何でもコードビハインドだとでも
言いたそうな勢いだなw
UIの画面設計の宣言的定義とUIロジックの手続き的記述を分けて書けるフレームワークなんて
MS以外にもいくらでも�
644:るし、データバインディングもそのための定番手法の一つではあるが knockout.js含めて「コードビハインド」という用語がMS関連以外の文脈で使われることなんて ほとんどね～よ。手続き的記述の部分をMSが独自にそう呼んでいるだけの話。
645:デフォルトの名無しさん
13/02/16 15:44:41.67 .net
日本語だと分離コードになるのか。
確かにMS関連しかその言葉聞かないし、ぐぐってもMS関連しか出てこない
646:デフォルトの名無しさん
13/02/19 01:32:44.57 .net
似たようなものだと、コードビハインドという単語ではないけどJSFの管理ビーンとか似た雰囲気
647:デフォルトの名無しさん
13/02/19 08:22:24.77 .net
Adobe FlexのMXML+ActionScript3がかなり似ているというか洗練されていると思う。
MXMLでのV定義は単純にAS3でのクラス定義の別記法なので、AS3でのクラス定義と
同様に実装するinterfaceを指定出来る。VMにもinterfaceを定義してあげればVとVMが
互いの実装を知らずにinterfaceだけを通してやり取りが出来る。
VMのinterfaceの先頭にBindableとアノテーションをつければ勝手にgetter・settetが
バインド可能になるのでデータバインディングでVMの値をVにはり付けるのも簡単。
648:デフォルトの名無しさん
13/03/03 08:33:04.94 .net
やっぱダイアログや画面遷移はView Serviceにするのが好きだな。
649:デフォルトの名無しさん
13/03/03 10:12:08.72 .net
同意
共通に使えるものにメッセージ使うのはアンチパターン
というかメッセージいらない
650:デフォルトの名無しさん
13/03/07 11:13:30.47 .net
MVVMの意図するところはこんな認識で合ってる？
・V<->VM の依存関係はバインディングに任せましょ
・VM はデータの加工と操作 (コマンド) の提供に専念しましょ
651:デフォルトの名無しさん
13/03/09 07:15:19.68 .net
大雑把にはあってるんじゃないか
652:デフォルトの名無しさん
13/03/09 19:14:13.47 .net
MとV&VMを別プロジェクトにして問題ある？
653:デフォルトの名無しさん
13/03/09 19:48:12.38 .net
>>635
ないって言うかむしろしろ(´・ω・｀)
654:デフォルトの名無しさん
13/03/09 19:48:13.70 .net
よっぽど小規模でない限り分けるだろ
655:デフォルトの名無しさん
13/03/22 14:44:16.04 .net
開幕迎える前にグッバイ・モーガンになるんか？
656:デフォルトの名無しさん
13/04/01 12:24:22.90 .net
livet 詳しい人いたら教えてくれ。
URLﾘﾝｸ(github.com)
ここの200行あたりにある感じで、ConfirmationDialogInteractionMessageAction を使う、MenuItem を作った。
でもこの方法だと、MenuItem の IsEnabled に ListenerCommand の CanXXXX が反映されない。
IsEnabled に反映させるにはどうしたらいいんだろうか？
657:デフォルトの名無しさん
13/04/01 13:51:12.65 .net
MenuItemに直接アクション持たせてIsEnabled管理も別プロパティでやるか、
CommandのCan～状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ
658:639
13/04/01 19:20:38.99 .net
せっかく教えてもらったが、いってることがわからんズラ
「MenuItemに直接アクション持たせて」とはどのようすればいいんだろうか？
サンプルのサイトがあったら張ってもらえないだろうか。
「CommandのCan～状態更新の際CommandのRaiseCanExecuteChangedを呼ぶ」
これをやるためには、MenuItem の Command にバインディングする必要があるだろうが、ダイアログの表示はコード・ビハインドでやるという理解でよいでしょうか？
質問ばかりですまんです。
659:デフォルトの名無しさん
13/04/01 19:58:53.84 .net
MenuItemのIsEnabledにコマンドの可否状態が反映されないって言うからMenuItemにコマンドはバインドした状態で反映されないって言ってるんじゃなかったの？
それともコマンドをMenuItemにバインドせずにMenuItemに反映されないって言ってるの？
ダイアログの表示ならコマンドで叩かれたVMからVへメッセージ飛ばしてやるんだろ
そのために確認用のトリガとアクション書いたんじゃないのか
660:639
13/04/01 23:25:33.35 .net
質問の仕方がまずかったかな。
IsEnabled と具体的なプロパティを書くのではなくて、
MenuItem の活性・不活性に CanXXXX が反映されない
と書けばよかった。
コードはリンク先に書いてあるのとほとんど同じ。
"Interaction.Triggers"に設定していあるのであって、
MenuItem の Command にはバインドされてない。
質問をかえれば、リンク先のようなコードを書いたが、
これでは SetDefaultColorCommand の CanSetDefaultColor
が MenuItem の状態（活性・不活性）に反映されません。
どうしたらいいでしょうか？
って感じです。
661:デフォルトの名無しさん
13/04/02 01:20:28.31 .net
>>643
MenuItemはLivetのメッセージ機構なんて知らないし
DirectInteractionMessageにもコマンドの状態を反映させる仕組みは無いから
自分でやらなきゃならんだろうな。
VMにプロパティを用意してIsEnabledにバインドするとか
コマンドの状態をIsEnabledに反映させるBehaviorでも書けば?
662:デフォルトの名無しさん
13/04/02 13:33:43.91 .net
LivetのCommandにはCanExecuteプロパティあるからIsEnabledにそれをバインドするのがいいだろう
663:639
13/04/02 21:29:50.11 .net
>>645
ありがとう。できた。
シンプルな解決策だね。
664:デフォルトの名無しさん
13/04/05 08:36:23.77 .net
Livetの0.98辺りの時に書いてたソースコード、
今のバージョンだとそのまま使えないんだな…
DispatcherCollectionとかWindowMessageActionとか、
コンストラクタに渡せるパラメータの型とか順番とか、すっかり変わっちゃってる
665:デフォルトの名無しさん
13/04/08 17:23:05.27 .net
Livet .NET4.5で、読み取り専用のスレッドセーフなコレクションをModelに持たせたいんですけど
ObservableSynchronizedCollectionをラップするクラスを自作するしかありませんか?
666:デフォルトの名無しさん
13/04/08 19:50:30.83 .net
MVVMだのスレッドセーフだの言う前にマルチスレッドをちゃんと理解しろよ
読み取り専用ならスレッドセーフだからReadOnlyCollection<T>でいい
667:デフォルトの名無しさん
13/04/08 20:35:10.02 .net
読取専用のコレクションは変更されないわけじゃないぞ
668:デフォルトの名無しさん
13/04/08 20:47:02.14 .net
さすがにそれは無理があるだろ…
それに、随時少しずつ変更されるんじゃなくて時々ゴソっと入れ替わるだけなら
Observable*使わなくてもコレクションごと差し替えてしまえばいい
669:デフォルトの名無しさん
13/04/08 21:01:42.99 .net
っていうか作法的には>>651のやり方の方が正しく「スレッドセーフ」だと思う
Observable*使うと、連続してコレクションを変更するときに変更途中の変な状態が晒されちゃうよ
決してObservableSynchronizedCollectionなら解決するという問題ではなく
670:デフォルトの名無しさん
13/04/08 21:35:22.96 .net
一括で変化させるのではなく、逐一反映させたいのです。
その為読み取り専用ラッパもINotify～でないといけません。
671:デフォルトの名無しさん
13/04/11 14:22:53.29 .net
Livetプロジェクトを作った時にできるInfrastructureAssembliesフォルダは何のためにあるの?
672:654
13/04/11 14:37:04.33 .net
すいません。必要なDLLとクイックヒントのXMLっぽい事は分かりました。
でもLivet.Design.dllが何の役割があるのか分かりません。
673:デフォルトの名無しさん
13/04/13 02:18:05.29 .net
>>648
ReadOnlyObservableCollection
674:デフォルトの名無しさん
13/04/15 14:41:24.53 .net
昔の0.9xのLivetで開発してたもので、画面描画が完了したタイミングでアニメーション開始させるために
DispatcherHelper.BeginInvoke(action, DispatcherPriority.Render);
みたいに書いてたのがあるんだけど(actionはアニメーション開始させる処理)、
今のLivetだと「BeginInvokeは古い形式です」とかいう警告になってしまう。
まぁ、警告だからコンパイルできるし実行もできるんだけど…
警告出ない、古くない形式ってどう書けばいいんだろう?
675:デフォルトの名無しさん
13/04/16 00:44:11.22 .net
UIDispatcherプロパティからBeginInvokeだったと思う。
676:デフォルトの名無しさん
13/04/16 07:45:34.55 .net
>>658
677: それでOKみたいですね どうもでした 0.9xと1.xで、結構変わってるとこ多いですねー
678:デフォルトの名無しさん
13/05/02 16:37:49.02 .net
MVVMでの非同期処理をする場合について質問なんですが
MはUIスレッドを意識せずプロパティやコレクションを変更し
それを監視してるVMが適宜UIスレッドにディスパッチする
という感じでするのでしょうか?
679:デフォルトの名無しさん
13/05/02 17:18:30.55 .net
UIスレッドというものはView側の都合だからそんな感じだな
VかVMあたりだろう
680:デフォルトの名無しさん
13/05/08 13:29:53.61 .net
Livetの公式ページが404 File Not Foundになってる…
681:デフォルトの名無しさん
13/05/08 14:57:34.62 .net
よくあること
682:デフォルトの名無しさん
13/05/10 06:05:27.27 .net
よくあるのか
たまにしか見に行かないから、この1年半くらいで初めてだった
そのうち直るのかな
683:デフォルトの名無しさん
13/05/14 17:27:08.94 .net
@merancronと@ugaya40のサイレントバトルがかなり面白い
684:デフォルトの名無しさん
13/05/17 06:09:53.49 .net
Livetのページ、1週間以上経ってもまだ404 File Not Foundなんだが閉鎖しちゃった?
それとも移転したのか?
閉鎖にしても移転にしても何かその旨書いといて欲しい
しかしユーザー困るな
685:デフォルトの名無しさん
13/05/17 14:40:36.69 .net
>>666
たぶんサーバーの料金払ってないだけ
686:デフォルトの名無しさん
13/05/17 15:27:29.29 .net
MVPなんだからAzureの無料枠ぐらいもらってるだろうに……
687:デフォルトの名無しさん
13/05/17 19:00:21.91 .net
や ら な い か
688:デフォルトの名無しさん
13/05/17 19:07:32.07 NuBHhb8n!.net
kon
689:デフォルトの名無しさん
13/06/24 11:30:16.12 .net
Uにリムーブされていることに気がついたｗ
まあ、ちょくちょく揉めてたからなｗ
690:デフォルトの名無しさん
13/10/03 15:35:02.10 .net
Vにバインドしたコマンドの内部で非同期操作を呼び出したときのお作法ってあるんですかね？
691:デフォルトの名無しさん
13/10/03 16:40:34.53 .net
俺は気にしてないが、VMでは特に気にしなくていいんでね？
692:デフォルトの名無しさん
13/10/10 22:24:40.50 .net
>>672
同じコマンドを複数回読んだ場合、場合によっては順序が変わる可能性あるからその辺に注意ぐらいかのー
693:デフォルトの名無しさん
13/10/10 23:00:23.03 .net
いい加減日本語の書籍を出してほしい。
694:デフォルトの名無しさん
13/10/14 23:43:00.78 .net
ModelがINotifyPropertyChangedを実装する理由は
Mを操作した結果、プロパティが変化したことを通知する
という理解でいいですか?
695:デフォルトの名無しさん
13/10/15 12:36:49.83 .net
OK
696:デフォルトの名無しさん
13/10/16 15:35:26.82 .net
>>676
OnPropertyChanged で渡すプロパティ名が間違っていると View への通知が
正しく行われない。当たり前の話だけど、この種のつまらないトラブルが
多いから注意してね。
697:デフォルトの名無しさん
13/11/14 23:01:29.82 .net
>>394
ちょっと前の書き込みだけど、フォルダ分けみんなどうやってるかが気になる。
やっぱ、View/ViewModel/Modelって分けてるのかな？
なんか、画面が大量にある場合とかに、V/VMのクラスが大量にできて、対応するV/VMのペアが、IDEから辿りにくいんだよなぁ。。
V/VMがたくさんあるような時って、機能とかグループごとにサブフォルダでまとめた方がいいのかな。
こんな風に、、
・グループ1フォルダ
・View
ここにグループ1のViewを複数入れる
・ViewModel
ここにグループ2のViewModelを複数入れる
・グループ2フォルダ
・View
・ViewModel
698:デフォルトの名無しさん
13/11/15 07:23:33.44 .net
俺も最初に参考にしたサンプルが
View/ViewModel/Model みたいにフォルダ作ってたので
それに倣ってそんな感じにしたけど、サンプル程度のクラス数ならいいんだけど
数が2桁くらいになってくるといまいちだよね。サブフォルダまで作っても。
むしろ、特定の機能のフォルダ作っちゃって、そこに
それに関連したView/ViewModel/Modelをセットで入れる、みたいなのも
逆にそこ�
699:ｾけで完結しないで複数にまたがるのが分類しにくかったり。
700:デフォルトの名無しさん
13/11/15 13:19:46.47 .net
>>680
俺もそれが妥当と思う
701:デフォルトの名無しさん
13/11/15 14:20:43.75 .net
少なくともView内は分けない方がいいと思う
702:デフォルトの名無しさん
13/11/15 14:31:37.31 .net
昔はフォルダで分けてたけど、今はこんな感じ↓
ソリューション
- ModelLayerプロジェクト
- ViewModelLayerプロジェクト
- ViewLayerプロジェクト
- UnitTestプロジェクト
- Commonプロジェクト
703:デフォルトの名無しさん
13/11/15 14:38:30.55 .net
書き忘れたけどもう一つ、ソリューション名と同名のプロジェクトが有るな
（仮にMainプロジェクト）
MainプロジェクトとUnitTestプロジェクトは、アプリケーションプロジェクトで
V/VM/M及びCommonプロジェクトは、クラスライブラリプロジェクト
704:デフォルトの名無しさん
13/11/15 18:56:17.04 .net
C#の場合自動生成される名前空間にフォルダ階層が付加される仕様がこういう場合鬱陶しい
705:デフォルトの名無しさん
13/11/15 19:45:58.66 .net
複数の機能(サブシステム)から構成されるようなアプリなら、俺も680派。
「レイヤ」よりも「機能」の方が凝集度高いんだし。
1機能内でもまだ画面が多いようなら、/機能/の下にView/ViewModelとかを作っても良いけど。
そこまででなければ、少なくともViewとViewModelはセットで。
Modelは、機能固有のものならセットにしても良いけど、だいたいはアプリケーションレベルで
考えるものな気もするので、別配置。
706:デフォルトの名無しさん
13/11/15 23:49:30.50 .net
ModelはともかくViewとVMは一対一で対応してること多いからなあ
707:デフォルトの名無しさん
13/11/16 04:31:20.31 .net
Modelはフォルダどころか別プロジェクトだろ
708:679
13/11/17 16:07:31.49 .net
>>680,686
機能ごとに分けて、そのフォルダの中にV/VMを突っ込むのよさそうだね。
VとVMは一緒にいじること多くて、近くに置いておきたいし。
ありがとう!!
すごく参考になった。
709:デフォルトの名無しさん
13/11/17 16:51:12.93 .net
VMが扱うモデルは１つとは限らないわけで、そういうのは無理があると思うけどね
710:デフォルトの名無しさん
13/11/18 10:21:42.10 .net
ん？
711:デフォルトの名無しさん
13/11/19 23:38:23.24 .net
>>690
機能単位でまとめるのはVとVMまでにして、モデルは別フォルダとか別プロジェクトにまとめる、でいいんんじゃないかな？
712:デフォルトの名無しさん
14/01/13 13:39:58.61 .net
Mの設計にいまいち確信が持てないんだけど
例えばChromeみたいなタブブラウザを作る場合、開いてるページのコレクションはMで持つの?
713:デフォルトの名無しさん
14/01/13 18:47:34.47 .net
>>693
MVVMはそんなに厳密に考えんでいいと思うけどね。
VMをVIEWを軽くするためのロジック移し場所ぐらいに考えてモデルを分ける必要あるなら作ると。そのモデルは一つでも複数でもいい。
Chromeの例なら自分なら開いてるタブやその他の状態を持つアクター一個作るかな。
714:デフォルトの名無しさん
14/01/14 13:13:51.65 .net
MVVMの設計に関しては、
まずアプリケーションをVとMに分ける。
次にVをVとVMに分ける
くらいの考えでいいと思う
715:デフォルトの名無しさん
14/01/15 10:21:03.85 .net
今はMVVMPCEARELS
716:デフォルトの名無しさん
14/03/05 07:59:10.50 .net
test
717:デフォルトの名無しさん
14/03/05 16:17:16.97 .net
普及している感じがしない
718:デフォルトの名無しさん
14/05/20 17:04:41.75 Vv+C9W3P.net
>>699のような手合いは一度ふぁうらー先生の本でも読んだらいいよ
関心事の分離とフレームワーク依存がわかってない
719:デフォルトの名無しさん
14/05/20 20:57:52.43 PPVaI37M.net
PoEAAは読んでるけど、どこがわかってないのかわからないので、教えてくれ。
720:デフォルトの名無しさん
14/05/20 22:25:34.65 9K9vHtgJ.net
>>699
今迄一度もViewでこのデータが必要だからここに持たそうとかやったことのないものだけが石を投げなさい(｡-_-｡)
721:デフォルトの名無しさん
14/05/21 21:50:13.56 v99ZJ6SN.net
>>699
マジでなにがどうわかってないんだか教えて欲しいんだがな。
722:デフォルトの名無しさん
14/05/23 07:24:21.57 mY7MwSDJ.net
PoEAAのMVCの説明って意味不明だよな
723:デフォルトの名無しさん
14/05/23 11:25:59.93 EWfyg3GH.net
>>702
[ModelがViewを意識]と[Modelの責務]は次元の異なる問題ではないだろうか
724:デフォルトの名無しさん
14/05/23 11:26:58.12 EWfyg3GH.net
>>703
翻訳文が意味不明なんだろうな
725:デフォルトの名無しさん
14/05/23 13:12:25.80 3xLYWpXM.net
>>704
だからモデルの債務になるものでビューのことを一切意識しないで扱えるものがどんだけあんだよ。
ビューでこういう使い方するからこういう風に元のデータは持とうとかいちどもやったことないの？
726:デフォルトの名無しさん
14/05/23 13:57:11.39 EWfyg3GH.net
>>706
それはModelのデザインの話であって、責務とは別の話だろうよ
デザインと責務がごっちゃになってない？
いすれにせよ>>699の非難は的外れだけどね
727:デフォルトの名無しさん
14/05/23 14:02:08.57 EWfyg3GH.net
大きな切り口としてアプリケーションをプレゼン層とドメイン層に分ける
プレゼン層＝ビュー、ドメイン層＝モデルだから当然責務は違う
しかし>>706のいうとおり、モデルがビューの使い方を意識した設計になるのは
開発の都合上当然の話だと思うな
728:デフォルトの名無しさん
15/02/26 21:33:45.94 cT7tYUid.net
ReactiveProperty良さげなんだけど使ってる人います？
週末にでも遊んでみよう。
729:デフォルトの名無しさん
15/09/25 15:22:24.80 kx8P/2+s.net
Livet1.3キタ
730:デフォルトの名無しさん
15/10/21 22:31:30.80 4/KXy1nx.net
WPF MVVMでアプリ作ってる人いるんだろうかと思えるくらい過疎っぷりだな
ほんと情報少なくて困ってる
731:デフォルトの名無しさん
15/10/22 01:36:32.77 5QLmtDbA.net
こんなスレあったのか。今まで気が付かなかった。
MVVMは机上の空論っていうか筋が悪いの一言に尽きると思う。
これは過去にオブジェクト指向が攻撃されたような批判者の理解不足に基づく誤解では必ずしもない。
732:デフォルトの名無しさん
15/10/22 11:01:27.71 T+i/NslY.net
とオブジェクト指向の時にも同じようなことを言っていた人はいた。
733:デフォルトの名無しさん
15/10/22 12:13:21.98 dfQe7r4R.net
>>712
具体的にはMVVMのどこらへんが実情に即していない机上の空論で、筋の悪さなの？
可能であれば、古典的MVCやMVPとの比較も交えながら論じてみてほしい。
734:デフォルトの名無しさん
15/10/22 13:13:45.09 522gqyPw.net
>>713
オブジェクト指向は筋が悪かったからな
735:デフォルトの名無しさん
16/01/20 23:45:57.28 xrqpD1Un.net
結局どんな設計がいいの？
Rxに傾倒したけど、上手く使いこなせてない
736:デフォルトの名無しさん
16/05/01 15:54:23.24 tKi6j9CT.net
匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています
言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？
Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
URLﾘﾝｸ(twitter.com)
ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ
The Covenant Project
概要
Covenantは、純粋P2Pのファイル共有ソフトです
目的
インターネットにおける権力による抑圧を排除することが最終的な目標です。 そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します
特徴
Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)
接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
・
737:デフォルトの名無しさん
16/05/01 22:27:00.95 VrD9Va1p.net
>>716
fluxとかかな。まだよく分かっていないけど。
状態を一箇所に集約する
738:デフォルトの名無しさん
16/05/03 11:18:03.92 uB7yk5jG.net
fluxのデータフロー見てたらApache Strutsを再発明したかったのかなって思た
739:デフォルトの名無しさん
16/05/10 17:20:07.82 sgC64ZMu.net
MVVMって保守性が悪いよね。
WPF自体がそういう傾向が強いけど、MVVM使うと輪を掛けてそうなる。
他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。
MVVMで保守性が高くなるんだ！って喧伝してる人がいるのは知ってるけど、
正直裸の王様を褒めてるようにしか思えない。
740:デフォルトの名無しさん
16/05/10 20:43:19.06 OBekjSgo.net
結局正解はなくて最適解があるだけなんだけどさ
よくある失敗はMVC、それも頭でっかちなコントローラーをVMに置き換えているだけパターン
この場合ビューモデルが主役で、テンプレートエンジンのビューと1:1の対となる入れ物の箱モデル
を量産することになる
ちょこっとイベントハンドラーをコードビハインドに書いたら、あとは全部ビューモデルにお任せ
という中央集権国家が誕生、疎結合どこいったって話だな
741:デフォルトの名無しさん
16/05/10 21:04:44.88 Urp5/7iJ.net
>>720
>他人が見て、後で自分が見て、ここのこの機能はどうやって実現されてるのか、
>ここの仕様を変えるにはどこをいじればいいの、理解するのに時間が掛かり過ぎる。
これって単に慣れてないからってだけじゃなくて？
742:デフォルトの名無しさん
16/05/10 21:24:17.05 YLufBM4s.net
昔のようなデバッグして追いづらいってのはあるな。
743:デフォルトの名無しさん
16/05/11 11:26:55.39 sA9FQTwa.net
やっぱりrails系は偉大だったってことかなー。
どこにどんなコードを置くのかフレームワークとして強制するって大事だね。
iOSとかUIKitってだけだから特にファイル構成に対する強制がなくて悩む。
744:デフォルトの名無しさん
16/11/25 20:31:02.28 JXCOPEY3.net
お前らがMVVM頑張っても
画面設計者がMVVM理解者とは限らないから
どこかは破綻するんやで
745:デフォルトの名無しさん
16/12/15 23:39:13.49 KILwFG0x.net
MV)o￥o(VM
746:デフォルトの名無しさん
17/03/23 17:58:48.49 aO3Y1mks.net
データを格納したdatatableをdatagridにバインドして表示させてます。
この場合、datatableはVMですか？Vですか？
747:デフォルトの名無しさん
17/03/23 23:57:20.04 pns5gc7N.net
他のフレームワークに比べてMVVMが有用なケースって、WPF以外だとどんなのがありますか？
748:デフォルトの名無しさん
17/03/31 23:28:02.62 Cc537bij.net
>>728
Xamari
749:n.Forms vue.js
750:デフォルトの名無しさん
17/04/21 04:30:27.44 H6APCPmE.net
UWPみたいな大きい画面から小さい画面までサポートする奴。
UIとロジック分けられないと死ねる。
751:デフォルトの名無しさん
17/05/11 22:40:49.29 NjKe635i.net
modelからViewModelに通信の結果を返すときに、
Rxとか使わずに、interfaceを渡してコールバックを返すようにするのは何かマズいんでしょうか
752:デフォルトの名無しさん
17/05/11 23:10:02.50 w+/nr1Tg.net
Rxも結局インターフェースだしいいんじゃ？
753:デフォルトの名無しさん
17/05/11 23:55:27.09 NjKe635i.net
modelは状態の公開と戻り値のないメソッドの提供のみするそうですが、
状態の公開っていうのは要はpublicなfieldってことなんでしょうか
getterで提供したらなんで駄目なんでしょうか
c#のことはよくわかりませんandroid javaを想定しています
754:デフォルトの名無しさん
17/05/12 11:29:50.90 WPNdofPW.net
>>733
メソッドの戻り値をvoidにする、setterを提供しないのはMVVM由来ではなく、非同期な作りをしたい場合に起因します。
これは非同期な作りの場合、メソッドを呼び出しても直ちに状態が変更されるとは限らないから。
なので、状態の変更が完了した時点でMが通知し、受信側がgetterを介して状態を取得することを推奨しているに過ぎない。
逆に同期的な呼び出ししかしないのであれば、setterやメソッドの戻り値も好きにすればいいと思います。
755:デフォルトの名無しさん
17/05/12 12:01:49.68 efiy+Fg+.net
がや氏の戻り値返すなとかはCQRSやReactみたいに処理の流れを固定しろってのが本質と思うが本人もアーキによって返しますよとかいってるからじゃああの煽りはなんだったの感もありよくわかんね
756:デフォルトの名無しさん
17/05/12 18:50:06.13 NqFIOOZC.net
本人の中では色々な蓄積もあってその上で言ってんだろうけど、間を飛ばすから外から見たらよくわからん事になってるという印象
757:デフォルトの名無しさん
17/05/12 19:52:15.91 05vfegfG.net
とりあえず御大の言うことはスルーしておいて、Flux、Reduxなんかについて調べてから、自分で答えを出せばよろし
758:デフォルトの名無しさん
17/05/12 20:05:15.61 6PqY2VyR.net
C#で状態の公開というとプロパティを使うわけだけど、
javaにはプロパティがないからgetter使うしかないだろうし…
そもそもMVVMではgetter使っちゃダメなんて話があるの…？
759:デフォルトの名無しさん
17/05/12 20:34:29.17 z/cC9xJA.net
状態の公開が何でpublicなfieldになんのか分からん
オブジェクト指向もっかい勉強した方がいい
760:デフォルトの名無しさん
17/05/12 22:16:02.54 Ne3HESGY.net
いや返り値のないメソッドしかテイギシタラ駄目っていう縛りがあると思ってたから、
getterも駄目なのかと
761:デフォルトの名無しさん
17/05/12 23:10:52.37 6PqY2VyR.net
MVVMの提唱がMSからだし、MSが作った言語にはプロパティがあるから…
…javaのgetterが駄目ならプロパティ使うのも駄目になるはず
762:デフォルトの名無しさん
17/05/12 23:56:43.00 XKa7CxLZ.net
ゲッターかプロパティかは本質じゃないだろう。
ゲッターをフィールドっぽく見せてるのがプロパティなだけなんだし。
763:デフォルトの名無しさん
17/05/13 06:13:49.08 Hzzf9sbT.net
AndroidでMVVMやりたいだけなのに
C#でのMVVMとFluxとReduxとクリーンアーキテクチャと
databindingとRxとretrolamdaと全部学ばないといけないわけ？
敷居高杉ませんか
764:デフォルトの名無しさん
17/05/13 08:08:27.52 JyAd7JIY.net
MVVM含めアーキテクチャごっこをやること自体が目的なら全部学べよ。
Androidで開発しやすくしたいというのであれば、まずはData Bindingを使うことと、
APIの戻り/公開メンバとしてObservableを使ってみるところから始めろ。
DroidKaigiのアプリあたりを参考にしながら。
765:デフォルトの名無しさん
17/05/13 08:55:58.29 R5mpG+FZ.net
build 2017と関係あるのかわからないけど、UWP関連でこんなもんが
URLﾘﾝｸ(github.com)
URLﾘﾝｸ(developer.telerik.com)
766:デフォルトの名無しさん
17/05/13 09:01:35.75 Hzzf9sbT.net
droid kaigiですね。ありがとうございます。
他にMVVMの参考になる小規模なソースコードのgithubリンクとかないっすか
767:デフォルトの名無しさん
17/05/13 14:21:43.11 DOmFl3BV.net
Android java MVVMで検索したら色々出てくるけど…
768:デフォルトの名無しさん
17/05/13 17:26:38.50 Hzzf9sbT.net
画面遷移の処理とか結局viewでしかできないから、
view -> viewModel -> view
で行ったり来たりしてるのとかみると糞だなあと思う
769:デフォルトの名無しさん
17/05/13 21:32:34.67 JyAd7JIY.net
Presentation Coordinator
Navigation Service
なお、画面遷移の話とは別に、Androidの場合どうしてもActivity/Fragmentに
依存してしまう部分は出てくるから、その辺はあまり厳密に考えない方がいい。
770:デフォルトの名無しさん
17/05/25 12:23:45.13 7qHN/0ER.net
VMとMの分割についてきちんと説明してくれてるサイトってあまりないけど、
基本的には全部Mに入れてVMはプロパティとしてMだけを持ってそれをVにバインドするってことでいいの？
大抵のサイトでは全部VMに入ってるけど
771:デフォルトの名無しさん
17/05/25 12:55:06.49 jD8c7u6v.net
サイトは知らんが、一番しっくりくるなーと思う考えの一つは
MはDBなどのデータを格納する何か、もしくはデータそのもの。
VMはMからのデータを加工するものとVewとの橋渡しを分けてVMへ。
VはVewそのもの。
ってのが個人的に一番しっくりくる。
772:デフォルトの名無しさん
17/05/25 12:57:53.56 V6q89FWa.net
viewそのものだとactivityがviewになるのは違和感がないか
773:デフォルトの名無しさん
17/05/25 12:59:02.78 jD8c7u6v.net
違和感ある。
VMに入れたい。
774:デフォルトの名無しさん
17/05/25 14:34:21.13 CXNFHBlU.net
MVCだろ
M はDB以外のことは出来るだけしない
V は表示するだけ
C(VM) で色々する
概ね >>751 さんに同意
775:デフォルトの名無しさん
17/05/25 18:18:08.97 V6q89FWa.net
VMがactivityの参照を持ったらだめだと聞いたが。。
Xamarinだとpageか
776:デフォルトの名無しさん
17/05/26 00:49:21.51 rlJlQaZI.net
C=VMだとMVCと変わらんだろうが
777:デフォルトの名無しさん
17/05/26 02:36:40.07 NvS9muX6.net
イメージとしてはCより広い範囲のものをぶち込んでMやVに余計な物置かないのがVMって思ってる。
基本MVCと変わらん。
Cじゃないのはどこに置くとか名前から混乱してる人多かったから、VでもMでも無いのは全部VMってした方が混乱は少ない。
778:デフォルトの名無しさん
17/05/26 06:12:40.96 Xdie43+z.net
MVVMのVはMVCのV+Cだよ
MVPのVとかと同じ
779:デフォルトの名無しさん
17/05/26 06:38:23.57 OOmYkqkr.net
MVVMのVって左から3番目のVのことですか
780:デフォルトの名無しさん
17/05/26 07:01:45.39 Xdie43+z.net
2番目だよ
781:デフォルトの名無しさん
17/05/26 12:30:06.83 fehtyedu.net
めちゃ効率悪い作り方
782:デフォルトの名無しさん
17/05/26 15:34:26.98 ZNc2U8qB.net
MVVMってMVCより明確にしたもの
VMはCという漠然とした者じゃなくて
Viewに対応するオブジェクトそのもの。
だからVMのプロパティを変更することでViewに反映されるし
Viewで何か変更するとVMのプロパティに反映される。
双方向バインディングを使って実現する。
783:デフォルトの名無しさん
17/05/26 19:26:58.74 GnitEmTF.net
全然進化してないな
784:デフォルトの名無しさん
17/05/26 20:59:38.95 ovKX6RUR.net
>>761
効率求めたらガチガチにVewと結びつくからな。
Vewが固定ならMVCもMVVMも要らない。
デスクトップやモバイルで中身同じだけどVewだけ違うとかだからMVCやMVVMが必要になる。
デスクトップとモバイルで同じ処理を別々に書くよりは全体では効率が良くなる。
特にモバイルが画面の大きさや画面比率が多様化してる昨今では。
785:デフォルトの名無しさん
17/05/26 21:03:56.89 ovKX6RUR.net
>>763
強いて進化と言ったらMVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したままで、updateで更新しないと値を更新しなかった。
MVVM独自かは不明だが、MSでは相互に値の更新を自動通知し合う仕組みが出来た。
>>762が言ってるのはそういう事。
786:デフォルトの名無しさん
17/05/26 21:40:38.92 Xdie43+z.net
>>765
そんなもん独自のわけないだろ
787:デフォルトの名無しさん
17/05/26 22:27:08.33 F2M8XGQu.net
MVVMにおいてactivityはviewでいいんだよな？
788:デフォルトの名無しさん
17/05/26 23:41:27.21 ZNc2U8qB.net
更にいうとMVVMをさらに発展と言うか破綻しづらいようにしたのが
flux。MVVMのVMは双方向バインディングだけど
fluxの場合は、Viewの変更は直接VMに反映しない方針。つまり片方向バインディングに限定した。
その代わりVMへの変更関連をActionに集約して
Action -> State(VMに対応) -> View ->Action
と片方向への情報の流れに限定したのがflux
789:デフォルトの名無しさん
17/05/27 02:57:55.41 V3ffhZkY.net
>MVC時代は相変わらずクラス側でVewのプロパティに代入してもVewは古い値を表示したまま
糞Windowsだけだろω
790:デフォルトの名無しさん
18/05/23 23:07:17.16 Au5e7VGg.net
僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
USCRF
791:デフォルトの名無しさん
18/07/04 23:01:58.94 gFgZc5FG.net
QIC
792:デフォルトの名無しさん
18/07/06 12:35:20.43 uTPDH9XV.net
USCRF
793:デフォルトの名無しさん
19/01/28 14:30:35.46 2/HZJEKq.net
LivetとPrismとはなんだったのか
794:デフォルトの名無しさん
19/01/28 22:53:33.32 ELKeaiTx.net
Livetは使った事ないから知らんがWPF開発には色々便利なものあったらしいしPrismも便利なとこあるんじゃないの
自分は使わんけど
795:デフォルトの名無しさん
19/01/30 03:07:28.56 nTVyoRLY.net
知らんなら答えなくて良いんじゃね？
796:デフォルトの名無しさん
19/01/30 10:24:55.23 g/bNoaAl.net
評判は聞いてたからその範囲で教えてあげてんだけど？
無知すぎるボンクラは逝ってどうぞ
797:デフォルトの名無しさん
19/01/30 10:35:20.87 MXCEKHH4.net
Prism.Unityは、UWP版のほうがシンプルでかつ十分な機能で良いんだけど
wpf版もあっち基準に改善したら良いのにな
798:デフォルトの名無しさん
19/01/30 12:36:56.89 m67rAUwN.net
URLﾘﾝｸ(teratail.com)
MVVMやってるのこんなのばっかりだからな死滅すればいいよ
799:デフォルトの名無しさん
19/01/30 12:37:12.23 m67rAUwN.net
ハイハイ理解できないから終了ね
800:デフォルトの名無しさん
19/01/30 12:38:11.42 m67rAUwN.net
>>776
知らないなら答えなくていいんじゃね？
ぼんくらは死ね
801:デフォルトの名無しさん
19/01/30 12:43:13.60 eltFPQSh.net
>>776
知らんなら答えなくて良いんじゃね？
過疎スレで無駄に煽るボンクラ
802:デフォルトの名無しさん
19/01/30 14:39:06.71 g/bNoaAl.net
無知が顔真っ赤にしてテラワロス
803:デフォルトの名無しさん
19/02/05 22:13:49.20 y7JCcM6u.net
>>782
無知が顔真っ赤にしてテラワロスっておまｗ
そんなんがほんとに面白い人とかいるのかね
MVVMはどこいったのｗ
スレタイと何も関係ない書き込みしちゃって頭おかしくないのボンクラｗｗｗｗ
804:デフォルトの名無しさん
19/02/05 22:15:30.79 y7JCcM6u.net
いやテラワロスってのはMVVMなんだろうな
無知なのでわからんわ
805:デフォルトの名無しさん
19/02/05 22:50:39.27 sDFzuzWu.net
>>778
＞INotifyPropertyChanged はバインド専門ではありません。
これって詭弁だよね
MVVM使う時点で通常のモデルにすると不便だからINotifyPropertyChanged使うだけ
806:デフォルトの名無しさん
19/02/05 22:57:59.44 sDFzuzWu.net
MVVMじゃない設計で作られた モデル、ビジネスロジックがあってそれをMVVMで使う場合どうすんの？ってことなんだろうけど
もう一層外からくるんだだけじゃうまくいかないからほとんどを作り直しすることになるんじゃないかな？
807:デフォルトの名無しさん
19/02/06 02:16:42.38 ar/eio3d.net
>>783
何日も前のに突然どうしたw
>>785
MMV間は好きにすればいいかと
自分はわざわざMでINotifyPChangedなんか使わんけど
808:デフォルトの名無しさん
19/02/06 09:39:48.85 DbH07QrE.net
俺なんかMVCすらよくわかんないな
Webは兎も角、それ以外はMVCだと言われてるアプリを見てもCからVを書き換えてるのだらけに見えちゃうんだな
これでいいんか？それとも世の大半が間違えてるのか？どっちなんだ
809:デフォルトの名無しさん
19/02/06 12:24:14.98 ar/eio3d.net
Cからvだけでしかないってのはダメだと思うが、結局その場合にちょうどいい程度に疎結合になってればいいと思うけどね
自分はMVにロジックも詰め込んで、でかくなってきたらMにする程度でやってる
810:デフォルトの名無しさん
19/02/11 03:23:52.16 h3xrvU+a.net
いつも疑問なんだけどMVVMでダイアログ表示するときなんでVMでShowDialog()しちゃいかんの？
MessengerでViewに送ってコールバックでってやるよりもVMをDataContextにぶっこんで直接操作したほうがわかりやすくない？
811:デフォルトの名無しさん
19/02/11 04:01:02.71 KW1QXsfq.net
>>790
MVVMのVMは、UIへの依存を排除することを試みるパターン。
なので、直接呼んで良いかと問われればNo
UIの知識に起因する処理を行いたいのであれば、UIから提供されたインターフェースを介してUI操作を行うMVPの採用を検討する。
結局のところ、MV*の違いは責任範囲の違いだけであり、MVPがMVVMよりV寄りに広いパターンなので、MVVMをベースにMVPにしても構わない。
ただしその場合、混乱の元なのでMVVMとは呼称すべきではない。
812:デフォルトの名無しさん
19/02/11 12:20:24.20 YckZaLLU.net
>>790
ぶっ込んで直接操作が何を指してるのかわからん。
そのダイアログを表示がらみだと思うけどもうちっと具体的に言ってくれ。
元のViewと対応したVMがあったとして、そこからダイアログ表示させる場合でいいんだよね？
813:デフォルトの名無しさん
19/02/11 13:34:01.09 NWPg0Oyv.net
>>792
すまん、説明が悪かったかも
あと無意識にWPFを前提に話してしまっていた
MainWindow
MainWindowViewModel
MainWindowModel
DialogWindow
DialogWindowViewModel
があったとしてMainWindowのボタン押下をトリガーにDialogWindowを表示したいとする
でWPFの昨日でVMにコマンドバインディングしていたボタンの処理の中で
DialogWindowのDataContextにDialogWindowViewModelを入れる
→MainWindowViewModelの中でDialogWindowのインスタンスを生成する
みたいな感じ
814:デフォルトの名無しさん
19/02/11 15:12:43.09 QkJqimZ7.net
VMからVを直接生成するのは禁じ手かと
てスタビリティーが担保できない
815:デフォルトの名無しさん
19/02/16 02:23:43.23 9HG1VuDS.net
7年前から何も状況変わってなくてワロス
816:デフォルトの名無しさん
19/02/16 02:52:06.72 9HG1VuDS.net
URLﾘﾝｸ(teratail.com)
わからないやつは使うな！
でほんとに使わなかったケースが多かっただけみたいだな
ユーザーの質がほんとひどい
難しい案件でだけ使えばいいがな