読者です 読者をやめる 読者になる 読者になる

Teeda Extension featuring Goya 〜アーキテクチャ【Pegeの継承】〜

Seasar2 Teeda

要件定義外部設計(アーキテクチャ)内部設計コーディング単体テスト結合テスト

今回は、Pageクラスの継承についてです。

Pageの継承

現在のTeedaのバージョン(3/18現在 Ver.1.0.6)では、各画面のPageクラスは、基底となる独自のPageクラスを継承するようにしておくと便利です。
多くのWebアプリケーションでは、以下のようにしておくと良いと思います。

  • AbstractBasePage
    • アプリケーション全体の基底クラス
  • AbstractSubAppPage
    • サブアプリケーションの基底クラス
  • SubAppXxxPage
    • 個々のPageクラス


上記の継承関係にした場合、バリデーションには注意する必要があります。
親クラスのバリデーションは継承されません。小クラスで明示的に指定する必要があります。
#バリデーションの継承を行えるようにするのは、現在Teedaコミッタ間でも検討中のようです。


なぜ継承するのか?

Teedaでは、Pageクラスのプロパティが画面の項目とマッピングされますが、何度も同じプロパティを定義しなくても済むようにするためです。
具体的には、以下のようなケースです。

  • アプリケーション共通で使われるプロパティがある → AbstractBasePageに定義
    • 通知用とエラー用のメッセージを別々に出力できるようにプロパティを定義する(FacesMessageを利用する場合、画面では内容を判別できないため、スタイルなどを別々に定義できない)。
    • ページング処理など、Teedaの標準機能にはないプロパティを定義する。
  • 同一サブアプリケーション内でのCRUD処理(作成/照会/更新/削除)では、大抵同じプロパティが使われる → AbstractSubAppPageに定義
    • 同一テーブルに対する処理になるため、各画面で同一プロパティを定義することになる。

分岐か分割か?

次に、サブアプリケーション内でのPageクラスの作成単位についてです。


Doltengが出力するScaffoldでは、CURDの処理を以下の単位で作成しています。

処理内容 画面 Pageクラス
一覧 一覧 SubAppListPage
編集 作成/更新 SubAppEditPage
非編集 作成/更新の確認、削除、照会 SubAppConfirmPage

これは、処理の内容に応じて表示を分岐するパターンです。
それで済む場合は、実装量も少ないので、最も簡単かもしれません。


ただ、実際のアプリケーションでは、編集できる項目が変わったり、表示内容が変わったりして、分岐が増えがちです。
そうなると、1画面内の処理が複雑になり、バグも発生しやすくなります。

#私は以前、1画面中に、4画面分ぐらいの情報を含んだHTMLを見たことがあります。
#そうなると、実際に動作するときには、もう、どこが呼ばれているのか分からないですね orz


なので、私は分割する方が良いと考えています。
ここで言う「分割する」とは、処理毎にPageを分割することを指します。処理と画面とPageを1:1:1として作成することになります。

つまり、以下の単位でPageを作成します。

画面 Pageクラス
一覧 SubAppListPage
作成/作成確認 SubAppCreatePage/SubAppCreateConfirmPage
更新/更新確認 SubAppUpdatePage/SubAppUpdateConfirmPage
削除 SubAppDeletePage
照会 SubAppInquirePage

このパターンは、単純さを優先です。
AbstractSubAppPageを継承するようにすれば、各Page(もしくはAction)では、その画面に必要な処理だけを記述することに注力できます。


実装量と単純さのバランスだと思いますが、特に画面数が多い場合は、多少実装量が増えたとしても、単純さを優先する方がトータルの生産性は高くなると思います。