ひがやすを技術ブログ

電通国際情報サービスのプログラマ

Pageクラス

Seasar Goya

Pageクラスとは、HTML(JSP)と一対一に対応するクラスで、画面に関する情報とイベントを処理するロジックで構成されています。
HTMLの入出力項目がPageクラスのプロパティにボタンのクリックのイベントがPageクラスのメソッドに対応すると考えると分かりやすいのではないでしょうか。
TeedaExtensionを例に説明します。
例えば､<input type="text" id="arg1"/>というタグは､Pageクラスのarg1というプロパティに対応します。arg1のプロパティにJavaで値を設定しておけば､HTMLに自動的に表示され、HTMLに入力した値は､自動的にarg1のプロパティに設定されます。
また、<input type="submit" id="doCalculate" .../>のタグをクリックするとPageクラスのdoCalculate()メソッドが呼び出されます。
このように、HTML(JSP)とPageクラスを一対一に対応させるアーキテクチャをPage駆動アーキテクチャといいます。Page駆動アーキテクチャ以外で有名なものには､StrutsのようなRequest駆動アーキテクチャ、JSFのようなEvent駆動アーキテクチャがあります。Page駆動アーキテクチャは､Event駆動アーキテクチャの一種です。
Page駆動アーキテクチャは、HTML(JSP)との関連が明確で分かりやすいので､今後のプレゼンテーション層での主流になるのではないかと思っています。
Pageクラスは、プレゼンテーション層に最適な構造を持っているので､「プレゼンテーションモデル」ということもできます。HTMLにid属性を書くだけでJavaと連携できるのも､プレゼンテーション層に最適な構造を持っているためです。
プレゼンテーションモデルを使うとプレゼンテーション層の開発がシンプルで分かりやすくなるということは理解していただけたのではないかと思います。
プレゼンテーションモデル(Page)を使う方法以外で有力なソリューションは､イベントハンドラ(Action) + ドメインモデル(Entity)を使う方法です。それぞれのプレゼンテーション層におけるメリット・デメリットは以下のとおりです。
プレゼンテーションモデル(Page)

  • メリット
    • プレゼンテーション層の開発がシンプルで分かりやすくなる。
  • デメリット
    • プレゼンテーションモデル(Page)とドメインモデル(Entity)を変換するコストがかかる。

イベントハンドラ(Action) + ドメインモデル(Entity)

  • メリット
    • プレゼンテーションモデル(Page)とドメインモデル(Entity)を変換するコストがかからない。
  • デメリット
    • プレゼンテーション層の開発が複雑で分かりづらくなる。

つまり、プレゼンテーション層の開発の簡単さとモデルの変換のコストのトレードオフになっています。ここで、モデル変換のコストがほとんどかからないとしたらどうでしょうか。プレゼンテーションモデル(Page)のデメリットがなくなり､メリットだけが残ります。
モデル変換のコストをほとんどなくすために使われるのが､Dxo(S2Dxo)です。S2Dxoを使うとインターフェースにメソッドを書いておくだけで､モデル変換のロジックは、アスペクトが自動生成します。
例えば､EmplooyeeというEntityをEmployeePageというPageに変換するとします。EmployeePageDxoに次のメソッドを書いておきます。



void convert(Employee employee, EmployeePage employeePage);
実装クラスはアスペクトが自動生成するのが書く必要はありません､後は､EmployeePageにEmployeePageDxoのsetterメソッドを書いておけば、自動的にDIされるので、EmployeePageで必要なときに次のメソッドを呼び出せば変換完了です。


employeePageDxo.convert(employee, this);
ほとんどコストをかけずにモデルの変換ができることが分かっていただけたのではないかと思います。
私の結論はこうです。


Pageクラスを使うことでプレゼンテーション層の開発がシンプルで簡単になり､モデルの変換のコストはDxoでほとんどなくすことができる。そのため、今後は､Page駆動アーキテクチャを使ったほうが開発は楽になる。
Pageクラスにはイベント処理をするための振る舞いがあるので､インターフェースが必要なのではと思う方もいるかもしれません。この件については次のように考えています。

  • インターフェースは､呼び出すクラスと呼び出されるクラスとの間の約束である。
  • Pageクラスは､フレームワークから呼び出されるだけで､他のクラスから直接呼び出されることはないので､インターフェースは特に必要ない。