Contenu connexe
Similaire à 塹壕よりLivetとMVVM (20)
Plus de Hiroshi Maekawa (20)
塹壕よりLivetとMVVM
- 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
- 11. WPF導入まで
• UI改善の大号令 → デザイナが本気を出す
→ なんかPhotoshopみたいなデザインに
→ 偉い人が気に入ったっぽい→ ナニコレ…
→ WPFだと作れるらしいよ(`・ω・´)
• 2009年∼2010年くらいの技術を基盤に
– WPF 3.5
– 当然Livet以前。というか色々以前。
わんくま同盟 大阪勉強会 #50 11
- 13. MVVM???
• 当時のリソース
• 2009年2月のMSDNマガジン:http://
msdn.microsoft.com/ja-jp/magazine/dd419663.aspx
– ライブラリはまだ少なかった
• Prism, MVVM Lightはあったけど・・・
– 情報不足、知識不足。
– なのでとりあえずMSDNマガジンを必死で解読
した
わんくま同盟 大阪勉強会 #50 13
- 18. ハマった・・・
• V:VM:M = 1:1:1は有り得ない!!
– でもV:VMがn:mになるのは特に問題はない(バ
インディングがよろしくやってくれるので)
– VM : Mがn:mになって詰んだ
• VM肥大化症候群に感染
– 症例①:M → VM
– 症例②:V → VM
わんくま同盟 大阪勉強会 #50 18
- 24. View → ViewModelへの肥大化
• えーっと、コードビハインドはMVVMだと絶対に書いちゃ
いけないんだよね・・・
• んじゃ、図形をドラッグして、移動させて回転させ
て・・・とかも、VMにXPosとかYPosとかWidthとか
Heightとかつけて
• イベントハンドラからVMに処理を投げて・・・
• ・・・マジでややこしすぎて死ぬので注意。やったらダ
メ、ゼッタイ。
わんくま同盟 大阪勉強会 #50 24
- 25. 最初の導入で起こったこと
• ViewModelの肥大化・巨大化
– Model、View双方から処理がしみだしてきた
– 何が困る??
• Viewがしみだすと、単体テスト性が落ちる落ちる
• Modelがしみだすと、変更管理がえらく大変に
• 結局、処理境界が明示できないのはよくない
• ちなみに、当初の目標デザインは普通に達成
– デザイナさんとペアプロっぽいこともしたり
– WPFのUI自由度はもっともっと評価されるべき
わんくま同盟 大阪勉強会 #50 25
- 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
- 33. ViewModelは?
• ViewModelは描画に必要なデータのアクセサ/ストア
– 描画時のみに用いるデータ以外は実体をModelに移す
• 処理も右から左へ流すだけ。各モデルの協調処理は
アプリケーション層の仕事
• じゃあ何のためにいるの??
– ユニットテストをするため!
• UIに極力近いレベルで書けるので、シナリオテストができる
– Automation的なことをする場合にも役に立ちますよ
わんくま同盟 大阪勉強会 #50 33
- 36. というわけで方針
• Model層もアップデート通知有り。
– Livet使う!
– ViewModel間の協調動作は極力なしで。
• ややこしい動きをするUIはカスタムコント
ロールとして切り出す
– 適切なプロパティを公開し、Bindableに
– 汚いことは極力内部だけで解決する。
わんくま同盟 大阪勉強会 #50 36
- 43. TDD(ユニットテスト)の観点から
• 最上位のUIシナリオを記述できるのはやはり強力
– 継続的インテグレーションのお供に
• 逆に、VMを書くときは、「それが外部からちゃんとテストでき
るか」を意識すると◎
– ViewModel内でモーダルダイアログやメッセージボックス出してない
よね??
– それらを抽象化するMessenger機構は、テストでこそ真価を発揮す
る!
• VM層を使ったらBDD綺麗に書けそうじゃない??
– (宣伝)*Spec勉強会やります
– NaturalSpecやろうよ!
わんくま同盟 大阪勉強会 #50 43
- 44. まとめ
• 分かって欲しかったこと
– MVVMのハマりどころ
• ViewModelの肥大化を防ごう
– Livetの美味しさ
• MVVMへの適合度が高くて楽しい
– MVVMの持つ力
• 画面とロジックの分離しやすさ
• 単体テスト実行上のメリット
わんくま同盟 大阪勉強会 #50 44
Notes de l'éditeur
- \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