Recommended
More Related Content
What's hot
What's hot (20)
Similar to 塹壕よりLivetとMVVM
Similar to 塹壕よりLivetとMVVM (20)
More from Hiroshi Maekawa
More from Hiroshi Maekawa (20)
Recently uploaded
Recently uploaded (11)
塹壕より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
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n
- \n