塹壕よりLivetとMVVM
- 1. 塹壕よりLivetとMVVM ＠Posaune わんくま同盟 大阪勉強会 #50 1
- 2. お前だれよ？ • まえかわ ひろし です • a.k.a @Posaune / posaunehm – ちなみにPosauneは独語でとろんぼーん。 • いるところ – Twitter – Blog：http://posaune.hatenablog.com/ – Github：https://github.com/posaunehm/ わんくま同盟 大阪勉強会 #50 2
- 3. なにもの？ • 一介のC#好き（メーカー所属）です。 – XAML >>>越えられない壁>>>Winform – F#も素敵ですよね。 • アジャイル界隈のほうがよく見かけます – 京都アジャイル勉強会（#京アジャ） – TABOK勉強会 関西 （#tabokjp） – あとはTDD界隈とか、CI界隈とか わんくま同盟 大阪勉強会 #50 3
- 4. さて本題。 わんくま同盟 大阪勉強会 #50 4
- 5. タイトルの元ネタ • 塹壕よりScrumとXP – Agileの日本語書籍として 最初に読むべきPDF – フリーだよ！！ – （宣伝）興味があれば #京アジャ へ –How we do Scrum わんくま同盟 大阪勉強会 #50 5
- 6. How We Do MVVM わんくま同盟 大阪勉強会 #50 6
- 7. 今日はなす事 • 何もわからないままWPFを業務導入して • とりあえずの設計パターンてことでMVVMを検討して • 実装して、痛い目にあって • 二度目のプロジェクトで色々試行錯誤した末に • Livetに出会っていろいろ思うことがあって • でもまだ模索中で • そんな話をします。 わんくま同盟 大阪勉強会 #50 7
- 8. おことわり • 本日の話は、あくまで個人が思ったことで す。 • 間違い・勘違い・思い違い、色いろあると 思います。ツッコミ大歓迎。 • 頭からの否定・肯定はやめてね！！ • こわくないよ！ わんくま同盟 大阪勉強会 #50 8
- 9. Agenda • イントロ • はじめての挑戦 • 二度目のリベンジ • 別の世界から眺めてみて わんくま同盟 大阪勉強会 #50 9
- 10. はじめての挑戦 わんくま同盟 大阪勉強会 #50 10
- 11. WPF導入まで • UI改善の大号令 → デザイナが本気を出す → なんかPhotoshopみたいなデザインに → 偉い人が気に入ったっぽい→ ﾅﾆｺﾚ… → WPFだと作れるらしいよ(｀・ω・´) • 2009年∼2010年くらいの技術を基盤に – WPF 3.5 – 当然Livet以前。というか色々以前。 わんくま同盟 大阪勉強会 #50 11
- 12. さて、WPF • とりあえずデザインはデザイナさんからAI データでもらうとして・・・ • 設計はどうする？？ – 元ソフト（C++/MFC : Doc-Viewアーキテク チャ）のロジックを受け継ぐ必要あり – なんかWPFではMVVMってのが流行りらしい よ？ わんくま同盟 大阪勉強会 #50 12
- 13. MVVM？？？ • 当時のリソース • 2009年2月のMSDNマガジン：http:// msdn.microsoft.com/ja-jp/magazine/dd419663.aspx – ライブラリはまだ少なかった • Prism, MVVM Lightはあったけど・・・ – 情報不足、知識不足。 – なのでとりあえずMSDNマガジンを必死で解読 した わんくま同盟 大阪勉強会 #50 13
- 14. こんな感じの理解 • とりあえずViewとViewModelをバインディ ングとコマンドでつなぐらしい – 単体テストも便利になるらしい – IDataErrorInfoとかを使うともっと幸せになれ るらしい • ViewとViewModelは一対一で対応かな？ • Modelはなんかデータの置物っぽいね。 わんくま同盟 大阪勉強会 #50 14
- 15. こんな感じの理解 ・とりあえず3つに分けて・・・ ・Viewはまとまりで切り出して・・・ ・対応するVMとMを作ればいいのか！ わんくま同盟 大阪勉強会 #50 15
- 16. こんな感じの理解 ・ViewからはなんかCommandとかいうものでViewModelに操作を伝えて… ・ViewModelでそれを処理するんだよね。んでModelのデータを触ると。 ・んで変更したプロパティを通知するとふしぎぱわーで更新できるのか。 わんくま同盟 大阪勉強会 #50 16
- 17. まだつっこまないでね！！ わんくま同盟 大阪勉強会 #50 17
- 18. ハマった・・・ • V:VM:M = 1:1:1は有り得ない！！ – でもV:VMがn:mになるのは特に問題はない（バ インディングがよろしくやってくれるので） – VM : Mがn:mになって詰んだ • VM肥大化症候群に感染 – 症例①：M → VM – 症例②：V → VM わんくま同盟 大阪勉強会 #50 18
- 19. ① VM:Mがn:mになって死ぬ • 表示のバックエンドに過ぎないVMとModel が同じ構造してくれるわけない – 普通はVMは複数のModelを持つ – Modelは複数のVMによって共有もされる • ほとんどのサンプルはV:VM:M = 1:1:1の構 造なので誤解を生みやすい わんくま同盟 大阪勉強会 #50 19
- 20. ① VM:Mがn:mになって死ぬ 誰かが「何がどう変わったか」を通知しなければいけない わんくま同盟 大阪勉強会 #50 20
- 21. 解決策：VMが頑張る • 自分の操作によってどのプロパティが変化 するかを完全に管理する約束に • 他ViewModelに影響を与える場合は統合 • どうしようもない場合はObserverパターン を導入 わんくま同盟 大阪勉強会 #50 21
- 22. VMが頑張る図 VMは自分の操作によってModelがどう変化するかを完全に 把握する必要がある。。。 わんくま同盟 大阪勉強会 #50 22
- 23. ② VM肥大化症候群 • 一つの原因は先に説明した更新通知。 – そもそもVMが更新通知をするということは、 Modelの処理内容がほとんどVMにでてる • もう一つは、Viewで解決すべき問題が ViewModelへ渡ってしまったこと わんくま同盟 大阪勉強会 #50 23
- 24. View → ViewModelへの肥大化 • えーっと、コードビハインドはMVVMだと絶対に書いちゃ いけないんだよね・・・ • んじゃ、図形をドラッグして、移動させて回転させ て・・・とかも、VMにXPosとかYPosとかWidthとか Heightとかつけて • イベントハンドラからVMに処理を投げて・・・ • ・・・マジでややこしすぎて死ぬので注意。やったらダ メ、ゼッタイ。 わんくま同盟 大阪勉強会 #50 24
- 25. 最初の導入で起こったこと • ViewModelの肥大化・巨大化 – Model、View双方から処理がしみだしてきた – 何が困る？？ • Viewがしみだすと、単体テスト性が落ちる落ちる • Modelがしみだすと、変更管理がえらく大変に • 結局、処理境界が明示できないのはよくない • ちなみに、当初の目標デザインは普通に達成 – デザイナさんとペアプロっぽいこともしたり – WPFのUI自由度はもっともっと評価されるべき わんくま同盟 大阪勉強会 #50 25
- 26. 二度目の導入 わんくま同盟 大阪勉強会 #50 26
- 27. 二度目導入まで • 結構なインターバルあります（一年くらい） • その間はSilverlightをさわったり、Javascript/ HTML5を触ったりと、わりと雑多な感じでお仕事 • 画像のフィルタリングが必要な案件で、WPFでさ くっとEffect作ってサンプル出したら、採用に → WPF二件目ktkr！ • 時代はWPF4/VS2010！ – MVVMライブラリも充実期に。 わんくま同盟 大阪勉強会 #50 27
- 28. 一度目の反省・・・が解決しない • ViewModelが更新をして回るのはなんかおかしい ぞ・・・？機能が多すぎる。 – Model→ViewModelの更新通知はあるべき。 – そもそもModelってなんだろう？？ • 「コードビハインドを書いちゃダメ」は悪魔の言葉 – 必要なコードビハインドだって有るだろ・・・ – でも切り分けしとかないとカオスになりそうだしなぁ わんくま同盟 大阪勉強会 #50 28
- 29. そんな時にLivet発見 わんくま同盟 大阪勉強会 #50 29
- 30. Model再考 • 影響を受けたもの – Livet（ver 0.9x） • Modelに提供された更新通知 – ドメイン駆動設計 • レイヤーアーキテクチャ – UI – アプリケーション – ドメイン – インフラストラクチャ わんくま同盟 大阪勉強会 #50 30
- 31. 私のModel理解 • Livetで推奨されているように、Model層は更新通知を 持つべき – Observer形式はカオスになりがち • DDDでのドメイン層がMVVMのModelに該当する – データクラス（エンティティ）はModelの最下層 – 最外側にあるクラスにはLivet準拠のModelにする • ならばViewModel = アプリケーション層？ – 個人的には、否。ViewModelはあくまでUI層。 – アプリケーション層はModelの最上層に属する わんくま同盟 大阪勉強会 #50 31
- 32. Modelは大きいものでしょ わんくま同盟 大阪勉強会 #50 32
- 33. ViewModelは？ • ViewModelは描画に必要なデータのアクセサ/ストア – 描画時のみに用いるデータ以外は実体をModelに移す • 処理も右から左へ流すだけ。各モデルの協調処理は アプリケーション層の仕事 • じゃあ何のためにいるの？？ – ユニットテストをするため！ • UIに極力近いレベルで書けるので、シナリオテストができる – Automation的なことをする場合にも役に立ちますよ わんくま同盟 大阪勉強会 #50 33
- 34. コードビハインドの扱い わんくま同盟 大阪勉強会 #50 34
- 35. カスタムコントロール！ • どうしてもUI上ややこしい処理が必要な場 合は、プロパティやイベントを適切に公開 してやればいい！ – カスタムコントロール内部はコードビハインド でガリガリ描画 – 外側から見るとほぼバインディングだけで成り 立っているようにする わんくま同盟 大阪勉強会 #50 35
- 36. というわけで方針 • Model層もアップデート通知有り。 – Livet使う！ – ViewModel間の協調動作は極力なしで。 • ややこしい動きをするUIはカスタムコント ロールとして切り出す – 適切なプロパティを公開し、Bindableに – 汚いことは極力内部だけで解決する。 わんくま同盟 大阪勉強会 #50 36
- 37. Livetを使ってみて（ver.0.99） • Livetは使えば使うほど、使い手のことを考えて作って いるのかが分かる。 – 更新通知付きModel – Blend親和性の高いUI拡張 – Messenger機構 • 機能をフルに活かそうとすると、MVVMが自然に身につ くように作ってあるんではないだろうか（想像） • 個人的に超嬉しいのが、 CreateReadOnlyDispatcherCollection わんくま同盟 大阪勉強会 #50 37
- 38. CreateReadOnlyDispatcherCollection • 一言で言うと、「Modelのコレクションか らViewModelのコレクションを作る」 • XAMLではコレクション系UIをいかにうま く使うかが勝負（だと思ってます） – 極論、ListViewでなんだってできる • ただし、MVVMを真面目にやっていると 困ったことが・・・ わんくま同盟 大阪勉強会 #50 38
- 39. Collectionの変換 ・ModelのCollectionをViewModelのCollectionに変換 ・Collectionを同期する必要があるので結構ややこしい CreateReadOnlyDispatcherCollectionで一発変換！ わんくま同盟 大阪勉強会 #50 39
- 40. 二度目の導入まとめ • 設計方針は現時点では割と満足 • これから他のメンバーにどう徹底していく かが課題 – 実は今はプロジェクトからは一線を引いていた り・・・ – 世の中からWindowsFormが消え去りますよう に:-P わんくま同盟 大阪勉強会 #50 40
- 41. 別の世界から眺めてみて わんくま同盟 大阪勉強会 #50 41
- 42. WindowsFormから見ると • 現在、業務はWindowsFormに先祖返り • Bindingで自然にViewとControllerの分離がで きるWPFの有難味が身にしみます、はい。 • MVVMパターンを体験した後だと、「これ はPresenterに吐き出すべきだな」がなんと なく分かる – ※個人の感想です。一般的な効果を保（ry わんくま同盟 大阪勉強会 #50 42
- 43. TDD（ユニットテスト）の観点から • 最上位のUIシナリオを記述できるのはやはり強力 – 継続的インテグレーションのお供に • 逆に、VMを書くときは、「それが外部からちゃんとテストでき るか」を意識すると◎ – ViewModel内でモーダルダイアログやメッセージボックス出してない よね？？ – それらを抽象化するMessenger機構は、テストでこそ真価を発揮す る！ • VM層を使ったらBDD綺麗に書けそうじゃない？？ – （宣伝）*Spec勉強会やります – NaturalSpecやろうよ！ わんくま同盟 大阪勉強会 #50 43
- 44. まとめ • 分かって欲しかったこと – MVVMのハマりどころ • ViewModelの肥大化を防ごう – Livetの美味しさ • MVVMへの適合度が高くて楽しい – MVVMの持つ力 • 画面とロジックの分離しやすさ • 単体テスト実行上のメリット わんくま同盟 大阪勉強会 #50 44
- 45. 最後にもう一度おことわり • 本日の話は、あくまで個人が思ったことです。 ツッコミ大歓迎。 • そもそも設計に絶対の正解はないです。 • あえて言うなら、現場で頭を抱えてひねり出し たものでしょう、きっと。 • でもひねり出すためには、色々なパラダイムを 知っていることが必要です。 • 今回の話がそんな時の一助となれば幸いです。 わんくま同盟 大阪勉強会 #50 45
Editor's Notes
- #2: \n
- #3: \n
- #4: \n
- #5: \n
- #6: \n
- #7: \n
- #8: \n
- #9: \n
- #10: \n
- #11: \n
- #12: \n
- #13: \n
- #14: \n
- #15: \n
- #16: \n
- #17: \n
- #18: \n
- #19: \n
- #20: \n
- #21: \n
- #22: \n
- #23: \n
- #24: \n
- #25: \n
- #26: \n
- #27: \n
- #28: \n
- #29: \n
- #30: \n
- #31: \n
- #32: \n
- #33: \n
- #34: \n
- #35: \n
- #36: \n
- #37: \n
- #38: \n
- #39: \n
- #40: \n
- #41: \n
- #42: \n
- #43: \n
- #44: \n
- #45: \n
- #46: \n