Magic3の役割

Magic3フレームワークは、既存のWebアプリケーションフレームの問題点を解決し、Web技術に
新しい考え方とプラットホーム基盤をもたらすものです。
ここでは、既存のほとんどのフレームワークが元としているMVCモデルの問題点も合わせて、
既存フレームワークの問題点を示し、Magic3での解決方法を説明します。

  1. 画面遷移中心の考え方
    MVCモデルを基本としたフレームワークでは、クライアントからのアクションで、次に表示する画面を生成して表示するといった、
    画面全体を遷移する仕組みが主体になっています。
    アクションは画面(view)に結びつき、画面上のデータはデータのまとまりごとにデータモデルに結びつきます。
    画面に表示するデータが複雑になるにつれて、以下の図のように画面にモデルがたくさんぶら下がる構造になっています。
    コンテンツが少ない画面(A画面)とコンテンツが多い画面(B画面)を比較します。
    ここでの「コンテンツ」とは、まとまりのあるデータの固まりを表示している領域です。
    viewmodel.gif
    1つのアクションに対して、作成する画面が複雑になるにつれ、関連するモデルの数だけ処理は増加していきます。
    例えば、図の1つのコンテンツ部分を追加する場合、1つのアクションにおける画面生成までの1連の処理の流れすべての修正が必要になります。
    元々、モジュール分けして変更に強い仕組みにしているはずが、修正部分が局所的であるようにしているはずが、
    1連の流れすべて変更といったまったく意味をなさない結果を生み出しています。
    この問題は、アクションが「画面全体」に対しリンクしていることが原因です。
    1つのアクションが特定の領域(図のコンテンツ)を生成する仕組みと、画面全体を統合する仕組みを別にする考えが必要になります。
    Magic3フレームワークでは、個々のコンテンツ部分の生成と画面全体の統合の方法を分けることによって、多様なコンテンツからなる
    複雑なの画面の生成を容易にしています。(画面の生成方法?)
  2. 密結合
    MVCモデルの考え方としては、システムを構成するプログラムモジュールがそれぞれ独立した単位で開発でき、
    モジュール入れ替えが可能な汎用性の高いシステムができると考えられていました。
    しかし、実際のところはどうでしょうか。
    汎用性が高く、一部を切り取ればどこかのシステムにそのまま流用できるということは、今まで一度も実現した試しはありません。
    フレームワークに乗っかったシステムは、モジュールがサイトにぴったりくっついたままのサイト特化したモジュールの山であり、
    流用など程遠いシステムが構築されてしまいます。
    切り取って、別システムでそのまま使用できることはありません。モジュール同士が密結合しています。
    また、1つのディレクトリまるごと移動すればそのままモジュールを移動できるポータビリティ性のあるディレクトリ構成に
    なっていないフレームワークがほとんどです。
    Magic3フレームワークでは1つのディレクトリからなる完全な疎結合モジュール(Widget)によって非常にポータビリティ性の
    高い仕組みを実現しています。
  3. アクションで生成されるデータ
    アクションの実行よって生成されるのは、1つの画面です。ヘッダ付きのHTMLファイル全体です。
    HTMLに特化した汎用性にとぼしい形式のため、XMLやRSSといったWebサービス型のデータへの変更や流用は
    難しい仕組みになっています。 Magic3フレームワークで「アクション」の実行に近い機能を持つのはWidgetです。
    Widgetとは、「単体起動も可能」な、単にテキストを生成するという機能をもった部品です。
    Widget自体に画面生成のためのタグを生成させたり、XML,RSSなどフォーマットを指定して出力させたり、
    Widget単位で自由にコントロールできます。
    Widgetの考え方については、画面の生成方法?が参考になります。
  4. 決まりごとが多い