RIA アーキテクチャー研究会 第3回 セミナーに参加してきた #riaarch
RIAというキーワードと、技術的側面に興味があったで見つけ次第即参加申込して行ってきました。
会場はマイクロソフト本社@品川。最近ココに来る機械も多いですね。とは言え日中昼間は始めてかも。
早速参加メモ。(この日は勉強会ハシゴ参戦してきたので1日で2エントリ分収めないと、なのです(^^;))
セッション1 C#次世代非同期処理概説 Task vs Reactive Extensions
- 講師:河合 宜文さん (TwitterID@neuecc)
Silverlight 5でのTaskの搭載、Visual Studio 11ベータと、今後を見据えた非同期処理で取るべき戦略はますます多彩になってきました。Task, Rxのpros, consを考えつつ、主にRxでの非同期処理について紹介します。
ReactiveProperty
-
-
- Rxスタイルのバンディング補助ライブラリ
-
- 非同期処理とは何か?
- 非同期って?
- Parallel
- 並列:1つの処理をばらして同時実行して高速化
- Concurrent
- 並行:個別な処理が相互作用したりしなかったり
- Asynchronous
- 非同期:ブロックしない処理
- UIスレッドを止めなかったり、IO処理効率化だったり
- thread, taskを使っても勿論良い
-
- <実演Demo>
- 非同期サンプルプログラム Web
- 非同期サンプルプログラム silverlight
- 例外処理
- 例)404を返す、例外処理を追記
- 各所に例外処理を書かないと行けないので面倒ではある
- try/catch文なども書かなきゃ行けないので大変
- <実演Demo>
-
-
- TAPとは
- Task Based Asynchronous Pattern
- UIスレッド用スケジューラを用意する事で個別BeginInvoke不要
- TAPとは
-
-
- どれを選択するべきか
- Silverlight4ならばRx一択
- Silverlight5ではVS11を見据えて基本的なラップはTaskのFromAsyncで行う
- WinRTや.NET4.5WPFではasync/awaitで
- どれを選択するべきか
-
- 非同期ストリーム処理
- Reactive Extentions
- TPL Dataflow
- 非同期ストリーム処理
-
- まとめ
- C# 5.0は素晴らしい
- Rxの立ち位置は、非同期処理では若干難しくなってきている
- 将来的にはシンプルなケースでは完全不要でしょう
- ではRxに価値はないかというとそんな事は無くて、幾つかの場面では使える
- (なにより、現時点での唯一の解)
- まとめ
セッション2 UIパターンの捉え方
- 講師:尾上雅則さん (TwitterID:@ugaya40)
UIパターンの解釈の仕方と、ストレートに捉えて設計すると大規模プロジェクトを壊してしまいがちなそのプラットフォームのサンプルの捉え方、サンプルとパターンの概要を応用した設計の仕方を説明します。 パターンの概要だけでは自分で設計出来ないと思う方ぜひ来てください!
- 自己紹介
- 主にMVC/MVP/MVVMパターンに携わる
- C#er/MVVMer
- サイト:the sea of fertility
- 0.設計パターンを学ぶ意義 〜そもそもなぜ設計パターンを学ぶのか〜
- UIパターンに限らず、設計パターンはシステム構築の上での特定の目的に対する先人達による設計のベストプラクティスの事を指す。
- 設計パターンは本来特別まなばなければ到達出来ないものではなく、習熟者が開発者の多くがいずれ到達するパターンである。
- しかし別途学ぶ事には大きな意義がある。
- (※尾上さんによる実体験紹介)
- 設計パターンはシステムを構成してくれる
- プラットフォームに精通していなければ分からない制約にパターンを学ぶ事ではまりにくくなる。
-
- 設計パターンとは
- 特定の目的を実現する為の先人達のベストプラクティス
- 様々なパターンがある
- 意義
- コミュニケーションの促進
- 精通していない人達のための武器となる
- 設計パターンとは
- 1.UIパターンとは?
- いろいろな呼び名があるが、本セッションではUTパターンという言葉で進める。
- GUI Architecrures
- UIパターン
- 開発者が知っておくべき、6つのUIアーキテクチャパターン
- いろいろな呼び名があるが、本セッションではUTパターンという言葉で進める。
-
- メリット
- 分離することによる理解のし易さ
- テストしにくいUIを分離指定テスト容易部分を増やす
- 共有出来るドメイン(問題領域)が出来る
- プレゼン部分はそのPFの知識が本来別に必要
- 分離することによる理解のし易さ
- メリット
-
- UIパターンはGUIプラットフォームを使用して最大限機能を引き出し、最も効率良く開発を行えるようにする為のパターンとも言える。
- つまり・業務要件によって採用・不採用が大きく左右されるようなものではない。(プラットフォーム選択は要件次第)
- UIパターンの紹介
- 原MVC
- Android MVC
- Passive MVP
- 原MVVM
- MVVM 2011
- 現在はWPF4/Silverlight/Metro共通
- ※SLではネットワークアクセスなどのAPIが非同期のものしか用意されていない!
- ViewModelはModelのメソッドを同期的に呼び出す。Model内部で非同期処理
- 非同期をモデルに集約
- 現在はWPF4/Silverlight/Metro共通
-
- 混乱されたのでは?(実際これが混乱の原因)
- UIパターンは実装中立?
- Noであり、Yes。誰かが用意した途端、それは実装中立と言えるようになる。
- 2.UIパターンとプラットフォーム
- UIパターンとそのプラットフォームは、相互に破壊しあい、相互に成長していく関係にある。
- プラットフォームが生まれるとき
- 用途・設計をある程度想定して実装
- プラットフォームの進化
- 利用者などからプラットフォームへのフィードバックが蓄積される。
- より元のパターンにスマートに沿いたい
- 特定の定型処理(DB CRUDなど)の簡略化
- 不満を元にプラットフォームが進化
- UIパターンはPFの威力を最大限に生かすために変化を迫られ、多くの場合微妙に変化
- 時系列によってパターンが進化してくる
- ViewModelの責務が変わってくる。
- 元々の概念から、PF毎にパターンが自由に変化していく事も表す。
- 3.サンプルコードの捉え方
- サンプルコードの種類
- 小規模サンプル
- 大規模サンプル
- マーケティング重視サンプル
- ※それぞれ各責務の担当が異なることや、全く異なる実装要素が使用される事も少なくない。
- サンプルコードの種類
-
- サンプルコードが違いすぎる理由
- そもそも、『実装で苦しまないため』にある。
- 要件とそのPFの設計パターンが合わさって、ようやく1つの設計としてアウトプットされなければならない。
-
- [小規模]
- スパゲッティコードにならないための責務分割の、ただ冗長な部分が目立ちがち。
- <メリット>
- 各責務の役目がとらえやすい
- <デメリット>
- 適用する意味が殆ど分からない規模なので、誰得感
- この通り実装したら辛いだけ
- [小規模]
-
- [小規模]※適切に(つまり楽に)設計されている場合
- <メリット>
- 適切。設計や実装要素のメリットを感じ取りやすい
- <デメリット>
- パターンの責務が読み取りにくい
- シナリオに左右されやすい定型処理な機能が使われやすい
- 大規模に適用すると、デメリットがそのまま強く出て、結果的に意味のないコードになりがち。
- [小規模]※適切に(つまり楽に)設計されている場合
-
- [大規模]
- <メリット>
- 責務を認識やすいし、責務分割によってスパゲッティを回避出来たメリットを感じやすい。
- <デメリット>
- (初学者が)読むのが辛い。ただ辛い。
- <メリット>
- [大規模]
-
- 結果、どのさんぷるも学習には適さない。最初から概念を学んでからサンプルコードを学んだ方が近道。
- 設計パターンはあくまでも設計のための1インプットにすぎない。要件と合わせて適切な設計をそこからアウトプットする。
- 4.UIパターンの適用
- 1.概念の調査・理解
- UIパターンの適応結果=つまりアウトプットされた設計が『プレゼンテーションとドメインの分離」になっていなければ意味が無い。
- 各責務は何の役割を背負い、責務同士がどう関連しているのかを把握する事
- 2.サンプルコードの理解・解釈
- 実装要素の把握
- 『その実装要素を使用しているから○○パターンである』などという誤った理解をしない事
- 3.実装要素の取捨選択
- 責務が自身の役割を果たすのに必須となる実装要素を特定するフェーズ
- 4.設計のアウトプット
- 1.概念の調査・理解
- 5.注意点
- 責務分けに悩んだ時はどうするか?
- Mから考えると悩む。
- つまるところ、Modelとはアプリのうちの『View』と『中間層』以外の部分ということ。
- Viewに近いところから考える
- UIアンチパターン
- 3層もどき
- クラサバ
- 6.まとめ
- 2つの観点からチェック。
- プレゼンテーションとドメインの分離は出来ているか?
- 『特定の実装要素』にこだわりすぎていないか?
- 2つの観点からチェック。
セッション3 集中と分散 〜 スマートフォンとクラウド連携のアプリ開発と分業の実際
- 講師
- カブドットコム証券株式会社 社長付 IT戦略担当 谷口 有近様
- 株式会社セカンドファクトリー 東海 連様、高尾 哲朗様
スマートフォン×クラウドにおけるUXの必要性と、クラウド連携におけるマルチデバイス前提のアプリケーション設計に必要な考え方について、金融系アプリケーション開発の実例紹介を踏まえて、ご提示致します。
すいません、このセッションに関しては冒頭発表された方の喋るスピードがあまりにも速く、またスライドの内容もかな〜〜り情報過多な感じでしたので正直メモを取る気持ちが萎えました(笑)
セッション4 MVPVMパターン
- 講師:児玉宏之さん (TwitterID:@mnow)
MSDN マガジン2011年12月号で発表された「MVPVM 設計パターン」ですが、私もViewとViewModelの両方を知っていて現状の画面状態を管理する何者かが必要なことは感じていました。 Applicationの派生クラスやApplicationが操作するオブジェクトとして現状の画面状態を管理やナビゲーションをする機能をつくっていました。今回のセッションでは私なりに研究した「MVPVM 設計パターン」をお届けします。
- 自己紹介
- C# MVP 8年目
- MSDNマガジン 2011/12月号『MVPVM設計パターン』
- 発表者なりに研究した『MVPVM設計パターン』をお届け。
- モデル・ビュー・プレゼンターモデル(MVPVM)パターンは、Microsoft Petterns PrackticesのPrismプロジェクトで導入された。
- MVVMの能力と機能を全て利用出来、MVPの拡張性からプレゼンテーションロジックの複雑さにも対応。
- ViewModelは本来あるべきプロパティ公開とコマンドの受付になる。
- MVPVMパターン
- MVVMパターン+MVPパターンを合体させたもの。
-
- MVVMパターン
- View:UIの概観や配置、反応を定義
- VIewModel:Viewの...(※メモ失念)
- Model:データの取得や管理を行い、プログラムの管理の中核
- MVVMパターン
-
- MVPパターン
- View:UIの概観や配置、反応を定義
- Presenter:Viewのナビゲーションを管理し、ユーザ入力をModelに伝える
- Model:データの取得や管理を行い、プログラムの管理の中核
- MVPパターン
-
- MVPVMパターン
- View:UIの概観や配置、反応を定義
- ViewModel:Zviewの必要な情報をプロパティで公開しユーザ入力やコマンドをPresenterに渡す
- Presenter:Viewのナビゲーションを管理し、ユーザ入力をModelに伝える
- Model:データの取得や管理を行い、プログラムの管理の中核
- MVPVMパターン
-
- ナビゲーション
- MVVMパターンではどこがナビゲーションを担当していたのか?
- →メッセージ+ビヘイビア。
- ビヘイビアはViewの分類になる。
- 操作:メッセージを送ってメッセージボックスやダイアログを表示する事も多かった。
- (メッセージボックス:コード実装例解説)
- (ダイアログ:コード実装例解説)
-
- ナビゲーション
- MVVMパターンでは他にどこがナビゲーションを担当していたのでしょうか。
- →ViewModel+DataTemplate。
- さらに、DataTemplateをデータによって切り替えるDataTemplateSelectorというのもある。
- DataTemplateはViewの分類になる。
- DataTemplateSelector:コード実装例
- MVVMパターンでは他にどこがナビゲーションを担当していたのでしょうか。
- ナビゲーション
-
- プレゼンターの構成
- Presenterはパネルなどのコンテナで複数のPresenterを管理するものと、ユーザーコントロールやダイアログなどの単一ビューを管理するものがある。
- ViewやViewModelが階層構造になっているように、Presenterも階層構造になる。
- プレゼンターの構成
-
- プレゼンターの利点
- ApplicationやViewModelからプレゼンテーションロジックを解放。
- ViewとViewModelは疎結合でお互いに交換可能な状態に戻すことにより、再利用性を高め
- ViewやViewModelをライブラリ化しやすくなる。
- ViewとViewModelとModel全てにアクセス可能な存在なので、アンドゥ・リドゥの実装場所に最適。
- ViewModelからViewをクローズするメッセージは必要無くなる。
- プレゼンターの利点
-
- 親が子供を管理
- ダイアログを表示させたいPresenterはダイアログを管理するPresenterを生成して、
- ダイアログが閉じたら解放する。
- パネルなどのコンテナを管理する
- 親が子供を管理
-
- プレゼンター:
- コンテナ内をスライドして入れ替わる
- プレゼンター:
- まとめ
- MVPVMパターンはMVVMの能力と機能を全て利用出来、MVPの拡張性からプレゼンテーションロジックの複雑さにも対応可能。
- MVPVMパターンはViewとModelは疎結合でお互いに交換可能な状態に戻すのに有効な手段である。
以上、ざっくりとではありますがレポートでした。今回はどのセッションも資料的には情報満載で後で見返して見たいものばかりだったのですが、その情報量のために若干駆け足気味になってしまい、1つ1つのテーマをゆっくり理解する暇が無かったかも、というのが個人的な感想でした。資料が公開されたらそれぞれゆっくり読み解き、理解を深めて行きたいと思います。
その他関連: