塹壕よりLivetとMVVM

11,060 views

Published on

わんくま大阪勉強会 #50での発表資料です。

Published in: Technology
0 Comments
18 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
11,060
On SlideShare
0
From Embeds
0
Number of Embeds
1,145
Actions
Shares
0
Downloads
97
Comments
0
Likes
18
Embeds 0
No embeds

No notes for slide
  • \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
  • 塹壕よりLivetとMVVM

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

    ×