WPF/Silverlight/WindowsPhoneから WinRTまで見据えた リッチクライアントModel設計 RIAアーキテクチャ研究会 第２回セミナー 尾上 雅則

アジェンダ 自己紹介・デモアプリ紹介 リッチクライアントのModel 古き良き設計 WinRTとAsync CTP/ReactiveExtensions リポジトリ非同期ステートフルModel まとめ

1.自己紹介・デモアプリ紹介 3プラットフォームで 実装された Twitterクライアント

1-1.自己紹介 尾上 雅則(おのうえ まさのり) 28歳 C#er / MVVMer Blog Twitter WPF/Silverlight/WindowsPhone/WindowsForms/AS P.NET/SQL Server/ReactiveExtensions勉強中 Blog The sea of fertility – http://ugaya40.net Twitter @ugaya40

１-2.デモアプリ ３Platform(WPF/Silverlight/WindowsPhone) Twitterクライアント WPF4 7.1

１-2.デモアプリ 設計(全プラットフォーム共通) なぜTwitterクライアントなのか Full MVVM リポジトリ非同期ステートフルModel なぜTwitterクライアントなのか DBアクセスは定型的に過ぎ、またオブジェクトの変化が少な くそもそも適切な粒度でリッチクライアントらしくまとめる には無理があると判断。 サンプルで使用するDBアクセスの方法を標準と思われがちな のが心外。DBアクセスは機能・非機能要件によって使い分け ましょう！

１-2.デモアプリ 使用ライブラリ MVVM Light Toolkit ReactiveOauth Reactive Extensions 軽量であるが故に、もっとも万能である。 http://mvvmlight.codeplex.com/ ReactiveOauth OAuthでの通信をReactive Extensionsを利用して使用して行える。 作者 : @neueccさん http://reactiveoauth.codeplex.com/ Reactive Extensions コールバック・イベントハンドラのネストの撲滅 イベント合成 詳細は　http://neue.cc　の各記事参照

2.リッチクライアントのModel 「リッチクライアント」のって 言わなきゃいけないのは何故？

2.リッチクライアントのModel MVVMパターンでのModelの位置づけは？ 外観 呼出 画面 画面を レンダリングする ための情報 ビジネス ドメイン (アプリの機能) Data Binding イベント

2.リッチクライアントのModel MVVMパターンでのModelの位置づけは？ 呼出 画面 View レンダリング情報 ViewModel ビジネス ドメイン Model Data Binding イベント

2.リッチクライアントのModel Modelとは？ アプリの外観・見た目・小手先 の操作性に関わる部分以外 UI想定前のアプリのイメージ ちょっと高度なバッチ処理を書 くようにModelを書く アプリの外観・見た目・小手先 の操作性以外の事をViewModel に混ぜないように書く ビジネスドメイン Model

2.リッチクライアントのModel Modelとは？ いわゆる業務的なインプットは 例えばユースケース定義の粒度。 ユースケース定義には アプリを使用するユーザー・外部シ ステムのアクション アプリが外部に及ぼす影響 などが定義されている。 入力仕掛りなどユースケース定義にはない。 ビジネスドメイン Model

2.リッチクライアントのModel Modelとは？ 操作情報 データ送信 Model クラス群 システム 外部システム(DBなども) データ受信 ユーザー 操作指標となる情報 (進捗・オブジェクトの生滅など) アウトプット 視認できる情報 (表示・帳票)

2.リッチクライアントのModel Modelとは？ クラス群 IN OUT システムが受ける入力・すべき出力、 それらをユースケース定義の様な粒度で過不足なく 満たす、 それがModelの仕様であると理解しています。

2.リッチクライアントのModel デモアプリに見るモデル(ユースケース１) ユーザーがアプリを起動する 認証されている場合 認証情報をストレージから復元する 認証されていない場合 認証する 次回のために認証情報を保存する 認証済になった場合 ユーザーの基本情報を表示する ユーザーのリストのタイムラインをTwitterから取得し、基本タ イムラインと合わせて表示する IN OUT

2.リッチクライアントのModel デモアプリに見るモデル(ユースケース２) ユーザーがポストする ユーザーが投稿をTwitterにポストする IN OUT

2.リッチクライアントのModel デモアプリに見るモデル(ユースケース３) ユーザーが更新したいタイムラインを更新操作する 指定されたタイムラインの新しいツイートをTwitterから取 得し、新しいツイートを追加表示する。 IN OUT

2.リッチクライアントのModel デモアプリに見るモデル 起動時 各種ストレージ IN ⑥認証情報 を保存 OUT ①認証情報の復元 を求める ②あれば返す ③なかったら通知 アプリケーション コンテキスト TwitterSampleApplication ④認証 認証サービス AuthorizeUrlBuilder,Authorizer ⑤認証情報 をセット

2.リッチクライアントのModel デモアプリに見るモデル アプリケーションコンテキスト TwitterSampleApplication IN OUT 認証済アカウントコンテキスト AccountContext タイムライン TimeLine 自ユーザー情報 Tweet Tweet Tweet Tweet

2.リッチクライアントのModel Model設計の注意点 多くの場合当然ただのデータの入れ物じゃだめ。プ ロパティ(状態)を持ち、メソッド(操作)を持ちます。 ここまでの内容を踏まえれば自明のことです。 ドメインモデル貧血症じゃだめな事が多い Modelをただのデータの入れ物にすると、ViewModelが データを詰めるんですか？。ViewModel/Viewの役割は？ また、サーバと通信するアプリであっても、クライ アント側にも当然Modelはあります。これもここま での内容を踏まえれば自明のことです。 IN OUT

2.リッチクライアントのModel Model基本まとめ ビジネスドメイン ステートフル(状態を持つ) ドメインモデル貧血症ではない(状態だけではない) Modelの粒度はユースケース定義を想像して！ 悩んだときは、「ではこの処理をModelでしなかっ た場合ViewModelがするのが適切なのか？」 なんでも設計の基本は、対象のINとOUTを明確に。 IN OUT

３.古き良き実装 WPF/MVVMなオールドスタイル

2.古き良きWPF/MVVMの実装 UIをブロックしないための非同期 Modelで時間をかかる処理を行った場合(ネットワー クアクセスなど)に、GUIをブロックして操作不能に してしまうようでは話にならない フリーズって言われちゃいますよね？ IN OUT

2.古き良きWPF/MVVMの実装 UIをブロックしないための非同期 ソリューションは非同期呼び出ししかありません。 本質的な問題は、それがView/ViewModelの責務(外 観や小手先の操作性)に属するのか、Modelの責務(ビ ジネスドメイン)に属するのかです。 IN OUT

2.古き良きWPF/MVVMの実装 UIをブロックしないための非同期 多くの人が直観と実装しやすさから、 Modelはすべて同期的に実装する ViewModelが非同期でModelを呼び出す 事を選択しました。 IN OUT しかし・・・

2.古き良きWPF/MVVMの実装 問題点 ・非同期前提のプラットフォーム Silverlight(WindowsPhone)を含むプラットフォーム は、Webアクセスなどが非同期APIでしか提供されて いません。 もしこのWPF/MVVMのベーシックスタイルで実装す ると。。。 あれ？非同期は小手先の操作性と判断して ViewModelに寄せたんじゃなかったの？ ViewModelとModel両方非同期って問題を複雑化さ せているだけじゃ・・・。 IN OUT

2.古き良きWPF/MVVMの実装 問題点 ・イベントの連鎖 ステートフルModelは、ViewModelへの通知にイベン トを使用します。イベントハンドラのネストが発生し やすいんですね。。。 IN OUT このプロパティの変更通知来たら・・・ フィルタリングして・・・ その時にこっちのプロパティの変更通知きたら・・・

2.古き良きWPF/MVVMの実装 問題点 ・イベントの連鎖 どう解決するのか？ いくつかアプローチはあります。 しかしはずれのアプローチは当然引きたくないわけ で・・・ ちょっと先を見てみることにします。 IN OUT

４.WinRTと Async CTP/Reactive Extensions 未来と未来へのソリューション

4.WinRT/Async CTP/ReactiveExtensions WinRTとは？ Windows 8から搭載される新たなネイティブの基盤 (Win32後継？) .NETから見ると普通に.NETに見えるらしい。 C++erはネイティブアプリをXAMLで書くようにな るらしい。 OSレベルで処理が50ミリ秒以上かかる可能性のある ものはすべて非同期APIしか提供されなくなる。 .NETだけやるにはあまり関係ない？いいえ。 Silverlight/WindowsPhoneも考慮すればMSの姿勢 は明らか。 IN OUT

4.WinRT/Async CTP/ReactiveExtensions WinRTとは？ WindowsPhoneを含むSilverlight環境に加えて、ついに Windows本体にも非同期が！ 非同期を克服しなきゃいけない！ そもそも非同期の何が嫌か 単純に書くのが面倒くさい ブロックのネストが増える。 異常系まで絡むとわけわかめ。 しかもリトライとかしなきゃいけないネットワークアクセス が非同期とか・・・ とにかくネストが醜い。 では、非同期処理へのソリューションは？？ IN OUT

4.WinRT/Async CTP/ReactiveExtensions Async CTPとは？ OUT こんなに簡単に！ 詳しくはhttp://ufcpp.netで！

4.WinRT/Async CTP/ReactiveExtensions Reactive Extensionsとは？ LINQ to Events by @neuecc イベント・非同期などのネストをフラットに、イベ ントや非同期を時間を超えて合成・フィルタリング など。 LINQ to Objectがループブロックのネストを殺害し たように、本当に非同期やイベントのネストが消え てなくなります！ 多少はデモアプリの実装として紹介しますが、詳し くはhttp://neue.ccにて。 IN OUT

５.リポジトリ非同期ステートフルModel 提案

５．リポジトリ非同期ステートフルModel リポジトリって？ リポジトリとは？ 外部システムとの通信 ファイルアクセス DBアクセス など、システムにとって厄介な異常系を引き起こしか ねない呼び出しを、リポジトリの呼び出しと今回は定 義しています。 語源はリポジトリパターンからです。 IN OUT

５．リポジトリ非同期ステートフルModel リポジトリがソースコードに与える影響？ リポジトリは、ソースコードにとって テストが容易でない 非同期のネストを生む(Silverlight/今後) リトライなど厄介な要件が多い などの問題を引き起こす要因です。 逆に言えば、これらリポジトリを除いたソースコード は比較的可読性に優れ、テストも比較的容易です。 IN OUT

５．リポジトリ非同期ステートフルModel リポジトリ非同期ステートフルModel リポジトリ非同期ステートフルModelとは、 リポジトリへのアクセスをすべてReactiveExtensions の返す継続(?)に置き換えたModelです。 このModelでは、リポジトリにアクセスするメソッド はすべてIObservable<T>を返します。 なんの事かわからないでしょうし、 実際どういったメリットがあるのかわかりにくいと思 いますので、デモアプリのソースコードから説明しま す。 IN OUT

５．リポジトリ非同期ステートフルModel リポジトリ非同期ステートフルModel リポジトリ非同期ステートフルModelとは、 リポジトリへのアクセスをすべてReactiveExtensions の返す継続(?)に置き換えたModelです。 このModelでは、リポジトリにアクセスするメソッド はすべてIOservable<T>を返します。 なんの事かわからないでしょうし、 実際どういったメリットがあるのかわかりにくいと思 いますので、デモアプリのソースコードから説明しま す。 IN OUT

５．リポジトリ非同期ステートフルModel Web APIへのリトライ処理 不調な事で有名なTwitter API。気分よく使うにはリト ライ処理が必須です。 IN OUT Twitterに特定のユーザーの情報を問い合わせています。 この例では異常時に2回まで1.5秒ごとにリトライをかけています。 (TwitterApiクラス)

５．リポジトリ非同期ステートフルModel 多段Webアクセス 大きすぎるので、ソースコードで確認してください。 最低でも３段の連鎖WebAPIアクセスがネストすることなく順番に実行されます。 (AccountContextクラス) IN

５．リポジトリ非同期ステートフルModel 多段Webアクセスーカーソル処理 IN OUT フォロワー数を5000件づつカーソルとともに返してくれるAPIを叩いています。 カーソルが0になるまでアクセスを繰り返して、結果を集計して一つにして返してくれます。 もちろん各アクセスごとにリトライ1.5秒ごと２回までしてます。

５．リポジトリ非同期ステートフルModel リポジトリをすべて非同期にしたので 非同期の責務はすべてModel側に集中することになり ました。 異常系がきちんと考慮されているにもかかわらず、異 常系コードがほとんど出てこないModelコードになり ました。 LINQ的な機能が使えるので、イベント・非同期の結果 のフィルタリングもでき、ifのネストすら減りました。 IN OUT

６.まとめ

６.まとめ Modelについての基本 継続や非同期やらの扱いに関係なく、Modelが満たす べき要件は同じです。 ViewModelとModelの責務の違いをしっかりと意識し て開発すれば、ModelはUIの影響を受けないため、非 常に教科書的な、クラス構造が仕様を表すようなOOP の実装に近くなってきます。 Modelをより強く意識していただけるようになる一助 となっていれば幸いです。 IN OUT

６.まとめ リポジトリ非同期ステートフルModel IN OUT

６.まとめ デモアプリについての言い訳 まずModelですが、僕がRxスキルが未熟なためまだ汚 いです。 そしてViewModelも、MVVM Lightの上に即興で構築 した適当なインフラを急遽あつらえたものなので汚い です。 しかしこの資料とソースは公開します。今後もリファ クタしていくたたき台にしようとも思っているので、 ぜひ積極的に参加していただいたり、ご意見をいただ けるとありがたいと思っております。 IN OUT

ご清聴 ありがとうございました