RIAアーキテクチャ研究会 第3回セミナー 尾上 雅則 UIパターンの捉え方 RIAアーキテクチャ研究会 第3回セミナー 尾上 雅則

自己紹介 尾上 雅則 (おのうえ まさのり) 28歳(昭和58年世代) C#er/MVVMer WPF/Silverlight/Windows Phone/Windows Forms/ASP.NETなど Blog - the sea of fertility http://ugaya40.net Twitter - @ugaya40 Facebook – http://facebook.com/ugaya40

Agenda 0. 設計パターンを学ぶ意義 UIパターンとは？ UIパターンとプラットフォーム サンプルコードの捉え方 UIパターンの適用 0. 設計パターンを学ぶ意義 UIパターンとは？ UIパターンとプラットフォーム サンプルコードの捉え方 UIパターンの適用 注意点 まとめ

0. 設計パターンを学ぶ意義 そもそもなぜ設計パターンを学ぶのか

0-1.設計パターンとは？ UIパターンに限らず設計パターンとは システム構築の上での特定の目的に対する 先人達による設計のベストプラクティス の事を指します。 GoFデザインパターン レイヤパターン ドメインロジックパターン サーバ冗長化パターン UIパターン

通信インスタンス取得のためのAdapterだよ 0-2.設計パターンを学ぶ意義 設計パターンは本来特別学ばなければ到達できないものではなく、習熟した開発者の多くがいずれ到達するパターンです。しかし別途学ぶ事には大きな意義があります。 このクラス何？ 通信インスタンス取得のためのAdapterだよ あ、なるほど 意義１：コミュニケーションの促進

0-2.設計パターンを学ぶ意義 設計パターンは本来特別学ばなければ到達できないものではなく、習熟した開発者の多くがいずれ到達するパターンです。しかし別途学ぶ事には大きな意義があります。 このAPIやばい、 SQL手書きしなくていいじゃん！ 全部これ使えば幸せになれるんじゃない？ よし、これで行こう！ 初学者’s

0-2.設計パターンを学ぶ意義 実装中・・・・・・ 設計パターンは本来特別学ばなければ到達できないものではなく、習熟した開発者の多くがいずれ到達するパターンです。しかし別途学ぶ事には大きな意義があります。 このAPIやばい、 SQL手書きしなくていいじゃん！ 実装中・・・・・・ 全部これ使えば幸せになれるんじゃない？ よし、これで行こう！ 初学者’s

複数処理にまたがるトランザクション張れない？ 0-2.設計パターンを学ぶ意義 設計パターンは本来特別学ばなければ到達できないものではなく、習熟した開発者の多くがいずれ到達するパターンです。しかし別途学ぶ事には大きな意義があります。 もしかして・・・・これ使ってると 複数処理にまたがるトランザクション張れない？ うん、そうみたい・・・ まさか全部・・やりなお(ry？ ・・・・・・それしかないみたい。 初学者’s

0-2.設計パターンを学ぶ意義 想定された用途・強力に機能する場面 設計パターンは本来特別学ばなければ到達できないものではなく、習熟した開発者の多くがいずれ到達するパターンです。しかし別途学ぶ事には大きな意義があります。 こんな事にならないために・・・・・(実話) 設計パターンは、システムを構成してくれる要素(機能)の 想定された用途・強力に機能する場面 を教えてくれます。 もしかして・・・・これ使ってると 複数処理にまたがるトランザクション張れない？ うん、そうみたい・・・ まさか全部・・やりなお(ry？ ・・・・・・それしかないみたい。 初学者’s

0-2.設計パターンを学ぶ意義 意義２：初学者に優しい学習パス 設計パターンは本来特別学ばなければ到達できないものではなく、習熟した開発者の多くがいずれ到達するパターンです。しかし別途学ぶ事には大きな意義があります。 オブジェクト指向言語 ー オブジェクト指向 Android ー MVC/MVP XAML系テクノロジ(WPF/Silverlightなど) ー MVVM マルチスレッドシングルトン ー Double Checked Locking .NETアプリケーション ー pattern & practice プラットフォームに精通していなければわからない制約に パターンを学ぶ事ではまりにくくなります。 意義２：初学者に優しい学習パス

0.設計パターンを学ぶ意義 - まとめ 設計パターンとは？ 特定の目的を実現するための、先人たちのベストプラクティス コードレベルにとどまらない、さまざまなパターンがある 設計パターンを学ぶ意義 コミュケーションの促進 それに精通してない人がプラットフォームを使いこなすための武器

1. UIパターンとは？ UIパターンとは何で、何の目的で、いつ必要で、どこまでの話なのか？

1-0.UIパターンの呼び方 GUI Architectures UIパターン いろいろな呼び方がありますが、 Martin Fowler http://martinfowler.com/eaaDev/uiArchs.html UIパターン Matarillo.com http://matarillo.com/general/uipatterns.php 開発者が知っておくべき、6つのUIアーキテクチャ・パターン @IT http://www.atmarkit.co.jp/fdotnet/chushin/greatblogentry_10/greatblogentry_10_01.html いろいろな呼び方がありますが、 本セッションではGUIアプリケーションの設計パターンを「UIパターン」という言葉を採用し、特にMVC系について説明いたします。

1-1.UIパターンとは？ MVC/MVP/MVVM・・・など数多くありますが、すべてGUI周りの責務分割のパターンです。 基本的な目的はプレゼンテーション(表示)とドメイン(問題領域)の分離です。 PresentationDomainSeparation Martin Fowler http://martinfowler.com/bliki/PresentationDomainSeparation.html (和訳) プレゼンテーションとドメインの分離 Martin Fowler‘s Bliki in Japan http://martinfowler.com/bliki/PresentationDomainSeparation.html

1-2.プレゼンテーションとドメインの分離 MVC/MVP/MVVM・・・など数多くありますが、すべてGUI周りの責務分割のパターンです。 基本的な目的はプレゼンテーション(表示)とドメイン(問題領域)の分離です。 分離することによる理解のしやすさ テストしにくいUIを分離してテスト容易部分を増やす 複数のプレゼンテーションで共有できるドメインができる プレゼン部分はそのプラットフォームの知識が本来別に必要である プレゼンプラットフォームの仕様・変更にドメインが引きずられない 下二つを詳しく見てみましょう。

プレゼンとドメインの実装に必要な知識は別 1-2.プレゼンテーションとドメインの分離 プレゼンテーション Android XAML ASP.NET MVC Ruby on Rails ・・・etc ドメイン 各種汎用言語による実装 (C#/Java/関数型等) WPF/SilverlightのXAML(DSL)など、C#/VB.NET言語などの汎用言語の知識だけではGUIは作成できません。 「ドメインを複数のViewが共有可能」というメリットが活きる場面はそんなに多くないと思いますが、これはプレゼンテーションの作成はプレゼンテーションプラットフォームの固有知識を必要とすることの裏返しと言えます。 プレゼンとドメインの実装に必要な知識は別

なら別にパターンとか考えなくてもこれだけでいいんじゃないの？ 1-2.プレゼンテーションとドメインの分離 プレゼンテーション ドメイン なら別にパターンとか考えなくてもこれだけでいいんじゃないの？ まず「プレゼンテーションとドメインの分離」自体が一つのパターンだという事はさておき・・・

1-2.プレゼンテーションとドメインの分離 プレゼンテーション ドメイン ドメインなコード 便利 UIコントロール こうすると・・・

1-2.プレゼンテーションとドメインの分離 ドメイン ドメインなコード 便利 UIコントロール 想定と違って、 コントロールが画面表示に必須な状態を 保持していなかった！

1-2.プレゼンテーションとドメインの分離 こんな事になってしまいがちです。 プレゼンテーション層のプラットフォームは、 特定の用途と設計を意図して作られている事がほとんどです。 その「想定された用途と設計」に沿うために、 UIパターンに則って設計・実装する事が重要になります。 そしてプラットフォームが乱立していることが MVC系パターンが乱立している原因でもあります。 こうしたいけど大分作っちゃったので 今さらこう変更はできない・・・ プレゼンテーション 状態保持 ドメイン 定かならぬ領域へ・・・

1-3.UIパターンのコンテキスト あるプラットフォームは、ある用途と設計を踏まえて作られている事を思い出しましょう。 UIパターンは「GUIプラットフォームを使用して最大限機能を引き出し、もっとも効率よく開発を行えるようにするためのパターン」だと言えます。 つまり業務要件によって採用・不採用が大きく左右されるようなものではありません。(プラットフォーム選択は要件次第)

1-4.UIパターンの紹介 – 原MVC プレゼンテーション プレゼンテーション ④監視 ドメイン ⑤更新 ②入力を通知 ③ビジネスロジック Controller プレゼンテーション ②入力を通知 ③ビジネスロジック 呼出 ①入力 View プレゼンテーション Model ④監視 ドメイン ⑤更新

1-4.UIパターンの紹介 – Android MVC Controller プレゼンテーション ②入力を通知 ①入力 ③ドメインロジック 呼出 View ⑤変更依頼 Or 変更 ④結果 Model プレゼンテーション ⑥変更(⑤が変更依頼な時のみ) ドメイン

1-4.UIパターンの紹介 – 原MVP プレゼンテーション ④変更する (IF経由) プレゼンテーション ⑤監視 ドメイン Presenter プレゼンテーション ②入力を通知 ③ビジネスロジック 呼出 ①入力 View ④変更する (IF経由) Model プレゼンテーション ⑤監視 ドメイン ⑥Modelの変化を受け更新

1-4.UIパターンの紹介 – Passive MVP Presenter プレゼンテーション ②入力を通知 ③ビジネスロジック 呼出 ①入力 View ④Viewの変更 Model プレゼンテーション ドメイン

1-4.UIパターンの紹介 – 原MVVM プレゼンテーション プレゼンテーション ドメイン 依存 View ViewModel Data Binding イベント

1-4.UIパターンの紹介 – WPF 3.5 MVVM GUIが時間のかかる処理でブロックされないために ViewModelが非同期でModelのメソッドを呼び出す 依存 View ViewModel Model Data Binding イベント

1-4.UIパターンの紹介 – MVVM 2011 現在はWPF4/Silverlight(WindowsPhone)/Metro共通 依存 さらにWinRTでも非同期でしか提供されないAPI多数！ SilverightではネットワークアクセスなどのAPIが非同期のものしか用意されていない。 依存 View ViewModel Model 言語レベル非同期サポートも追加される！ Data Binding WPFでも.NET本体に強力な非同期サポートが追加された イベント ViewModelはModelのメソッドを同期的に呼び出す Model内部で非同期処理

1-4.UIパターンの紹介 パターンが、 プラットフォームごとに(Android MVCとか)、 同一プラットフォームでもバージョンごとに(WPF3.5 MVVM) 異なってくるので混乱されたのではないでしょうか？ パターンの本体は概念ですが、実用や議論の単位・プラットフォームごと、あるいはアプリケーションごとに責務関係が異なったり、時系列で変化したりします。その辺については2章と3章で説明します。

1-5.UIパターンは実装中立？ Ruby on RailsのMVCを受け用意されたASP.NET MVC Noであり、Yesです。 思想だけあり、それを実現できるプラットフォームがないUIパターンは夢です。 その思想が実現可能であることを示すにはそういうプラットフォームを用意するしかありません しかし誰かが用意した途端、それは実装中立と言えるようになります。 Ruby on RailsのMVCを受け用意されたASP.NET MVC → ASP.NETの世界にでもMVCが可能に！ XAML系のMVVMを受け用意されたKnockout.js → Javascriptの世界でもMVVMが可能に！

1.UIパターンとは？- まとめ UIパターンは、GUIアプリケーションの責務分割のためのパターン(ベストプラクティス)であり、プレゼンテーション(表示)とドメイン(問題領域)の分離を目的とする。 UIパターンに則ることで一般的にすぐ思いつくメリットの他に、致命的な設計ミスを防ぎやすい事が挙げられる。 UIパターンは本来実装中立ではないものだが、実装中立にすることもできる。その場合、各責務の役割が微妙に異なる事もある。 プラットフォームとUIパターンについては2章で掘り下げます。

2. UIパターンとプラットフォーム その相互作用とライフサイクル

２.相互作用 UIパターンとそのプラットフォームは、相互に破壊しあい、相互に成長していく関係にあります。 破壊的なフィードバック

２.相互作用 ①プラットフォーム誕生 プラットフォームの進化 プラットフォームAPIは、用途・設計を想定されて誕生します。 ２.相互作用 ①プラットフォーム誕生 プラットフォームAPIは、用途・設計を想定されて誕生します。 用途・設計をある程度想定して実装 UIパターン MVC MVVM etc プラットフォーム Ruby on Rails XAML etc プラットフォームの進化

２.相互作用 ②プラットフォームフィードバック ２.相互作用 ②プラットフォームフィードバック 利用者などからプラットフォームへのフィードバックが蓄積されます。 プラットフォーム より元のパターンにスマートに沿いたい 特定の定型処理(DB CRUDなど)の簡略化 プラットフォームのプラットフォームの進化に沿いたい(言語面など) 冗長性を排除したい OSSでないならベンダー戦略からの要求

２.相互作用 ③ プラットフォーム２誕生 プラットフォームの進化 不満を元にプラットフォームの新バージョンが誕生します。 プラットフォーム より元のパターンにスマートに沿いたい フィードバックが反映された プラットフォームバージョン２ 特定の定型処理(DB CRUDなど)の簡略化 プラットフォームのプラットフォームの進化に沿いたい(言語面など) 冗長性を排除したい OSSでないならベンダー戦略からの要求 プラットフォームの進化

２.相互作用 ③ プラットフォームver２誕生 UIパターンが「プラットフォームの威力を最大限引き出すもの」であることを思い出してください プラットフォームが更新

特定プラットフォームでのUIパターンの進化 ２.相互作用 ③ プラットフォームver２誕生 UIパターンは「新しいバージョンのプラットフォームの威力を最大限に活かすため」に変化をせまられ、多くの場合微妙に変化します。 UIパターン UIパターン＋ プラットフォームver２ プラットフォームが更新 特定プラットフォームでのUIパターンの進化

２.相互作用 ③ そして再びプラットフォームへ UIパターンが「プラットフォームの威力を最大限引き出すもの」であることを思い出してください 変化したパターンが再びプラットフォームに影響を与える UIパターン＋ プラットフォームver２ プラットフォームでは、またよりUIパターンに沿うためのフィードバックなどが蓄積されます。 最初に戻る形ですね。

２.相互作用 時系列で異なるUIパターン UIパターンとプラットフォームが相互に影響を与え、相互に成長していくことはまず時系列によってパターンの形が変わってくる事を表します。 破壊的なフィードバック UIパターン プラットフォーム 破壊的なフィードバック

２.相互作用 プラットフォームごとに異なるUIパターン Ruby on Rails MVC Ruby on Rails MVC２ Ruby on Rails MVC２ Android MVC Android MVC２ Android MVC２ 原MVC iOS MVC iOS MVC２ ASP.NET MVC MVC ASP.NET MVC MVC２

２.相互作用 プラットフォームごとに異なるUIパターン 各プラットフォームごとに枝分かれした独自の系が、元の概念と全く異なる事になることも珍しくありません。 しかし当然どんな変化も許される　というわけではありません。 「プレゼンテーションとドメインの分離」 が果たせないように変化しようとしても、 それではそもそもの目的を見失ってしまい使えませんし、 その時はもうMVC系と呼ばれる事はないのです。 そもそも普及しないとは思いますが・・・。 Ruby on Rails MVC Ruby on Rails MVC２ Ruby on Rails MVC２ Android MVC Android MVC２ Android MVC２ 原MVC iOS MVC iOS MVC２ ASP.NET MVC MVC ASP.NET MVC MVC２

２.UIパターンとプラットフォーム- まとめ UIパターンとGUIプラットフォームは、相互に破壊しあい、相互に成長していく。

3. サンプルコードの捉え方 サンプルコードの捉え方

3-1.サンプルコードの種類 「○○パターンの実装」と言われるサンプルコードには大きく分けて３つの種類がある。 小規模サンプル 大規模サンプル マーケティング重視サンプル それぞれ各責務の担当が異なることや、全く異なる実装要素が使用される事も少なくない。

3-2.サンプルコードが違いすぎる理由 UI設計パターンはそもそも 「実装で苦しまないため」 にある。 「実装で苦しまないため」には要件とそのプラットフォームの設計パターンが合わさって、ようやく一つの設計としてアウトプットされなければいけない。 つまり設計パターンは設計のための１インプットにすぎないため、設計パターンだけでは本来コードで語れるものにはならないからです。 純粋な○○パターンのサンプルなんて存在しないのです。 3種類をそれぞれ見ていきます。

3-3.小規模サンプル① – 責務に厳密な場合 小規模なサンプルでは、スパゲティコードにならないための責務分割の、ただ冗長な部分が目立ちがちです。 メリット 各責務の役目がとらえやすい デメリット 正直言ってパターンを適用する意味がほとんどない規模なので、パターンを適用して何がうれしかったのかわからない この通り実装したらつらいだけ。 「なんだこれ、ただ面倒なだけじゃん」って言われがちですね。 こういうサンプルはメリットが読み取りにくく、パターンの学習の初期では微妙です。 無理してる感

3-3.小規模サンプル ② 小規模なサンプルとして適切に(つまり楽に)設計されている場合です。 メリット デメリット 適切。設計や実装要素のメリットを感じ取りやすい デメリット 責務を分割するメリットの無いところでは分割されていない・あるいは境界を曖昧にしてあるのでパターンの責務は読み取りにくい。 ユースケースが限られているのでシナリオに左右されやすい定型処理な機能が使われやすい （例: シンプルな1トランザクションのDB CRUD抽象化機能など） ユースケースの種類が豊富でコード量の多い大規模プロジェクトにこのまま同じような設計を適用すると、上二つのデメリットがそのまま強く出てきて、結果的にパターンを適用した意味のないようなコードになりがちです。

3-3.大規模サンプル さまざまな種類のユースケースと画面のある大規模なサンプルです。 メリット デメリット 多くのユースケースに対応するために、責務分割に厳密な事が多い。責務を認識しやすいし、責務分割によってスパゲティを回避できたメリットも感じやすい。 デメリット 読むのがつらい。ただつらい。 これも小規模にそのまま適用すればただつらいだけです。

3-3.マーケティング重視サンプル プラットフォームの新機能を紹介するサンプルや、抽象度の高いAPIのデモに使われがちです。新機能を盛り込む事が最重要視されて設計されています。 メリット 新機能や、抽象度の高いAPIについて知りたいなら悪くない。しかしそれらのデメリット・不適切なシナリオはそのサンプルから知れない事も考慮する。 デメリット パターンや設計の例としてとらえない方が良いレベル。 抽象度の高い機能ほど威力を発揮するシナリオが限られる。なのにこういったサンプルを見て誤った万能感を感じてしまう事も少なくないので注意しましょう。 パターンや設計のお手本にするのは正直おすすめできません。

3-4.どのサンプルが一番学習に良いの？ 結論から言えばそれだけ見れば○○パターンがわかるサンプル・・・なんていうのはありえないんです。 責務の分割が曖昧な小規模②のようなパターンも、大規模なパターンも「設計の1インプットとして○○パターンを使用して実装を楽にした」ならば立派に○○パターンの適用成功です。 3種類すべてのサンプルを読み、自身で概念を構築しなおせるなら、サンプルコードから入る学習も有用でしょう。しかしそれならば最初から概念から入った方が近道です。 それに○○パターンの概念を本当に深く理解するには成り立ちも必要です。成り立ちはコードから学べないからです。

3.サンプルコードの捉え方 – まとめ １つのサンプルコードだけで、○○パターンを理解できるという事はない。 設計パターンはあくまでも設計のための1インプットにすぎない。要件と併せて適切な設計をそこからアウトプットする。 サンプルコードには様々な隠された目標がある。それをきちんと意識して読むならサンプルコードベースの学習も有用。

4. UIパターンの適用 UIパターンの適用

4-1.UIパターンの適用 – 概要 プラットフォームの選択が終わり、要件がある程度洗い出せている場合はUIパターンの適用を含めた基本的な設計方針が示せます。 この章では実際の開発を始める上で、UIパターン入門者がどうUIパターンを学習・適応 = UIパターンを含んだ設計をアウトプットしていくかついて考えてみます。

4-2.UIパターンの適用手順 手順は以下の通りになります。一つづつ注意点をあげながら解説します。 概念の調査・理解 サンプルコードの調査・解釈 実装要素の取捨選択 設計のアウトプット

4-2.UIパターンの適用① 概念の調査・理解 まず先んじて把握していなければいけないのは、UIパターンの適応結果=つまりアウトプットされた設計が「プレゼンテーションとドメインの分離」になっていなければ意味がなくなるという事です。 オンラインには非常にさまざまなリソースが存在します。その中には残念ながら不適切な内容を含んだリソースが存在します。設計の形は千差万別ですが、 「プレゼンテーションとドメインの分離」が出来ていない形のUIパターン実装を紹介しているようなリソースは残念ながら不適切と言わざるを得ません。 では星の数ほどある概念、どこから学んでいけばよいのでしょうか？

4-2.UIパターンの適用① 概念の調査・理解 原概念を学んでも実用とは遠くなります。そのプラットフォームのUIパターンではすでに原概念の形から大きく離れている事が非常に多いのです。 そうなれば当然インプットはそのプラットフォーム向けのUIパターンを紹介している情報を探す事になります。しかし検索した情報は新旧雑多です。 以上を踏まえれば採用プラットフォーム公式の概念ドキュメントを元に概念を理解するのが良いでしょう。 もっとも大事なのは、各責務は何の役割を背負い、責務同士がどう関連しているのかを把握する事です。概念の調査と理解で学ぶべきはこれだけです。

4-2.UIパターンの適用② サンプルコードの理解・解釈 サンプルコードを読みます。しかし前述したとおり、サンプルコードは純粋な○○パターンのサンプルにはなりえません。 責務も前のフェーズで調べた概念と異なる事もあるでしょう。 ではサンプルコードは何に役立てるんでしょうか？ それは実装要素の把握です。 各責務が自身の役割を果たすために、プラットフォームの何の機能を使っているか把握・一覧化する事です。 「その実装要素を使用しているから○○パターンである」などという誤った理解をしない事 パターンの理解をする上でもっとも弊害になっているのはこの誤った理解だと思っています。ここまでを見れば自明だと思います。

4-2.UIパターンの適用③ 実装要素の取捨選択 前のフェーズで把握した実装要素の長所と短所を把握し、使用できないもの・不要なものを切り捨てます。 「責務が自身の役割を果たすのに必須となる実装要素」を特定するのがこのフェーズの目的です。 抽象度の高い機能の採用判断は特に慎重に ある実装要素が特定のシナリオでしか強力に機能しないもの・シナリオから外れるとむしろ実装の足を引っ張りかねないような機能(主に抽象度の高い機能)なら、それが今回自分が開発したいアプリの要件に沿うのならともかく、そうでないなら切り捨てるしかありません。 冗長に見えるコードは、その冗長さが何を求めてそうしているものなのかきちんと把握してください。その上で判断してください。

4-2.UIパターンの適用④ 設計のアウトプット いよいよ設計のアウトプットです。プロトタイプユースケースの実装を持って確認してみましょう。 概念 概念の成り立ち – つまりは各責務がなぜ必要なのか –まで把握していない、またそのプラットフォームに精通していないなら 、不要な責務の切り捨てはやめるべきです。冗長に見えても愚直に実装しましょう。事故が減ります。 しかし概念の成り立ち – つまり各責務がなぜ必要なのか – まで把握しているのなら、あるいはプラットフォームに精通しているなら必要であればある責務と責務を統合しても構いません。 実装要素 決めるのはあくまでも「責務が自身の役割を果たすのに必須となる実装要素」です。 なんども言いますが抽象度の大きい機能の採用は慎重に。その機能が原因で責務の役割が曖昧になるような事があればそれが全体に波及してしまうのはあっという間です。

4.まとめ いくつか代表的なユースケースを実装してみて、成果物となった設計をUIパターンの観点からチェックするときに重要な観点は二つです。 「プレゼンテーションとドメインの分離」は出来ているか？ MVC/MVP/MVVMならそれぞれC/P/VMで分離が出来ていないような設計をよく見ます。設計の段階で意識的に責務を統合した場合は別ですが、これはよほど小規模な場合のみ成立することが多いです。そもそもそれほど小規模ならこういった手順を踏んでいない可能性は高いでしょう 「特定の実装要素」にこだわりすぎていないか？ 「その実装要素を使用しているから○○パターンである」というのは誤った理解でしたよね？

５. 注意点 詳細な設計のために

５-1.責務分けに悩んだときは？ 実際に詳細な設計と実装をしていく中で、実現したある機能が「どこの責務に属するべきなのか？」で悩んだ場合の考え方を紹介します。 主にVとMの中間層と、Mのどちらに属するかで悩まれますね。こういった時ほど概念の出番です。 Mから考えると悩む ModelはどのMVC系でも「ドメイン」と言われます。 しかし「ドメイン」とはどこからどこまででしょう？。サーバ・クライアント型などのクライアントではもともとクライアント自体がもっと大きなレイヤから見ればプレゼンテーション層です。プレゼン自体がアプリのドメインであるともいえます。Modelの成り立ちを考えてみましょう。(例：入力値検証は本当にクライアントのドメインじゃないの？) つまるところModelとはアプリのうちの「View」と「中間層」以外の部分という事です。UIパターンはViewのプラットフォームのためにあるんですから当然ですね？

５-1.責務分けに悩んだときは？ 実際に詳細な設計と実装をしていく中で、実現したある機能が「どこの責務に属するべきなのか？」で悩んだ場合の考え方を紹介します。 主にVとMの中間層と、Mのどちらに属するかで悩まれますね。こういった時ほど概念の出番です。 Viewに近いところから考える 前述したとおりUIパターンはViewのプラットフォームを活かすためにあるわけですから、Viewと中間層の責務は確定的です。 それ以外の所は全部Modelなんですよ。 こうやって考えると責務で悩むことはないし、「プレゼンとドメインの分離」も自然に行えます。

５-2.アンチUIパターン① - 3層もどき Web開発経験者の中には３層っぽいというだけで、こんな形にしちゃう人がいます。 画面 ビジネスロジック データ アクセス プレゼンとドメインの分離ができていません。 真ん中は実際は画面制御もすることになりますね。 MVC系のそもそもの目的はどこに？ ビジネスロジックもデータアクセスもModelの中が適切

通信ロジックとか、ユーザーIDとか管理するのは ５-2.アンチUIパターン② - クラサバ クライアント側は中間層からという考え方。 View 中間層 (C/P/VM) Model （サーバ） 通信ロジックとか、ユーザーIDとか管理するのは 中間層なの？プレゼンとドメインが(ry サーバとクライアントは違う目的を持つ違うアプリです。 Modelはほぼ必ずクライアント側にもある層ですよ。

6. まとめ

6.まとめ 今回のセッションで最も大事なのは 1.UIパターンとは？ 2.UIパターンとプラットフォーム の内容です。 この二つの内容をしっかり把握していればあとの内容はすべて導出項目です。コードも重要ですが概念もそれほど重要です。 1章と2章の内容を把握していれば少なくとも「○○パターンの現実解なコード」なんていう怪しげな情報に踊らされなくなると思っています。 今回話した「UIパターンそのものの捉え方」をしっかりと把握して、UIパターンを適切に使用して楽な設計・実装ライフを送っていただけると幸いです。

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