Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

WinFormsからWPFへ

3,062 views

Published on

WinFormsからWPFに移行するのを妨げるものは「責務」の理解不足かもしれない。「責務」をどのようにとらえるべきかWinFormsとWPFで同じものを実装してみます

Published in: Engineering
  • 教材ソースコード https://github.com/nenaaki/RPNCalculator
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Be the first to like this

WinFormsからWPFへ

  1. 1. C#勉強会2018/12 (初級編1)
  2. 2.  山本 礼貴(やまもと れき)  男性/46歳(2018年12月現在)  コアコンセプトテクノロジー  HQ事業部所属  C#とWPFを使うのが近年の主なお仕事  とうとうC/C++経験年数をC#経験年数が上 回って狼狽える このスライドに書いたことは個人の見解です。企業や団体を代表するもの ではありません。(お約束)
  3. 3.  UIフレームワークは悪くない  責務が分かると中級皆伝  WinFormsでMVPする  WPFでMVVMする  まとめ 教材のソースコード https://github.com/nenaaki/RPNCalcu lator
  4. 4. WinFormsもWPFも良いもの
  5. 5.  MVVMなにそれおいしいの?  WinFormsで機能を満たすには十分では?  なんかよくフリーズするってばっちゃん が言ってた  例外の意味がわからない  XAML見てると目がチカチカする (XMLだもの)
  6. 6.  簡単なものはすぐに動く(初心者に優しい)  Win32やMFCから入りやすい(古参に優しい)  C#の基礎の習得用にとても良い  学習コストが低い  簡単に落ちない  例外の意味が分かりやすい 登壇者は別にアンチWinFormsではない
  7. 7.  画面と業務ロジックを分離する習慣がついて いない  画面とセットでオブジェクト指向しているとか (大変残念なオブジェクト)  ユニットテストを書く習慣が出来ていない (コードカバレッジに対する無頓着)  手作業で動作確認しただけで満足するのは怖い  C#で中規模以上のプロジェクトをさほどやっ ていない
  8. 8.  この場合の「中規模」とは「2-3人のエン ジニアで1~3か月かけて作る程度のも の」くらい  「簡単である」と「中規模以上の業務用 途に使える」を両立させるにはベタ書き では足りない 中規模以上の開発では、それを効率的に回 すためのメソッドがある
  9. 9. 実はUIフレームワークの事はさほど重要ではない
  10. 10.  画面ではなくデータ構造を先に設計  保守性を向上  「責務」の明確化(今日のメイン)  コーディング規約も多少は決めよう  単体での動作保証  ユニットテストを書く  異常系に対するガード このあたりからがプロのお仕事
  11. 11.  画面基盤と業務ロジックの依存関係を疎にす る  データ構造とその操作ロジックと、変化を通知す る「ルール」をコーディングする(Model)  出来上がったデータ構造を表示する部分をコー ディングする(View)  データを操作する部分を「ルール」を使って実装 し、データの変化を画面に伝達する仕組みを作る (ControllerとかPresenterとかViewModel)  頭文字を取ってM-V-VM
  12. 12. 責務を意識したコードをWinFormsで作ってみよう
  13. 13.  やってみましょう  WinFormsはMVP(Model-View- Presenter)が実装しやすい  中間層(P)はUIフレームワークの差異を埋め るためのものだと考える  画面基盤が異なると簡単に共通化できない部分  無理をしなければ中間層までUTを書くことができ る
  14. 14.  逆ポーランド記法計算機(懐かしい!)  3 4 + と入力すると 7 と表示される  10 20 30 * と入力すると 10 600 と表示され、 さらに + と入力すると 610 と表示される  データ構造はスタックだけ  演算子はスタック2つを吸い取って1つの結果をス タックに積む  計算機のデータ構造とロジックと操作メソッ ドを作る(主に追加とクリア)  入力できるのは数値と空白と演算子だけ
  15. 15.  テキストボックス  1文字入力するごとに変化を伝達  何が入力できるかはモデルから情報を得る  正規表現でもいいけど、今回はモデルがガードし てくれる仕様  クリアボタン  モデル側のスタックをクリアする 現状を常に正しく表示する機能があればOK
  16. 16.  入力をModelに伝達  入力内容によってModelにどんな変化を与えるか を実装します(これもModel側にメソッドを実装)  クリアボタンはModelのクリアメソッド  WinFormsなのでイベントをインターフェー スを介して伝えると良さそう Presenterをあまり分厚くしないのが肝心 データの操作はModelの責務
  17. 17. じゃあWPFでやってみよう
  18. 18.  Model-View-ViewModel を採用  Modelは一切変更しない  変更が必要な場合、設計がまずい  ViewModelはWPFの流儀に則ってModel- View間をつなぐ役目
  19. 19.  XAMLを書く  テキストボックス  1文字入力する都度テキストの変化を ViewModelに伝達するようにBinidingする  クリアボタン  クリアコマンドもBindingする
  20. 20.  ICommandとINotifyPropertyChangedを 実装  業務では巷にある基盤を使うといいけど今回 は自作(簡単だから)  ViewModelをDataContextに設定  アプリケーションとして厳密に同じ操作 感になるかはここの出来次第  Behaviorもあるといい  イベントに応じた動きができるので
  21. 21. 結構あっさり行けたと思いますがいかがでしょうか
  22. 22.  責務をしっかりと把握していたらそんな に難しくはない  どこに機能を置くべきか十分検討しよう  どのUIフレームワークでも同じような作 りが出来そうだと思う?  これならユニットテストを書ける
  23. 23.  責務への意識がしっかりしていれば、UI フレームワークの差はさほど大きな障壁 ではない  基本はModel-View-中間層  実践できないと中規模のプロジェクトは任せ られない  中間層の部分を分厚くしないと簡単  ユニットテストをしっかり書こう
  24. 24.  ModelとViewのスレッドを分けて非同期化する場合、 中間層はどっちのスレッド?  Viewのスレッドにあるのが正しい  中間層はView自体に依存せずにUIフレームワークの個性 を吸収する責務がある(Viewのスレッドに居ないとできな いことだらけ。一番まずいのはUTを作りにくいこと)  Modelは非同期部を実装する(UI以外の部分を実装する責 務がある)  当然ながら非同期であるときViewも非同期前提のViewになる。 それは仕様の話であり依存性の話ではない  そもそも非同期は「並列化」と「UI止めないこと」を仕様に含 むのだから (理想通りに行かないケースはもちろんあるのですが、目指す価値はあります)
  25. 25.  Modelや中間層の処理でユーザーへの問い合わせが必 要なときはどうするの?  Modelで問い合わせが必要な状態は中間層に責務移譲すべ き(何が正しいかはModelが持つが、ユーザーからの見え方 は中間層かViewの責務)  中間層とViewの間でポピュラーなのはMessengerパター ン  View側に中間層が尋ねたいことを表示する受け口を持つ方法  問い合わせ中は「非確定状態」なので、非確定である概念 を中間層とViewに持ってもいい(これもパターンというよ りは仕様の話) MessengerとBehaviorの組み合わせで何でもできる
  26. 26.  ご清聴ありがとうございました。

×