2012/8/4 わんくま同盟大阪勉強会 #50 尾上雅則本セッションの目的と動機付け本セッションの目的は、 MVC/MVP/MVVMなどのいわゆるMVC系 GUIアーキテクチャ・パターンをMVVMパターンを通して適切に理解・学習・適用するための考え方を学ぶ事です。 MVVMパターンは XAML系プラットフォーム(WPF/SL/WP7/Metro) から生まれたMVC系パターンです。よくあるMVVMの図ですがこれは何のために必要なんでしょう？ → 保守性や変更容易性や開発生産性を確保するため → こんな事は全ての開発関連話題で当り前の事問題は何を持ってそのメリットを確保するか Viewは表示で、Modelはドメインあるいはビジネスロジックとデータ、ViewModelはその橋渡し・・・？ドメインって？クラサバだとビジネスロジックはクライアントにないよ？ Modelに書くべきことは結局どこからどこまで？ Modelが曖昧だと当然橋渡しのViewModelもわからない何をもって保守性や変更容易性や開発生産性を確保するか説明できていない。 ViewModelは橋渡しって３つの責務が繋がってたら真ん中が橋渡しなのは当たり前でしょ？MVCもMVPもMVVMも全部一緒になる。納得したような気にはなりますが、結局何も説明できていないんです  尾上雅則 (おのうえまさのり)  昭和58年生フリーランス  C#/MVVM WindowsForms/ASPNET/XAML系全般など  Blog – the sea of fertility – http://ugaya40.net Twitter - @ugaya40 Facebook – http://facebook.com/ugaya40 MVVMer  Microsot MVP for Visual C#(2012/7~)    日本でMVVMが流行り始めた２年前、その頃はまだ誰も View/ViewModel/Modelの各役割を説明できませんでした。説明は先ほど例示したそれのレベルでしたインターネット上にはMVC系パターンに関する知見があふれています。そのすべてが同じなわけではなく、さまざまな意見があります。そういった状況でただ「MVCでは○○は××する」「MVVMでは△△は□□と解釈する」などと言ってもそれを信じる根拠はありません。本セッションでは私の２年間のうちのMVVMの概念に関わる認識をなぞり、MVVMパターンをまず導出していき、導出の中で見出した目的・理由を武器に MVC系パターンの     本質はなんなのかどう理解するのかどう学習リソースを扱うのかどう適用していくのかについて考えていきます。 PresentationDomainSeparation DomoSolution - BeforePDS      コントロールの状態が制御判断に利用されている責務分割されていない(この形のままじゃやりようが無い) 例えば色ではなく画像で表すことになったら変更範囲が大きい責務分割されていないのでUIの変更から影響範囲が考察しにくい。場合によってはイベントの処理順にビジネスフローが依存しかねない DomoSolution - AfterPDS  YourCondition.cs     Form1.cs  コントロールの状態に依存しない状態制御手段を持った。コードがBeforePDSより長い BeforePDSと比べてUIの変更にはるかに強いコードの見通しも良いイベントの処理順にビジネスフローが影響されたりすることもない。しかしこの程度の規模では冗長さが目立つばかりこの考え方の事を PresentationDomainSeparation(PDS) と呼びます。本来当たり前のOOPです。関心事の分離です。相互依存は望ましくないのでObserverパターンで！ PresentationDomainSeparation Martin Fowler http://martinfowler.com/bliki/PresentationDomainSeparation. html (和訳) プレゼンテーションとドメインの分離 Martin Fowler‘s Bliki in Japan http://martinfowler.com/bliki/PresentationDomainSeparation. html (引用):プレゼンテーションとドメインの分離 “最も有用な設計原則に、プログラムのプレゼンテーション層（ユーザーインターフェイス）とその他の機能をうまく分ける、というのがあります。”  分離することによる理解のしやすさ  テストしにくいUIを分離してテスト容易部分を増やす  複数のプレゼンテーションで共有できるドメインができる  プレゼン部分はそのプラットフォームの知識が本来別に必要である  プレゼンプラットフォームの仕様・変更にドメインが引きずられない  メリットは多く、OOPにおいてはそもそも至極真当な話です。  PDSしなかった事により発生するデメリットは、一般的なOOP がきちんとできなかった際のデメリットと同様です。規模の大きさに特に比例して影響範囲などの把握が難しくなります。  ただ全ユースケースでの処理の概要が一人でも一望できるほど規模が小さいプログラムでは冗長さが目立つかもしれません。 XAMLの事情とMVVM. そして他のMVCパターンへ  同じコントロールも外観をXAMLだけで別の外見に。 <TreeView> <ListBox> 画像貼りミスじゃないですよ！  外見の変化はカスタムコントロールを作る動機ではなくなった。 • Windowサイズを広げてみる DomoSolution – BeforePDS/WPFLayout <WindowsForms> 残念。 <XAML> CSSと同じようなシステム   コントロールに状態に応じた外観を定義する事が可能になった。(状態間にアニメーションの定義も可能/状態を追加する事も可能) 外観に関わるコードはこうやってほぼ全てXAMLに委譲できる。  WPF/Silverlightのデータバインディングは双方向のデータバインドに対応している  コレクションコントロール(ListBox/TreeView)などには最強の武器がある。展開するまで子のインスタンスが無い！  コレクションコントロールのはまり所  チェック状態をバインドで処理していないと・・・ DomoSolution - CollectionControl  コレクションコントロールのはまり所  WindowsPhoneではさらに状況は深刻 DomoSolution - PhoneListBox スクロール関係ないところにチェックが！画面のレンダリングに必要な動的に変化する情報を保持するバインドオブジェクトを設ける事で正常に動作するバインド！  XAMLはバインディングファースト      コレクションコントロールもそうだが、XAMLプラットフォームの主な機能はバインディングが前提で作られている DataTemplateをC#/VBなどの汎用言語コードで構築しても全機能を使う事はできない。コントロールの状態は信用しない。コレクションコントロールの挙動などからも、メソッドどうこうより、バインドされたオブジェクトが正常にレンダリングされれば良いという哲学を感じる。バインドするオブジェクトはコントロールの状態ストアとして機能する  XAML用コントロールをコードからのみ自在に触るのは習熟が難しく限界がある。  XAMLはDSL(問題領域特化言語)   バインディング・レンダリング機能を充実させるためにCLRプロパティとは別のプロパティシステムをも備える CSSライクなDSLをわざわざ介す事で、柔軟なレンダリング・レイアウトシステム、そして仮想化などを含むコントロールの自由な実装を手に入れた。  XAMLは外観の変化に非常に柔軟なDSL   外観の変化を動機としてC#/VBなどの汎用言語コードを書く事はほとんどない XAMLはバインディングファーストDSL    メソッドやプロパティを直接触るのでは駄目で、バインディングじゃないとできない事があるくらい！バインドされたオブジェクトがコントロールの状態を決める PDSの説明で出てきた「プレゼンテーションプラットフォームの実装には汎用言語と異なった知識が必要」の典型例  WindowsFormsと比べると、XAML自体に対する知識がないと扱いにくい。WindowsFormsはC#に関する知識だけである程度できる。 XAML系プラットフォームでPDSを適用すると・・・そしてXAMLにはXAML固有の都合でバインドするオブジェクトが必要となるのでそしてXAMLにはバインドするオブジェクトが必要となるのでそしてXAMLにはバインドするオブジェクトが必要となるので View ViewModel Model この形の事をMVVMパターンと言います。見ての通り全然特別なパターンではありません。 View ViewModel Model  Viewの都合で存在するViewModelを責務として分けている理由はなんでしょうか？ Viewの都合であるものなのに、どうしてバインドするオブジェクトをViewのコードビハインドとかに書かないの？  Viewの都合で存在するViewModelを責務として分けている理由はなんでしょうか？  まず一つ目として使いまわしの視点があります。  ViewModelを書くのは手間です。使いまわせるところがあるなら使いまわしたいものです。  例えば詳細画面のViewModelを一覧画面でも使いたいなどがありませんか？  Viewの都合で存在するViewModelを責務として分けている理由はなんでしょうか？  また、Viewのクラスは基本的にDispatcherObject と言って、単一のUIスレッド以外から触ると例外が出ます。  ViewModelの値はModelから更新されることがあるのに、これは現在ネットワークアクセスなどがすべて非同期を強要される方向に向かっている(すでに WPF以外すべての環境で強要されます)XAMLプラットフォームでは大きな問題です。  ViewModelをView内に記述するわけにはいかないのです。見ての通り、XAMLプラットフォームの特徴に配慮してPDSを実現しようとした形がMVVMパターンになります。 MVVMは「XAMLプラットフォームとPDS」という視点から当たり前に導き出されるものであり、それは特定の業務に向いているとか向いていないとかではありません。 MVVMは「XAMLプラットフォーム」で開発する以上考慮すべき考え方と言えます。 MVVMパターンは、XAMLプラットフォームの力を存分に引き出して(それにはPDSが含まれる)設計を行うためのものです。 MVVMを見て、MVC系はPDSを各プラットフォームの特性に合わせて実現するものだと考えれば、他のMVC系の理解もサクサク進みます。   例えばASP.NET MVCはWebアプリケーションプラットフォーム Webプラットフォームである以上、HTMLのレンダリング(ASP.NET MVCの場合はRazorというDSLを使う)、セッション管理、遷移管理などの機能を持ちます。  しかしRazorがサポートするのは、単一ページのレンダリングであり、Webでは複雑になりがちな遷移管理などその他のViewプラットフォームの都合を請け負う部分が必要です。 ASP.NET MVCのRazor以外の、GUIプラットフォーム都合部分(主に遷移など)を請け負うのがASP.NET MVCでのControllerです。  もちろんViewとModelの間のデータの橋渡しもします。  原初のMVC ASP.NET MVC 同じMVCなのになんで違うの？ＭＶＣ系が「Viewプラットフォームの特徴を生かしたPDS実現パターン」だという事を思い出しましょう。つまり、プレゼンテーションプラットフォームが変わ MVC系は変わるのです。このサイクルを繰り返すそしてこの事が「同じMVCといえどもプラットフォームごとに全然変わってくる」理由と言えるでしょう。   MVVMパターンを含むMVC系パターンはPDSを実現するためのもの。 Presentation側が特にDSLを使用する場合などは、そのDSLの我儘などを担う部分が必要となってくる。 MV○パターンの○は全てPDSのPresentation側で、Viewで処理できないPresentationPlatform の我儘を担う。  MVVMのViewModel – XAMLのための状態ストア  MVCのController – Razorで処理できないASP.NET MVC固有部分  少なくとも国内ではそういう情報がほとんどない=少なくとも日本語ではそういった説明はほとんどないものの、実は元のマーチンファウラーのPDSの説明に該当箇所がある。(海外でも誤解している人が多い事は、MOVE絡みで把握) This principle is the most prominent part of Model View Controller (MVC), indeed for many people MVC is how they describe this separation. PresentationDomainSeparation – Martin Fowler この原則は、モデル・ビュー・コントローラー（MVC）の最も有名な個所です。確かに、多くのひとにとってMVCとは、この分断をどのように行うかというものとなっています。プレゼンテーションとドメインの分離 – MartinFowler’s Bliki in Japanse    MV○系パターンはプラットフォームを選んだ時点で、何を使うべきなのかほとんどの場合決まっている。業務などによらない。 MV○系パターンではModelの中の設計にタッチしない。ＭＶＣ系はPresentation固有の知識にあたる部分とそれ以外を分離するための知識である。導出フェーズ終わり MVC系の有効範囲結論から言うと概念を流し読みして理解が十分でない状態でサンプルからきちんとした概念を読みだそうとしても無駄です。何故ならMVC系パターンは「楽に開発するために」あくまでもPDSに付随するメリットを手にいれるための手段なので、例えばModelの中の設計にタッチしていないわけで、サンプルコードにはその他の概念が含まれすぎています。何種類か見てみましょう。例えば計算機レベルのサンプル厳密に３つの責務にわけた所で、PDSの冗長さが目立つだけです。きちんと理論から到達したなら、 PDSのメリットと冗長さというデメリットを比較して大抵こうはなりません。サンプルとしての意図でこうなっているんでしょうが、その割にはメリットも伝えられません。例えば計算機レベルのサンプル ViewModelをModelと統合しています。計算機程度の小規模であるならば、大抵の場合あるべき姿です。でもこの姿からMVVMの姿って学べませんよね。えーと、単純に読むのがつらいですし、適用されているMVC系以外の考慮事項多すぎますよね。例えばSilverlightのWCF RIA Service。普通に考えればそれだけ使えばModel部分を全部代替できるというものではないのですが、そういう代替できるシナリオをわざわざ用意したり、ViewModelの責務に微妙にModelが染み出したようなサンプルがMSさんの物には多いです。マーケマーケ。仕方ないとは思います。。。例えばASP.NET MVC3のスキャフォールディング。 ControllerからDBいぢれたりしちゃいます。 PresentationPlatformはその進化の過程で”定型シナリオに簡単に対応するために”PDSを部分的に崩しすような機能を盛り込んできる事があります。そしてこれが搭載されたMSさんが出してるような ASP.NET MVC3のサンプルは必然的にこの機能アピールが多くてつまりほとんどPDSが崩れているという。でもCodePlexにあがっているような規模の大きいサンプルで(Project Silkとか)では使っていないみたいですよ。 PDSを崩すデメリットが大きくなるからでしょう。同じMVVMを考慮した結果だけでも本当に無数にあります。ここから概念を抽出？・・・。 × Model内の設計・・ etc ドメインロジックパターンだけでも TransactionScript DomainModel TableModule (次のセッションで詳しく) サンプルから概念を理解した気になっている人は、MVVMであれば例えば   ViewModelではコマンドを使うコードビハインドを書かないなどと言った実装上の選択にすぎない事をMVVMの定義と紐づけます。しかしそれはやはりMVVMの定義とは関係がないものです。そういった実装要素は、メリットとデメリットをしっかり見極めてご自身で状況によって取捨選択してください。サンプルでの学習は概念の理解を前提としてそういった時に有用です。結論：いきなりサンプルからは無理なので横着しないできちんと概念から学びましょう。サンプルで学べるのは MVC系の考え方ではなくMVC系フレームワークの使い方程度です。そしてそうやって学んだ使い方では、もともとMVC系の責務分割の目的がわからないものだからその実装要素が何の目的に寄与しているかわからない、結果実装要素の取捨選択ができない。   コマンド使うのがMVVMだよね？コードビハインド使わないのがMVVMだよね？どちらも違いますもしPDSを踏まえてMVVMを理解していたらどうなるか？ ViewModelは「Viewの何の我儘を請け負っているのか」に頭が回るようになりますし、そうなれば ViewModelはViewの状態を受け持つという事もわかります。そしてPDSの観点からViewModelに含めるべきではないコードが明確になります。コマンドはコードビハインドを使わないっていうのは？そう、何一つトップダウンな決めつけなしできちんと PDSから各プラットフォーム用のMVC系をボトムアップで理解していけば、コマンドの使用やコードビハインドを使わないという知識は、XAMLとMVVMの組み合わせが可能にするViewの抽象化要件やデザイナとの分業要件のためにある事がわかるはずです。ならViewの差し替え・抽象化要件がなかったら？コマンドを使わなくても良いし、コードビハインドを書きまくれば良いと判断できます。 MVVMの責務分割の根拠となるPDSの不理解こそが MVVMを教条主義に変えるものです。サンプルコードから学んだつもりになっても学べないのは当たり前です。きちんと概念 – それが責務分割であるMVC系ではその責務分割の根拠となるPDS からしっかりと理解すればさまざまな事がわかってきます。まだ世の中に出て間もない新しいものは、そのプラットフォームの特徴を見極め、先ほどMVVMを導き出したように自分で検討してみるのもいいかもしれません。そしたら周知してくださいね！実は今回お話したMVVMの定義は簡略系です。 MVVMの先祖にPresentationModelパターンというMVC系のパターンがあります。同じに見えませんか？ええ、MVVMパターンはPresentationModelパターンに加えViewの抽象化要件やデザイナとの分業などを可能にしているだけにすぎません。その気になればViewを完全にXAMLの定義だけで構築することが可能な事や、Viewの抽象化に対応できること(コマンド/コードビハインドの使用生むなど)がPresentationModelパターン一般に想定されていないXAML系MVVM特有のメリットを生んでいます。では今まで説明したMVVMの定義で組んだアプリケーションはPresentationModelを適用したのであって、MVVMを適用したのではないのか？そうではありません。紛れもなくXAML系の都合とPDSを考慮 = MVVMパターンを考慮し、開発されたアプリケーションとなります。 MVVMパターンがもたらすメリットのうち、 Viewの抽象化要件やデザイナとの分業は多くのケースでは不要だから、それに関わる部分を選択しなかっただけですね。そして不要な部分はメリットが無くてデメリット(冗長さ)があるだけなのだから採用しない、それこそがまさに適切なMVVMパターンの適用法です。こうやってMVVMの責務分割/その根拠となるPDSから理解していればこういう取捨選択が可能になり、結果それがMVVMの典型的な実装になっていなくても、それは紛れもなくMVVMの適用結果として適切な実装(パターンを使用してメリットを享受)だし、MVVMを考慮した結果と言えます。これがMVVMなんだ！などという実装は存在しないし、則るだとか遵守だとかいう表現はそもそも不適切です。そういった表現はMVVMを実装例から学べたつもりになっている人に特有の表現なので気を付けましょう。そしてメリットを理解できていない実装に縛られているせいでMVVMを教条主義だと貶めるのも彼らです。惑わされないように。適用TIPS  ここでは前章までに培った知見を使って世の中で言われがちな様々な課題を確認していきます。  理解度確認に一緒に考えていきましょう。  MVVMを基準で話します。 Q.Modelはデータの入れ物？Ａ.データの入れ物だとしたら値をつめるのはViewModelしかなくなりますよね。PDSは？意図的に崩したのでないのであれば×。他のMVC系でも同様 Q.ModelはEntityFrameworkとかRIA Service？Ａ.そうなる場合もありますが、そうならない場合の方が多いのでその考え方に縛られないでください。必要あれば別の層をかぶせてModelとしてくださいね。△ まとめ MVVMであれば、ViewとViewModelの責務は決定的です。よく「今考えている処理をViewModelとModelのどちらに書けばいいかわからない」という話を耳にしますが、それはModelが曖昧な上にViewModelを橋渡しとしか思っていないからです真ん中にいるViewModelやControllerが必要以上に責務を負う事は、橋渡しもするからこそどんどん肥大する可能性があり危険なのです。 PDSを確保したいなら、ViewModelやControllerは極力薄くなるようにするべきです。欲しい機能は Model、あるいはViewのコントロールに持たせていきましょう。あのControllerやPresenterやViewModelをも全て一言でくくる事になり何の説明にもなっていない真ん中橋渡し論は本当に罪深いものです。しかし世間はそういった認識にあふれています。惑わされないようにしてください。楽をするためには時にはPDSで得られるメリットとデメリットを測りにかけて、PDSを崩すことも大事です。 PDSを守るのが本来の目的ではなく、あくまでも楽に開発するための設計パターンです。きちんと概念/PDSから理解していればメリット・デメリットの取捨選択はできますよね？小規模なコードでPDS遵守しても苦しいだけの事は多々ありますよ。