PureMVCとCairngormにおけるGUIパターンの比較

作者 Moxie Zhang, 翻訳者 渡辺 裕之 投稿日 2008年7月2日 午後3時5分

コミュニティ

Java

トピック

RIA

タグ

Flex,

フレームワーク,

GUI

2008年6月9日、経験豊かなJava開発者であるPer Olesen氏はTech PerにおいてPureMVC(リンク・英語)とCaringorm(リンク・英語)という2つのとても人気のあるFlexフレームワークを比較したブログ記事を公開した(リンク・英語)。そこではとりわけ使いやすさとそれらがGUIアーキテクチャのパターンをどのように適用しているのかについて記述されている。

デザインパターンに基づいたアプリケーション開発はここのところJava開発者にとっての頼みの綱となっている。FlexやActionScriptの開発者にとってこの習慣はJavaでの開発経験から来たものか、ActionScript/Flexのフレームワークによってもたらされたものである。Olesen氏はこの経緯について下記のように述べている。

そのようなアプリケーションの設計を助けるためにいくつかのGUIアーキテクチャに関するパターンが開発され説明されてきました。Martin Fowler氏(リンク・英語)はPresentation Model(リンク・英語)やSupervising Presenter(リンク・英語)などのとてもよく知られたパターンについていくつかの素晴らしい記述をしています。これらはMVCのようなユーザインタフェース（UI）に関する完全なアーキテクチャではありません。アーキテクチャの手引きに関する小さな部分であり、アプリケーションのロジックがいかにビューフレームワークのAPIに依存しているかについて説明しています。

続けて以下のように説明している。

PureMVCはMediator（仲裁者、調停人）(リンク・英語)と呼ばれる構造を持ちます。それはまさに字面通りのものです。Mediatorパターン(リンク・英語)で実装されたアプリケーションはビュー部分のAPIとアプリケーションのその他の部分のAPIとの間を仲裁します。これがPureMVCがMVCアーキテクチャのビュー部分をどのように実装しているのかを現すカギとなる構造であり、アプリケーションとビューの依存関係を削減し、システム全体において依存具合を下げているのです。

Olesen氏は合わせてPureMVCには実装のイディオムに関するドキュメント(PDF・英語)とベストプラクティスを含むLoginPanelという見本があると指摘する。その見本ではmediatorはビューのことを知っているが、ビューはmediatorのことを知らないということを示している。

PureMVCのドキュメントで提供されているソースコードを解析した結果、Olesen氏はこのパターンはSupervising Presenter（監督するプレゼンター）またはPassive View（受動的なビュー）として知られたパターンそのものであると考えている。これらのパターンはどちらもビューから振舞いを抽出し、ビューと関連する別のプレゼンテーション用クラスにそれを移す。この処理はどちらのパターンでも「プレゼンテーションのクラスをビューを知っているが、ビューはプレゼンテーションのクラスは知らない」ように行われる。この2つのパターンの違いはどれだけのロジックを抽出するかということである。この場合、PureMVCのmediatorはSuperVising Presenterに一番近くなる。

Cairngormフレームワークに関連してOlesen氏は以下のように述べている。

Cairngormにはmediatorやsupervising presenter、passive viewといった概念やそれに類するものは一切ありません。実際のところ、ビューコンポーネントの状態を直接モデルにデータバインディングすることを推奨していることでCairngormは多くの人に非難されています。さらに悪いことにモデルはグローバルな状態にあり、シングルトン（なクラス）を通して提供されます。

Cairngormのドキュメントと見本（入門編のコンタクトマネジメントシステムと“上級編”のCairngormストアの両方）を見るとこの考え方がより明確になります。ビューには多くのロジックと同様に多くの操作が含まれておりAutonomous View（自律的なビュー）パターンと言われる状態になっています。autonomous viewとは何でしょう？Martin Fowler氏は以下のように説明しています：画面の状態、振舞いの全てを一つのクラスに詰め込んだもの。

Olesen氏はこれはまるで“無パターン”パターンであると考える。Cairngormベースで作成されたアプリケーションに含まれるautonomous viewはモデルのグローバルなインスタンスに直接データバインドすることを推奨していると考えている。そしてそれによってビューとモデルの関心事の分離をひどい状態にしていると考えている。

最後にはOlesen氏は単に一方のフレームワークが他方に勝るとは考えていない。氏は以下のように結論付けている。

どちらのフレームワークにとってもUIパターンはほんの一部に過ぎません。しかしとても重要な一部です。mediatorがフレームワークの組み込み済みのコンセプトとなっていることで、PureMVCの備え付けの機能により多くを得ることができると論じることはできます。mediatorとnotificationを通したmediatorとの通信によってPureMVCフレームワークはうまい具合に作り上げられています。

原文はこちらです：http://www.infoq.com/news/2008/06/gui-patterns-puremvc-cairngorm

• 次へ >