2012/8/4 わんくま同盟 大阪勉強会 #50 尾上雅則

本セッションの目的と動機付け

 尾上 雅則 (おのうえ まさのり)  昭和58年生 フリーランス  C#/MVVM WindowsForms/ASPNET/XAML系全般など  Blog – the sea of fertility –  Twitter -  Facebook –  MVVMer  Microsoft MVP for Visual C#(2012/7~)

本セッションの目的は、MVC系が分離しただけ で未着手の領域 – Modelについてどういった実 装の指針があるかを説明する事です。 この分野は用語の混乱がMVC系よりさらにひど く、正確な意味を把握するのが難しくなってい ます。

世の中にはModelという言葉が溢れていますが、このセッ ションの終わりには MVC系のModel ≠ DDDのDomainModel DDDのDomainModel ≠ PoEAAのDomainModel Model ≠ PoEAAのDomainModel MVVMのViewModel≠MVCのViewModel MVCのModel ≠ MVVMのModel WPF MVVMのModel ≠ JS MVVMのModel のような事を特段説明せずとも理解していただけるように なっていただけている事、Model周りについての説明の混乱 を避けられるようになる事目標としています。

一般的なWebアプリケーションのMVC系の Modelと、リッチクライアントのMVC系の Modelを例にとって説明します。 今回はPDSの視点からModelを見て、それぞれ ASP.NET MVCとXAML MVVMを例にとりなが らModelの中身について説明していく事にしま す。 前コマのセッションより、さらに先入観が理解 の妨げとなる内容ですのでご注意ください。

PresentationDomainSeparationのDomain部分再定義

PresentaionPlatformの都合が関係ある部分と、 それ以外の部分にアプリケーションを責務分割 する事。

アプリケーションはそもそもドメイン(問題領域)に対す るソリューションである。 そしてそのうちの一部分をPresentationPlatformが便 利に担ってくれている。 しかし便利に担ってくれている分、プレゼンテーショ ンプラットフォームは固有の知識や事情を必要とする 部分がある。そこを分離する

そしてPresentationPlatformの都合が関係ない 部分とは、 ASP.NET MVCやXAML MVVMではそれぞれ、 基本的にSystem.WebやSystem.Windowsを 必要としない部分になっているはずである。

これはすなわち、PresentationPlatformが異なれば、 ASP.NET MVCのModel、XAML MVVMのModelの形も 同じModelという名前にも関わらず異なる事を示します。 特にWebアプリケーションとリッチクライアントほど もPresentationPlatformの形が異なればほとんど共有 は不可能です。

Webアプリケーションは、極論「古いHTMLを 受け取って新しいHTMLを返すメソッド」の様 な動作です。(※最近流行りの非同期Web系は 今回は説明の都合で無視します)

セッション・ファイルアクセス・DB操作など の開発者自身がオブジェクトのライフサイクル 制御をおこなわないような処理を外部サービス へのアクセス処理として考えると、 ここが開発者の 主な関心領域

そしてそのすべてのオブジェクトが、1リクエ ストの度に生成され、そのリクエストの結果を 返却次第破棄されるのがWebアプリケーション の特徴です。ステートレス(状態を持たない)で す。

PDSの視点を適用すれば、 Modelの役割は、 PresentationPlatformを使用してフィルタリン グされたリクエスト/入力情報を元に、 PresentationPlatformが新しい画面を描画する のに必要な情報を渡す役割 として定義できます。

必然的にModelのインターフェースは戻り値を持つメ ソッドで表現される

リッチクライアントアプリケーションにはWeb のリクエストにあたるような明確な「オブジェ クトとの生成と消滅のタイミング」の区切りが 存在しないため、開発者がオブジェクトの生成 消滅などのライフサイクルを管理しなくてはな らない。(ステートフル)

また、WPFを除くすべてのXAML系 (Silverlight/WindowsPhone/MetroStyleApps)で はネットワークアクセスなど、同期処理を提供す るとUIスレッドのフリーズを招きかねない処理は 非同期のみでしかAPIが提供されない。 例えばHttpWebRequestクラスには、 BeginGetResposeとEndGetResponseは存在する が、単なるGetResposeは存在しない。 少なくともXAML系では、時間のかかるメソッドは すべて非同期化するように流れが向いている。 この事がModelのインターフェースに与える影響 は・・

Modelはすぐに戻り値を返せないので、 ユーザーからの入力をただ受け取るだけ。 ただModel内部では処理が始まっている。 ユーザーからの入力に際して・・

時間のかかる処理の終了は、外部サービス (サーバなど)からのPush通知などと同じように Model→ViewModel→Viewといった形で伝播 される。 Modelへの入力と応答は切り離される事が多い！

PDSの視点を適用すれば、 Modelの役割は、 PresentationPlatformを使用してフィルタリン グされたリクエスト/入力情報を受け取る。 のと、 自身の変化をPresentation層(ViewModel）に 通知する事 として定義できます。

PDSから見れば、同じ役割を担うアプリケーション でもMVC系のModelの役割は PresentationPlatformが異なれば当然違ってくる。 PresentaionPlatformが求めるMVC系のV + ○(C/P/VM)の責務は決定的でそれ以外の部分が Modelとなるから。 Web MVCのModelとXAML MVVMのModelの形が 違うのはそれぞれのPresentationPlatformの要求 が異なるため。

PoEAA TransactionScript/ PoEAA DomainModel/ DDD DomainModel

Web MVCのModelは PresenPlatformに関連しない範囲で 要求情報を受け取って、画面の描画に必要な情 報を返す。 それぞれ要求情報と、画面の描画に必要な情報 とは何か？

この画面の場合  検索対象はWeb  検索結果は全言語  検索単語は”MVC” 要求情報

この画面の場合  各種検索結果のURL/ タイトル/サムネイル なテキスト  関連広告のURL/タイ トル/サムネイルなテ キスト  などなど・・たくさん 新画面の描画に必要な情報

メソッドシグネクチャは Public SearchResult Model.Search( SearchType.Web, Language.All, “MVC”); のようなイメージ。

SearchResultは のようなただのデータ の入れ物。 メソッドを持ったりす る必要はない → 次のリクエストでは またこのオブジェクト を１から作り直すので 自身が変化したりする 必要がない。

Searchメソッド内部ではSearchResultに必要な情 報をDBなどから引っ張ってきて、SearchResult を作る。 Web MVCのModelは多くの場合は、ユースケース 中心粒度を基準に画面表示に必要なデータの入れ 物を作成し返す。 この形が TransactionScriptパターンです。 PoEAAにあるドメインロジックパターンの一つです。 ASP.NET MVCではこの入れ物の事をViewModelと呼び ます。

XAML MVVMではModelへのリクエストと、応 答が分割される事が多いところまで説明しまし た。 Twitterクライアントアプリケーションを例に、 XAML MVVMでのModelを説明します。

デモアプリ WPF4 Silverlight4 Windows Phone 7.1

Modelの構造 赤枠は変更通知コレクション

メインタイムラインを更新する Void TwitterApplication.Current.TimeLines[“Home”].Update() Staticプロパティ 内部ではネットワークアクセスが非同期で始まります。

メインタイムラインを更新する 内部での非同期処理が終了する と、タイムラインの変更通知コ レクションに新しいTweetが追 加されます。 この変更通知がこのModelから →ViewModel →View へと伝播していくわけです。

今回のデモアプリでは、Modelの中のオブジェクトは一 度作成されたら消滅はしませんが、実際にはツイート 保持数があまりにも増えた場合は自身のコレクション を削除する処理もあり得るかもしれません。 その場合もModelの変更通知コレクションの変化が ViewModel→Viewへと伝播していきます。 WebのTransactionScriptと比べると教科書通りのOOP です。 この形でのModelはコンソールアプリケーションでラッ プする形でも簡単にすべての機能を試せます。 (実際開発中デバッグはそうやって行いました)

画面に表示される情報は、Modelが保持する情報の射 影であり、その状態は常に変化しうるし、その変化を Presentation層に伝達する手段を持つ。また教科書的 なOOPのため、オブジェクト自身が自身に関するメ ソッドを持つ。 (WebのTransactionScriptの方がむしろOOP的に不自 然) アプリケーションの振る舞いをOOPで表現しただけ この形の事をPoEAAでいうドメインモデルパターン と認識しています。 やはりドメインロジックパターンの一つです。 トランザクションスクリプトが特殊だからこその存在だ と思います。

TransactionScriptをリッチクライアントに適 用するとどうなるでしょう？ 画面に表示されている情報はModelに保持されている情 報の射影ではなく、ユースケースに基づいて作成された 使い捨ての表示用オブジェクトです。 詳細画面での変更が一覧画面をリロードするまで伝わり ませんね。

TransactionScriptは基本的にユースケース粒度の 表示用データを集中して作っていくものなので、 例えば仕様変更などで、あるユースケースへの変 更が別のユースケースに影響を及ぼす場合でもそ れを認識できません/しにくいです。 所蔵本一覧取得画面の表示では、 本の価格は税込みを使うように変更 本当は所蔵本詳細画面でも同様の変 更を行う必要があるが気づきにくい

あらゆる意味で変更に対する追跡性が低いのが TransactionScriptのデメリットです。 また、処理の起点はユースケースであり、サーバ からのPush通知などを受け取るのはポーリングな どをしないと難しくなります。 しかしWebアプリではほとんど問題が出ない手法 です。というか、まさにWebアプリケーションの ための手法だと思います。Webアプリケーション はもともと処理の起点がユースケースしかありま せん。

DomainModelをWebアプリケーションに適用しよ うとするとどうでしょう？ ところがWebアプリケーションは結局 TransactionScript的なインターフェースを必要と します。 また内部に作ったDomainModelもWebアプリケー ションでは状態を持てないし、所属するメソッド をその入れ物に置くことは難しくなります。意義 が薄くなり手間が増えますが・・・超大規模/DDD 的な開発手法に限れば意味が出てきます。

ドメイン駆動設計(DDD)でのDomainModelは PoEAAのDomainModelとは意味合いが変わってき ます。 DDDにおけるDomainModelとは 業務のドメイン(問題領域)の専門家と DomainModelを定義し、それを開発者も共有する。 ドメインの専門家と作成したDomainModelをベー スに開発を行う。 私の理解ではこんなところです。

DDDについての深入りはボロが出るので避けた いところですが、これはWebアプリケーショ ン・リッチクライアント問わず想定されている 開発手法です。 DDDのDomainModelは業務的な意味をモデリ ングしたのものであり、それがそのままオブ ジェクトであるだとかクラス構造であるだとか と必ずしも紐づけさせる必要がないものだと 思っています。(もちろん紐づけた方が楽です がWebじゃ厳しいですよね)

業務的な意味を持つDomainModelは状態をも つだろうし、変化する事もあるでしょう。 IBMさんなんかはステートレスなはずなWebア プリケーションで擬似的にステートフルな DomainModelをオブジェクトして扱えるよう にする製品を出しています。(成功例は知らな いですが) そこまでしてDDD のDomainModelに拘る理由 はなんでしょう？

業務と、業務関連の状態の変化をそのまま図示し ようとすると模造紙数枚をつなぎ合わせなければ いけないような例えば金融のような超巨大業務で はTransactionScriptの変更追跡性の無さが致命傷 となる場合があるからではないでしょうか？ DDD の DomainModelに対する変更は TransactionScriptに対する変更よりはるかに追跡 用意なはずです。 私の理解はこうですが、DDDに対する理解が浅い のでさまざまなご意見をお待ちしております。

少なくともPoEAAにおいて、TransactionScriptと 対になるDomainModelはアプリケーションの振る 舞いをOOPしただけのものであり、DDDで言う DomainModelほどの業務的に深い意味と必ずしも 紐づく必要はないはずです。 そうでなければTransactionScriptと粒度が異なっ てきます。 PoEAAのドメインロジックパターン (DomainModel/TransactionScript/未説明の TableModule)でのオブジェクトは画面に表示する データの作り方と成り立ちに関わるものです。

 WebMVCのModelではステートレスなアプリ ケーションと相性の良いユースケース中心に 使い捨ての表示用オブジェクトを組み立てる PoEAAでいう所のTransactionScriptが基本  リッチクライアントのMVVMでのModelでは オブジェクト自身が状態や振る舞いを持ち、 画面に表示される情報はそのModelが保持す る状態の射影となるPoEAAでいう所の DomainModelが基本

PoEAA TransactionScript/ PoEAA DomainModel/ DDD DomainModel

 MVC系のModelとは、PDSの考え方によって アプリケーション全体から PresentationPlatformの知識を必要とする部 分を除いた部分全て。  PresentationPlatformの形が変われば、同じ 要件を実現するアプリケーション同士でも Modelの形が変わってくる。

 Web MVCのModelはステートレスであるた め、TransactionScript的なインターフェース を必要とする。  リッチクライアント – 特にXAML MVVMの Modelはそのメソッドが戻り値を返しにくい などの事情からDomainModelとしてしか設 計しづらい。  ドメインロジックパターンはModelの中の設 計指針の一つである。

MVC系のModel ≠ DDDのDomainModel DDDのDomainModel ≠ PoEAAの DomainModel MVC系のModel ≠ PoEAAのDomainModel MVVMのViewModel≠MVCのViewModel MVCのModel ≠ MVVMのModel WPF MVVMのModel ≠ JS MVVMのModel