RIA アーキテクチャー研究会 第3回 セミナーに参加してきた #riaarch

RIAというキーワードと、技術的側面に興味があったで見つけ次第即参加申込して行ってきました。

会場はマイクロソフト本社@品川。最近ココに来る機械も多いですね。とは言え日中昼間は始めてかも。

早速参加メモ。(この日は勉強会ハシゴ参戦してきたので1日で2エントリ分収めないと、なのです(^^;))

セッション1 C#次世代非同期処理概説 Task vs Reactive Extensions

Silverlight 5でのTaskの搭載、Visual Studio 11ベータと、今後を見据えた非同期処理で取るべき戦略はますます多彩になってきました。Task, Rxのpros, consを考えつつ、主にRxでの非同期処理について紹介します。


ReactiveProperty

      • Rxスタイルのバンディング補助ライブラリ
  • 非同期処理とは何か?
    • 非同期って?
    • Parallel
      • 並列:1つの処理をばらして同時実行して高速化
    • Concurrent
      • 並行:個別な処理が相互作用したりしなかったり
    • Asynchronous
      • 非同期:ブロックしない処理
      • UIスレッドを止めなかったり、IO処理効率化だったり
      • thread, taskを使っても勿論良い
    • 非同期はなぜ重要か
      • クラウド並のバスワード
      • RIA的にはUIスレッドのブロックいくない
      • ユーザーエクスペリエンス的には当然だろjk
        • Windows phone Win8には最初から非同期メソッドしか用意されていない、同期処理不可!
        • jsなんて最初からそれonlyだし
      • Web的には同時接続対策
        • C10K問題
        • node.jsの流行にC#では5.0で対応
    • <実演Demo>
      • 非同期サンプルプログラム Web
      • 非同期サンプルプログラム silverlight
      • 例外処理
        • 例)404を返す、例外処理を追記
        • 各所に例外処理を書かないと行けないので面倒ではある
        • try/catch文なども書かなきゃ行けないので大変
    • 非同期処理の憂鬱(Asynchronous blues)
      • ネスト宇宙ヤバイ
        • 単発ならそれ程でもないが・・・
      • 例外処理不能
        • というかもう無理。
    • 非同期処理のパターン
      • APMとは
        • Asynchronous Programming Modelの略
        • XXXとYYYによる(※詳細失念)ペアによる非同期処理
      • とにかく面倒臭い
      • 正しく使うのは慣れが必要
      • EAPとは
        • Event-Based Asynchronous Pattern
        • 素の状態のC#では割と楽な書き方
        • リクエストの発行が後になるという順序の問題を抱える
        • 後述するTaskやRxの登場で消えつつある
      • TAPとは
        • Task Based Asynchronous Pattern
      • UIスレッド用スケジューラを用意する事で個別BeginInvoke不要
      • Rxとは
        • Reactive Extentions
        • LINQ1ベースのイベント・非同期処理ライブラリ
        • @ITで連載やってます。
        • LINQベースのため合成処理が異常な程強力
        • 非同期処理だけでなく、あらゆる処理に使える
    • Future
      • C# 5.0/Visual Studio11
        • ContinueWithが言語サポート
        • それに加えて標準クラスライブラリにもラップ済み非同期処理関連メソッドが大量追加
      • Rx is awaitable
        • Task vs Rxなら Rxの方が使いやすい
        • ただしC# 5.0ではTaskが圧倒的に使いやすい
        • じゃあ将来を見据えてTaskで作った方が・・・?
      • Task Is Observbable
        • TaskのメソッドはToObserveableでRxに変更可能
      • FromAsyncPattern
        • Rxはawait可能である事、C#5.0でTaskベースの非同期処理が
    • どれを選択するべきか
      • Silverlight4ならばRx一択
      • Silverlight5ではVS11を見据えて基本的なラップはTaskのFromAsyncで行う
      • WinRTや.NET4.5WPFではasync/awaitで
    • 非同期ストリーム処理
      • Reactive Extentions
      • TPL Dataflow
    • まとめ
      • C# 5.0は素晴らしい
      • Rxの立ち位置は、非同期処理では若干難しくなってきている
        • 将来的にはシンプルなケースでは完全不要でしょう
        • ではRxに価値はないかというとそんな事は無くて、幾つかの場面では使える
        • (なにより、現時点での唯一の解)

セッション2 UIパターンの捉え方

UIパターンの解釈の仕方と、ストレートに捉えて設計すると大規模プロジェクトを壊してしまいがちなそのプラットフォームのサンプルの捉え方、サンプルとパターンの概要を応用した設計の仕方を説明します。
パターンの概要だけでは自分で設計出来ないと思う方ぜひ来てください!


  • 0.設計パターンを学ぶ意義 〜そもそもなぜ設計パターンを学ぶのか〜
    • UIパターンに限らず、設計パターンはシステム構築の上での特定の目的に対する先人達による設計のベストプラクティスの事を指す。
    • 設計パターンは本来特別まなばなければ到達出来ないものではなく、習熟者が開発者の多くがいずれ到達するパターンである。
      • しかし別途学ぶ事には大きな意義がある。
      • (※尾上さんによる実体験紹介)
      • 設計パターンはシステムを構成してくれる
      • プラットフォームに精通していなければ分からない制約にパターンを学ぶ事ではまりにくくなる。
    • 設計パターンとは
      • 特定の目的を実現する為の先人達のベストプラクティス
      • 様々なパターンがある
    • 意義
      • コミュニケーションの促進
      • 精通していない人達のための武器となる
  • 1.UIパターンとは?
    • いろいろな呼び名があるが、本セッションではUTパターンという言葉で進める。
    • MVC/MVP.MVVM・・・全てGUI周りの責務分割のパターン。
    • 基本的な目的はプレゼンテーション(表示)とドメイン(問題領域)の分離。
    • プレゼンテーションとドメインの分離(ファウラーの翻訳)参照。
    • メリット
      • 分離することによる理解のし易さ
        • テストしにくいUIを分離指定テスト容易部分を増やす
      • 共有出来るドメイン(問題領域)が出来る
        • プレゼン部分はそのPFの知識が本来別に必要
    • AndroidのActivityやWPF/SilverlightXAML(DSL)など、それぞれJava言語・C#/.NET言語などの汎用言語の知識だけではGUIは作成出来ない。
    • プレゼンテーションの作成はプレゼンテーションプラットフォームの固有知識を必要とすることの裏返しとも言える。
    • プレゼントドメインの実装に必要な知識は別。
      • なら別にパターンとか考えなくても良いのでは?
      • これ自体が一つのパターンだと言う事はさておき・・・
      • 想定された用途と設計に沿うために、UIパターンに則って設計・実装することが重要に。
      • そして、PFが乱立している事がMVC系パターンが乱立している原因でもある。
    • UIパターンはGUIプラットフォームを使用して最大限機能を引き出し、最も効率良く開発を行えるようにする為のパターンとも言える。
    • つまり・業務要件によって採用・不採用が大きく左右されるようなものではない。(プラットフォーム選択は要件次第)
  • UIパターンの紹介
    • MVC
    • Android MVC
    • Passive MVP
    • 原MVVM
    • MVVM 2011
      • 現在はWPF4/Silverlight/Metro共通
        • ※SLではネットワークアクセスなどのAPIが非同期のものしか用意されていない!
      • ViewModelはModelのメソッドを同期的に呼び出す。Model内部で非同期処理
      • 非同期をモデルに集約
    • 混乱されたのでは?(実際これが混乱の原因)
    • UIパターンは実装中立?
      • Noであり、Yes。誰かが用意した途端、それは実装中立と言えるようになる。
    • 1章まとめ
      • UIパターンはGUIアプリケーションの責務分割のためのパターンであり、プレゼンとドメインの分離を目的とする。
      • UIパターンに則る事で一般的に思いつくメリットの他に、致命的な設計ミスを防ぎやすい事が挙げられる。
      • UIパターンは本来実装中立ではないが、実装中立にする事も出来る。
  • 2.UIパターンとプラットフォーム
    • UIパターンとそのプラットフォームは、相互に破壊しあい、相互に成長していく関係にある。
    • プラットフォームが生まれるとき
      • 用途・設計をある程度想定して実装
      • プラットフォームの進化
      • 利用者などからプラットフォームへのフィードバックが蓄積される。
        • より元のパターンにスマートに沿いたい
        • 特定の定型処理(DB CRUDなど)の簡略化
    • 不満を元にプラットフォームが進化
    • UIパターンはPFの威力を最大限に生かすために変化を迫られ、多くの場合微妙に変化
    • 時系列によってパターンが進化してくる
    • ViewModelの責務が変わってくる。
    • 元々の概念から、PF毎にパターンが自由に変化していく事も表す。
  • 3.サンプルコードの捉え方
    • サンプルコードの種類
    • ※それぞれ各責務の担当が異なることや、全く異なる実装要素が使用される事も少なくない。
    • サンプルコードが違いすぎる理由
    • そもそも、『実装で苦しまないため』にある。
    • 要件とそのPFの設計パターンが合わさって、ようやく1つの設計としてアウトプットされなければならない。
    • [小規模]
      • スパゲッティコードにならないための責務分割の、ただ冗長な部分が目立ちがち。
      • <メリット>
        • 各責務の役目がとらえやすい
      • <デメリット>
        • 適用する意味が殆ど分からない規模なので、誰得感
        • この通り実装したら辛いだけ
    • [小規模]※適切に(つまり楽に)設計されている場合
      • <メリット>
    • 適切。設計や実装要素のメリットを感じ取りやすい
      • <デメリット>
      • パターンの責務が読み取りにくい
      • シナリオに左右されやすい定型処理な機能が使われやすい
      • 大規模に適用すると、デメリットがそのまま強く出て、結果的に意味のないコードになりがち。
    • [大規模]
      • <メリット>
        • 責務を認識やすいし、責務分割によってスパゲッティを回避出来たメリットを感じやすい。
      • <デメリット>
        • (初学者が)読むのが辛い。ただ辛い。
    • [マーケティング重視のサンプル]
      • <メリット>
        • 新機能や抽象度の高いAPIについて知りたいなら悪くない。
      • <デメリット>
        • 抽象度の高い機能ほど、威力を発揮するシナリオが限られる。
      • ※パターンや設計のお手本にするのは正直オススメ出来ない。
    • 結果、どのさんぷるも学習には適さない。最初から概念を学んでからサンプルコードを学んだ方が近道。
    • 設計パターンはあくまでも設計のための1インプットにすぎない。要件と合わせて適切な設計をそこからアウトプットする。
  • 4.UIパターンの適用
    • 1.概念の調査・理解
      • UIパターンの適応結果=つまりアウトプットされた設計が『プレゼンテーションとドメインの分離」になっていなければ意味が無い。
      • 各責務は何の役割を背負い、責務同士がどう関連しているのかを把握する事
    • 2.サンプルコードの理解・解釈
      • 実装要素の把握
      • 『その実装要素を使用しているから○○パターンである』などという誤った理解をしない事
    • 3.実装要素の取捨選択
      • 責務が自身の役割を果たすのに必須となる実装要素を特定するフェーズ
    • 4.設計のアウトプット
  • 5.注意点
    • 責務分けに悩んだ時はどうするか?
    • Mから考えると悩む。
      • つまるところ、Modelとはアプリのうちの『View』と『中間層』以外の部分ということ。
    • Viewに近いところから考える
    • UIアンチパターン
      • 3層もどき
      • クラサバ
  • 6.まとめ
    • 2つの観点からチェック。
      • プレゼンテーションとドメインの分離は出来ているか?
      • 『特定の実装要素』にこだわりすぎていないか?

セッション3 集中と分散 〜 スマートフォンクラウド連携のアプリ開発と分業の実際

  • 講師
    • カブドットコム証券株式会社 社長付 IT戦略担当 谷口 有近様
    • 株式会社セカンドファクトリー 東海 連様、高尾 哲朗様
スマートフォン×クラウドにおけるUXの必要性と、クラウド連携におけるマルチデバイス前提のアプリケーション設計に必要な考え方について、金融系アプリケーション開発の実例紹介を踏まえて、ご提示致します。

すいません、このセッションに関しては冒頭発表された方の喋るスピードがあまりにも速く、またスライドの内容もかな〜〜り情報過多な感じでしたので正直メモを取る気持ちが萎えました(笑)

後日、可能な形でスライドが公開されるとの事なので、詳細はそちらの方を御覧下さい。(写真で雰囲気だけでも...)


セッション4 MVPVMパターン

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パターン
      • View:UIの概観や配置、反応を定義
      • VIewModel:Viewの...(※メモ失念)
      • Model:データの取得や管理を行い、プログラムの管理の中核

    • MVPパターン
      • View:UIの概観や配置、反応を定義
      • Presenter:Viewのナビゲーションを管理し、ユーザ入力をModelに伝える
      • Model:データの取得や管理を行い、プログラムの管理の中核

    • MVPVMパターン
      • View:UIの概観や配置、反応を定義
      • ViewModel:Zviewの必要な情報をプロパティで公開しユーザ入力やコマンドをPresenterに渡す
      • Presenter:Viewのナビゲーションを管理し、ユーザ入力をModelに伝える
      • Model:データの取得や管理を行い、プログラムの管理の中核
    • ナビゲーション
    • MVVMパターンではどこがナビゲーションを担当していたのか?
      • →メッセージ+ビヘイビア。
      • ビヘイビアはViewの分類になる。
      • 操作:メッセージを送ってメッセージボックスやダイアログを表示する事も多かった。
    • (メッセージボックス:コード実装例解説)
    • (ダイアログ:コード実装例解説)
    • ナビゲーション
      • MVVMパターンでは他にどこがナビゲーションを担当していたのでしょうか。
        • →ViewModel+DataTemplate。
        • さらに、DataTemplateをデータによって切り替えるDataTemplateSelectorというのもある。
        • DataTemplateはViewの分類になる。
      • DataTemplateSelector:コード実装例

      • MVVMパターンは、ViewとVIewModelは疎結合でお互いに交換可能であるという事が利点の1つであると言われてきた。
      • しかし密結合多し。どうして?
      • ナビゲーションとはViewとViewModelの両方を知らないと出来ない。
      • この場合、Viewに仕込んでいるので、ViewModelや本来ViewModelにあるべきデータがViewに出来てしまう。

      • MVVMパターンではViewだけがナビゲーションを担当していたのか?
        • →アプリケーションクラスが担当。
        • アプリケーションクラスはMVVMパターンの範囲外。
        • 範囲外であれば別に問題無い?
        • →ナビゲーションを担当するPresenterがあれば、アプリケーションクラスはすっきりするはず。
        • アプリケーションクラス:コード実装例
    • プレゼンターの役割
      • ViewとViewModelのインスタンス生成を行う。
      • Viewをパネルなどのコンテナに追加し、DataContextにViewModelをセット。
      • Modelに表示すべきデータを要求し、ViewModelにセット。
      • 上位のPresenterやViewModelの依頼により更新すべきデータを収集し、Modelを更新。
      • ViewとViewModelのインスタンス解放。

    • プレゼンターの構成
      • 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つのテーマをゆっくり理解する暇が無かったかも、というのが個人的な感想でした。資料が公開されたらそれぞれゆっくり読み解き、理解を深めて行きたいと思います。



その他関連: