プログラマーズ雑記帳

今回はUIアーキテクチャーの歴史についてです。 
もともとスライドだったのですが、 説明を追加して、記事にしてみました。
最初は MVVM の簡単な説明のつもりでしたが、 MVC とその問題点を付けて、 最近のUI開発の傾向を書いて、とやっているうちに変に広がった内容になってます。

スライド版はこちらです。



ここからブログ版です。

目次

(一)MVC 以前  

(二)MVC - 拡張 MVC 時代  

(三)MVVM(.NET)  

(四).NET 以外の傾向  

MVC 以前

最初に MVC 以前の状態とともにUIアーキテクチャーにおける前提ついてお話します。

UIアーキテクチャーの大前提

MVC 以降いろいろなUIアーキテクチャーが登場しますが、 共通している目的は アプリケーションのコア部分とUI部分を分離する ということです。

これはかっこよく言うと、次のようになります。
 ビジネスロジックとプレゼンテーションロジックを分割する

MVC 以前ではそれらを1つのオブジェクトにまとめる傾向があったらしいです。
MVC 自体は賛否両論あるかも知れませんが、 そういった考えが広まり、UIアーキテクチャーが注目されるきっかけとなったことは 大きな意味があると思います。


もう一つ最初に伝えておくべきことは 完璧なUIアーキテクチャーはない ということです。

銀の弾丸などない という格言があります。
ソフトウェア開発では、魔法のように問題を解決するような技術は存在しないことを示唆する言葉です。 これはUIアーキテクチャーでも同様です。

そのため、最後に出てきたUIアーキテクチャーでも決定版とはなりません。
問題がでてきて、新しいものが生まれるという繰り返しが今後も続いていくでしょう。

MVC と 拡張 MVC 

MVC (GoF 本) 

MVC が広くつかわれるようになったのは、 ﹃ GoF 本﹄ で紹介されたことが大きかったでしょう。
そこで、﹃ GoF 本﹄ での MVC から始めることにします。

もう少しわかりやすいように Wikipedia にあったシナリオをコラボレーション図風にしました。



今までの説明で MVC は理解できたでしょうか?

Model 、 View の方はわりとわかりやすいと思います。
しかし、 Controller はわかりづらいです。 ユーザー入力に対するインターフェースといわれても、 "View に入るんじゃないの ?" と思う人も多いでしょう。

また、ちゃんと理解できたとしても、"もっといい方法があるんじゃないか" と指摘したい点も多々あるんじゃないでしょうか。
例えば、 私は Model から View へ矢印がでているのは、結合が密になりよくないと思います。


誤解されたり、改良されたりで、 MVC は人によって解釈が様々になってしまっているのが現状です。
MVC が何を指しているのか、はっきり言って正解はわかりません。

今度は、この変化していった Web、PCでの MVC について見ていきます。

MVC (Web)

Web サービスで広く使われている MVC フレームワークとして Ruby on Rails があります。 これは次のようなアーキテクチャーです。

Web の場合は View と Controller の違いははっきりしてます。
View は html ページとその作成を担当します。 CGI は アドレスとパラメーター(アドレスの?の後など)を受け取り、処理を行います。 その受け取り部分が Controller です。


Model と View ではなく、なぜ MVC としたのでしょうか?

﹃ GoF 本﹄ では Controller を分ける利点をいくつか挙げられています。

●キーボードの応答を変えたり、メニューからの呼び出しに変更するとき、表示方法を変更しなくていい。  

●入力イベントを無視するといったことをコントローラーのインスタンスの入れ替えで可能。  

その他にも "View を入れ替えれば、PCアプリ、 Web アプリでも使えるように" という理由もあります。
ちょっと無理そうな話ですが、例えば、PCアプリが次のような構成であれば、 入れ替えて使うということができるかも知れません。

ただし、アプリが複雑化してくると、すぐ厳しくなってくるはずです。
やはり、これは欲張りすぎというものでしょう。

拡張 MVC (PCアプリ)

次にPC上で動作するデスクトップアプリケーションの場合です。
この場合は、 Widget や Control といった GUI ツールキットが提供する部品を組み合わせて作成します。

高機能な部品になってくると、どうしても表示と入力処理を兼ね合わせるものになってしまいます。 このため、 View と Controller の分離は不可能になってきます。

﹃ GoF 本﹄ で指摘されている機能はほとんど GUI 部品の方で機能を持っていますし、 普通はPC向けだけに作るので、あまり Controller を分ける必要もありません。


そこで、でてきたのがVとCをまとめて View とする拡張 MVC です。 (拡張といいつつ、減っていますが...)
これは、コアとUI分離という基本原則だけ残った形です。

拡張 MVC は GUI ツールキットによっては次のような呼ばれ方もします。


●MFC : Document - View

●Qt : Model - View

問題点

次のような状態でしばし落ち着きます。

ただし、 拡張 MVC に問題がないわけではありません。
それは View の肥大化 です。

もともと大して分けてないので、 プログラムの 8, 9 割が View というのも珍しくありません。
ちゃんと意識して作らないと、全部 View で MVC 以前に戻ることもありえます。
そこで、"なんとか分けなきゃ" となります。


一方、 Web は Web で Google の Web アプリのような高機能なものが求められ、 JavaScript が大規模化し、 こちらも View の肥大化が起こります。

UIアーキテクチャーの乱立

問題点の解決ためにいろいろなUIアーキテクチャーが考案されます。

●MVP - Model, View, Presenter

●PM - プレゼンテーションモデル 

●アプリケーションモデル 

これらのアーキテクチャーについては次のサイトで詳しく説明されています。

●開発者が知っておくべき、6つのUIアーキテクチャ・パターン - ＠IT

ただし、ここで MVC の拡大解釈が話を複雑にします。
例えば、 MVP の Presenter は簡単にいうとMとVの﹃つなぎ﹄の役割ですが、 Controller の名前でそのように使われることもあります。

また、 こういったUIアーキテクチャーは GUI ツールキットなどで、 フレームワークとして提供されないとなかなか定着しづらいものです。

●ライブラリー、ツールキット、フレームワーク 違いわかる? | プログラマーズ雑記帳

要望

新たな要望も出てきます。
これはデザインの重要性が高まりからきています。

Web サイトは大手企業などでは Web デザイナーが作成しています。 それと同じように画面デザインもデザイナーに任せたいという要望です。

しかし、そのためには 画面レイアウトとコードを分離する必要が出てきます。
ただ、これは GUI ビルダーでも、昔から試行錯誤されているところなので、古くからの要求ともいえます。

画面レイアウト、コード分離の難点

GUI アプリケーションでは必然的にイベント駆動プログラミングとなります。
これが分離のネックです。

イベント駆動では呼び方はいろいろありますが、基本的に次のような仕組みです。


●シグナル(イベント) → コールバック 




●ループで画面を表示

●イベント発生(ボタンクリックなど)

●コールバック関数が呼ばれ、処理を実行

●ループに戻る

このボタンなどの部品とコード上で定義されたコールバック関数を結び付ける必要があります。

MVVM(.NET)

問題点の解決のため、 .NET では MVVM が使わるようになってきました。

.NET の登場 

(一)Win32API と MFC

(二)Java の台頭

(三)C#、.NET で対抗

1. 
Windows での GUI のベースはC用の Win32API です。
.NET 登場以前は VC++ では API をラップした MFC が使われていました。Cのラッパーなので、オブジェクト指向でできていないとか、 C++ でしか使えないといった批判がありました。

2.
そんな中 Java が出て来ました。
Java はガベージコレクションなどの機能で C++ よりも開発しやすく、しかもクロスプラットフォームです。
また、 Linux も gnome や KDE などで使いやすくなってきていました。
アプリケーション開発をみんな Java に移行され、 そのアプリがOSを選ばずに動作するとなれば、 開発ツールだけでなく、 Windows からユーザーをごっそり持っていかれる危険性が出てきます。

3. 
そこでMSが対抗して出したのが C# と .NET です。
ただし、そこで最初に用意された Form は従来の部品を .NET 用にラップしたもので、 ピュア .NET ではありませんでした。
﹃6つのUIアーキテクチャ・パターン﹄での紹介では フォームとコントロール ですが、これはまだ拡張 MVC のままといってもいいでしょう。

WPF

その後、.NET 用に作りなおされた GUI ツールキットとして登場したのが、 WPF です。


しかし、なかなか広まっていないのが現状です。
おそらく、原因は次のようなところでしょう。


●Form の方が部品が多機能で豊富  

●従来の部品を使っているからこそ、今までの蓄積分があり、 WPF の部品が貧相に見えてしまいます。
 


●使い方がわかりづらい  

●WPF ではVSで部品を配置した後、ハタと次どうすればいいかわからなくなってしまいます。  Form の方が使い方は想像しやすいです。
 また、使っている人が少ない → いいドキュメントも少ない ということもあります。 



●長い間MS製品ですら使われなかった  

●﹁さぁ、使ってください﹂と出された WPF ですが、  使う場合には﹁本当に実用に耐えうるの?﹂ というのは気になるところです。
 そんな中、MS自身が自分のところの開発に使っていないとなると﹁大丈夫かこれ。﹂と思うのは当然でしょう。
 

MVVM の登場

  WPF はなかなか使われません。 しかし、だからといって Form のままでは問題点と要望が解決できません。

●View の肥大化

●画面レイアウトとコードの分離

ここで問題解決のための MVVM の登場となります。
流れとしては MVP → PM → MVVM といった感じです。

●WPF のための MODEL-VIEW-VIEWMODEL (MVVM) デザイン パターン # Model-View-ViewModel の進化

  と、その前に採用されている技術を紹介しましょう。

●データバインディング

●コマンドパターン

データバインディング

今更ですが、データを扱う部分は Data や Core ではなく、 何故 Model というのでしょうか?

ここでの Model の意味はモデル化、モデリングといった時と同じで抽象化の意味です。
データは XML ファイルやDBなどですが、これをプログラム内では扱いやすい構造体(オブジェクト)などに変換して使います。 データそのものではなく、構造体などに抽象化しているところなので、 Model です。


デスクトップアプリでは、 Model 内でデータを構造体(オブジェクト)として直接管理することもありますが、 多くはファイル、DBから構造体(オブジェクト)に変換する必要があります。
この技術をデータバインディング といいます。
ただ、 プログラミング言語にメタプログラミング(リフレクション)の機能が必要だったり、 C++ のようにそれがない言語では特殊な前処理が必要だったりとそうそう簡単にできるものでもありません。

設定画面でよくあるパターン

﹃ GoF 本﹄にでてくるようなパターンではありませんが、 設定画面などでよく使われる手法があります。

それは画面の内容と構造体(オブジェクト)との相互に変換する機能を持たせることです。
デフォルト値があったり、部品の値がそのまま確定ではないモーダルなダイアログだったりする場合に向いています。

通常、この変換は自分で実装しないといけないのですが、 WPF ではこの実装を助ける機能があり、双方向データバインディングと呼ばれています。


これ、 Model で使われるものと似ていないでしょうか?
画面(View)を構造体(オブジェクト)に変換することで、抽象化しています。 ViewModel の由来は View 用の Model というところからきています。

双方向データバインディングにより、 ViewModel のオブジェクトの値を変更すると画面が変更され、逆に画面を変更すると ViewModel の値が変わります。 画面を抽象化した ViewModel としておくことで、プレゼンテーションロジックのテストがやりやすくなります。

コマンドパターン

こちらは﹃ GoF 本﹄にもでてくるパターンです。

要求をオブジェクトでカプセル化するパターンで、 いろいろなところからの呼び出しに対応しやすくなります。

MVVM

MVVM は次のような構成です。

画面レイアウトとコードの分離

View

XAML : XML でレイアウト定義

ViewModel



●データ: 双方向バインディングで同期 (大部分をこれで行う)

●コマンド : 必要最小限のイベント駆動
 


View で画面の作成を行い、このレイアウト定義を XML に記述します。
これにより、 画面デザインは Expression Blend などのデザインツールで行えるようになります。

パラメーター項目の設定などはデータバンディングを使い、 [OK] ボタンを押すといった必要最小限だけイベント駆動にします。
これにより、なるべくコードと分離しています。

View の分割

拡張 MVC (MV) における View の部分を View と ViewModel に分割することで肥大化を軽減しています。

ただ、 ViewModel がコマンドの管理だけならば、 Controller と区別しづらく、MVC に取り込まれていたかもしれません。
データバインドが MVVM の特徴です。

逆にデータバインドの機構がないと実装が大変なため、 MVVM は WPF 用のUIアーキテクチャー と言えます。

MVVM の実装

確かに MVVM は WPF 用のUIアーキテクチャーです。
しかし、注意していただきたいのは、 WPF は MVVM フレームワークではないということです。

これは次のようなことを意味します。

●WPF で作れば MVVM になるわけではない  

●MVVM のアーキテクチャーを崩さないよう意識して実装する必要がある
 


●MVVM を実装するには毎回同じようなコードを書く必要がある

毎回同じようなコードを書くのは面倒なことです。 そこで MVVM 用のライブラリー(フレームワーク)がいくつか存在します。
(﹃ MVVM 入門 その4﹁ライブラリを使おう﹂ 言語: C# Visual Studio 2010 用﹄)

●Prism

●MVVM Light Toolkit

.NET 以外の傾向

.NET 以外にも、最近の傾向について触れておきます。

Web アプリケーション

問題のところで Web では JavaScript の部分が大規模化していると記述しました。
この解決策としては、 JavaScript の部分もフレームワークを使うというものがあります。

よく使われるフレームワークは Backbone.js、 AngularJS といったもので、 MVC が主流のようです。


2段構えになってややこしいですが、 JavaScript はセキュリティ上、サーバー側のアクセスには制約があり、仕方ないところでしょう。
ただ、 最近は Node.js などのサーバーサイド JavaScript もあり、 コードを共有化して減らすといった工夫もできます。

また、 JavaScript には "スクリプトのわりに書きづらい"、﹃大規模開発に向いていない﹄といった欠点があります。このため、 変換系の新言語や Dart に移行するという流れもあります。

●続々出てきた JavaScript 系新言語。どれを使う? | プログラマーズ雑記帳

MVVM にはデータバインディングが必要と書きましたが、 実は Dart のUIパッケージにもデータバインディングの機能があります。
ただし、こちらは MDV(model-driven view) というアーキテクチャーを採用しているようです。

●Web UI Package | Dart: Structured web apps

モバイル

スマホ、タブレットの出現により、 今までのPC、 Web に加え、 モバイルという分野ができてきました。

このモバイル用アプリは標準では次の言語で開発します。