MVVMについて語ろう

**デフォルトの名無しさん** · 2012/06/06(水) 11:03:33.21

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

**デフォルトの名無しさん** · 2012/07/24(火) 08:39:50.00

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

**デフォルトの名無しさん** · 2012/07/24(火) 10:53:05.83

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

**デフォルトの名無しさん** · 2012/07/24(火) 13:52:17.88

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

**デフォルトの名無しさん** · 2012/08/08(水) 10:33:09.91

MVVMerなら即VS2012にするよな？

**デフォルトの名無しさん** · 2012/08/08(水) 10:47:52.07

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

**デフォルトの名無しさん** · 2012/08/08(水) 19:08:07.03

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

**デフォルトの名無しさん** · 2012/08/08(水) 19:16:36.34

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

**デフォルトの名無しさん** · 2012/08/08(水) 19:20:24.35

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

**デフォルトの名無しさん** · 2012/08/08(水) 19:33:31.78

MVVMはWindows7以降用技術です

**デフォルトの名無しさん** · 2012/08/08(水) 23:10:28.72

いいえ、ウェブ技術(JavaScript)です。

http://ameblo.jp/ca-1pixel/entry-11298459074.html

knockout.js (http://knockoutjs.com/)

knockout.jsはMVVM（Model-View-ViewModel）パターンのフレームワークです。
双方向データバインディングやアイテムテンプレート等の機能があり、SilverlightやWPF開発者にはかなりとっつきやすいフレームワークだと思います。

**デフォルトの名無しさん** · 2012/08/10(金) 00:03:20.35

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

**デフォルトの名無しさん** · 2012/08/10(金) 00:29:56.78

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

**デフォルトの名無しさん** · 2012/08/10(金) 00:44:36.96

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

**デフォルトの名無しさん** · 2012/08/10(金) 10:33:45.16

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

**デフォルトの名無しさん** · 2012/08/10(金) 12:38:35.91

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

**デフォルトの名無しさん** · 2012/08/10(金) 13:57:56.40

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

…っという話かな？

**デフォルトの名無しさん** · 2012/08/10(金) 22:33:15.87

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

**デフォルトの名無しさん** · 2012/08/10(金) 22:48:20.32

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

**デフォルトの名無しさん** · 2012/08/10(金) 22:52:44.04

MVVMのどういう場面だ？

**デフォルトの名無しさん** · 2012/08/11(土) 01:28:16.52

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

**デフォルトの名無しさん** · 2012/09/08(土) 12:02:20.04

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

**デフォルトの名無しさん** · 2012/09/08(土) 12:30:15.15

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

**デフォルトの名無しさん** · 2012/09/08(土) 12:58:28.48

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

**デフォルトの名無しさん** · 2012/09/08(土) 23:34:49.46

MSほど多様な製品を長期に渡ってサポートしてくれるとこは他にない。
VB6が世に出てから14年経つがWin8でも公式にサポートされた。

リプレースするにも金がかかるから動く限りは保守しながら使いたいって客は案外多いよ。

**デフォルトの名無しさん** · 2012/09/10(月) 11:25:40.15

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

**デフォルトの名無しさん** · 2012/09/21(金) 19:02:26.84

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

**デフォルトの名無しさん** · 2012/09/21(金) 19:03:37.99

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

**デフォルトの名無しさん** · 2012/09/21(金) 20:02:31.93

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

**デフォルトの名無しさん** · 2012/09/21(金) 21:11:01.59

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

**デフォルトの名無しさん** · 2012/10/06(土) 11:05:26.15

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

**デフォルトの名無しさん** · 2012/10/08(月) 09:21:35.40

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

**デフォルトの名無しさん** · 2012/10/08(月) 19:09:14.56

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

**デフォルトの名無しさん** · 2012/10/08(月) 20:43:24.80

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

**デフォルトの名無しさん** · 2012/10/08(月) 21:26:12.25

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

**デフォルトの名無しさん** · 2012/10/13(土) 17:02:29.65

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

**デフォルトの名無しさん** · 2012/10/13(土) 17:08:27.07

イベント

**デフォルトの名無しさん** · 2012/10/13(土) 19:31:26.75

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

**デフォルトの名無しさん** · 2012/10/14(日) 16:54:03.98

徐々にウェブの世界でも
MVVMが浸透してきたな。

MVCだけじゃ、いろいろ足りない。

**デフォルトの名無しさん** · 2012/10/14(日) 17:05:03.26

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

**デフォルトの名無しさん** · 2012/10/14(日) 20:38:40.26

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

**デフォルトの名無しさん** · 2012/10/16(火) 00:33:06.45

>>340
テンプレート使ったこと無いの？

サーバーでテンプレートに渡す値を
値そのまま渡せばそれがAjaxになる。

サーバーサイドアプリ - テンプレート処理
なのだから、確実にAjaxの方が簡単になってる。；

**デフォルトの名無しさん** · 2012/10/16(火) 01:04:33.51

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

**デフォルトの名無しさん** · 2012/10/16(火) 01:11:23.92

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

**デフォルトの名無しさん** · 2012/10/16(火) 18:10:03.69

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

受けとったJSONオブジェクトを元に、自力でDOMを書き換えても良いし。

**デフォルトの名無しさん** · 2012/10/16(火) 20:40:35.72

クライアントが以前より負荷が高くなるという問題もあるけれど、
以前というのはもう十数年前だったら問題になるというレベルで
今はクライアントは十分な性能を持ってるしね。
ブラウザ自体も速くなった。

それに比べるとネットワークはまだまだ遅いわけで、
テンプレートはローカルにキャッシュしておいて
データ量を減らすほうが得策かな。
サーバー負荷も低くなるし。

これぐらいだれでも思っていることで、
普通サーバーでやるもんだろで終わってる人ってのは
何も考えてないとしか思えないけどｗ

**デフォルトの名無しさん** · 2012/10/16(火) 20:43:20.12

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:07:29.77

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:18:45.66

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:24:48.64

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:30:02.30

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

バリデーションなら単なるJavaScriptで良い

**デフォルトの名無しさん** · 2012/10/16(火) 21:31:42.33

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:32:50.76

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:34:43.44

話し理解できてないの？ｗ

バリデーションをAjaxで行う＝サーバーで通信して行うから、
そのバリデーションはサーバーでやってる事になるだろうって話だ。

あと、サーバーでやらないなんて一言も言ってない。
なんでこんなに文章読めないの？馬鹿なの？

**デフォルトの名無しさん** · 2012/10/16(火) 21:36:01.79

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:36:16.18

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:38:07.68

うーん？
> Ajaxはオプションだろ

>>349が
オプションでやるって書いてあるじゃん。

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:38:54.60

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:40:19.92

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:40:51.87

>>358
みんな＝お前以外

**デフォルトの名無しさん** · 2012/10/16(火) 21:41:02.38

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:41:14.80

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:43:13.41

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:45:12.56

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:58:42.34

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

**デフォルトの名無しさん** · 2012/10/16(火) 21:59:49.81

×今時Ajax
○いまさらAjax

**デフォルトの名無しさん** · 2012/10/16(火) 22:12:49.60

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

**デフォルトの名無しさん** · 2012/10/16(火) 22:16:13.83

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

**デフォルトの名無しさん** · 2012/10/16(火) 22:16:48.57

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

**デフォルトの名無しさん** · 2012/10/16(火) 22:17:15.76

node.js最強

**デフォルトの名無しさん** · 2012/10/16(火) 22:20:02.67

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

**デフォルトの名無しさん** · 2012/10/16(火) 22:22:07.06

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

**デフォルトの名無しさん** · 2012/10/16(火) 22:30:55.59

下見てもつまらないよ

**デフォルトの名無しさん** · 2012/10/17(水) 01:35:57.07

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

**デフォルトの名無しさん** · 2012/10/21(日) 22:42:39.14

なんか最近尾上の言うことがぶれすぎ
先月ぐらいから少しずつさりげなくぶれ始めてたんだが
なにがあったんだ？

コードビハインドとか頭おかしくなったのか？
その内容自体は宗教だからどうでもいいが
さんざん自分の考えと違うやつを罵倒してきた人間が
そこまでころっと価値観変えてどうなんだ？

**デフォルトの名無しさん** · 2012/10/21(日) 22:56:05.22

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

**デフォルトの名無しさん** · 2012/10/22(月) 06:04:37.89

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

**デフォルトの名無しさん** · 2012/10/22(月) 08:48:01.98

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

**デフォルトの名無しさん** · 2012/10/22(月) 09:20:38.69

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

**デフォルトの名無しさん** · 2012/10/22(月) 09:41:07.23

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

**デフォルトの名無しさん** · 2012/10/22(月) 12:14:52.36

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

**デフォルトの名無しさん** · 2012/10/24(水) 00:05:27.67

Blend 2012まだかよ

**デフォルトの名無しさん** · 2012/11/02(金) 12:07:46.01

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

**デフォルトの名無しさん** · 2012/11/02(金) 14:00:24.51

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

**デフォルトの名無しさん** · 2012/11/02(金) 14:32:57.66

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

**デフォルトの名無しさん** · 2012/11/04(日) 22:35:06.98

>>383
コードビハインドってViewって認識なの？
否定じゃなくて単純に質問。

**デフォルトの名無しさん** · 2012/11/04(日) 22:49:04.80

Viewとみなすのがふつう
ビヘイビアもコードビハインドの一形態なので同じくView

**デフォルトの名無しさん** · 2012/11/05(月) 20:21:18.14

結局
vmに置かれるviewに強く関係するけど
共通ロジックの置き場がない

**デフォルトの名無しさん** · 2012/11/05(月) 23:16:15.79

共通ロジックならUTILとかに置けばいいだろ？

**デフォルトの名無しさん** · 2012/11/05(月) 23:36:53.45

>>386
Viewとみなすのは分かったんだけど
VMじゃななくてVとみなす理由はなんなのかな？

**デフォルトの名無しさん** · 2012/11/05(月) 23:38:49.26

>>389
ビューと不可分だから

**デフォルトの名無しさん** · 2012/11/05(月) 23:45:04.35

>>390
WinFormsのコードビハインドなら不可分といえなくもないけど
WPFはそうともいえないんじゃね？

**デフォルトの名無しさん** · 2012/11/05(月) 23:51:07.82

>>391
この場合の不可分は「単体テスト可能かどうか」な。
ユーザーコントロールやウィンドウのクラスに対してXAMLを差し替えることは普通はできないし
無理矢理読み込むファイルを変えたとしてもコードビハインドからコントロールを直接触ってるから
結局ビューを表示して実際に操作してみないとテストできないわけ。
だからコードをビューから分離してビューなしでテストできるようにしましょうっていうのがVM。

**デフォルトの名無しさん** · 2012/11/06(火) 00:03:14.09

>>392
なるほどねー

**デフォルトの名無しさん** · 2012/11/06(火) 00:05:46.84

>>387
ViewModelsってフォルダにそういう機能のクラスを作ればええんや
まーそもそも、Views、ViewModels、Modelsってフォルダ群もなんだかなーって気もするが
そのほかのフォルダ構成でやってるやつおる？

**デフォルトの名無しさん** · 2012/11/06(火) 03:50:39.94

フォルダ分けない方が楽な気はするがその3つにしてるな

**デフォルトの名無しさん** · 2012/11/06(火) 15:16:09.04

М氏も「MVVM＝コードビハインド無し」みたいな誤解撒き散らしてたし
「フルMVVM」って造語が誤解生んだのも事実
でもだからなんなの？勝手に誤解してずっこけたの本人のせいじゃん
お前が元信者だから裏切られた感強いだけだろ

**デフォルトの名無しさん** · 2012/11/06(火) 16:34:58.61

dynamicを積極的に使うのはどうだろう
VMがdynamic型でVへの参照を保持して動的にVのメソッドを呼ぶようにすれば、
メッセージやインターフェイスを介さなくてもVM->Vの密結合が避けられる。
dynamicなら完全に透過的なプロキシが使えるから、たとえばメモリリークの恐れがある箇所は
WeakReferenceでビューへの参照を持ち、ビューがGCされたらnullオブジェクトとして振る舞う
ようなプロキシを利用すれば、メモリリークの問題もコードの見た目を全く汚さずに解決。
型無しがダメだというならメッセージだって同じようなもんだよね。
(Vが当該メッセージをサポートしているかどうかはコンパイル時にチェックされないという意味で)

**デフォルトの名無しさん** · 2012/11/06(火) 17:03:56.14

マルチキャストが必要な場合(メモリリークを避けるためにイベントを置き換えるとき)もこんな感じで
class HogeModel {
//弱参照で複数のリスナへの参照を持つ複合プロキシ
private WeakCompositeProxy listeners;
public void AddListener(dynamic listener) { listeners.Add(listener); }
private void RaiseSomethingHappened() {
　//登録された全てのリスナのOnSomethingHappenedメソッドを呼び出す
　//リスナがOnSomethingHappenedメソッドを持たない場合は何もしない
　((dynamic)listeners).OnSomethingHappened();
}
}

**デフォルトの名無しさん** · 2012/11/09(金) 04:16:24.83

MVVMってメトロになってもやること変わらんの？
技術的にはあっちが本流だと思うんだけど

**デフォルトの名無しさん** · 2012/11/09(金) 09:11:57.38

どうしてデザパタが環境によって変化すると思うんだｗ　技術じゃないぜ。概念だろ。