Teeda Extension featuring Goya 〜アーキテクチャ【Pegeの継承】〜
要件定義→外部設計→（アーキテクチャ）→内部設計→コーディング→単体テスト→結合テスト
今回は、Pageクラスの継承についてです。
Pageの継承
現在のTeedaのバージョン（3/18現在 Ver.1.0.6）では、各画面のPageクラスは、基底となる独自のPageクラスを継承するようにしておくと便利です。
多くのWebアプリケーションでは、以下のようにしておくと良いと思います。
- AbstractBasePage
- アプリケーション全体の基底クラス
- AbstractSubAppPage
- サブアプリケーションの基底クラス
- SubAppXxxPage
- 個々のPageクラス
上記の継承関係にした場合、バリデーションには注意する必要があります。
親クラスのバリデーションは継承されません。小クラスで明示的に指定する必要があります。
#バリデーションの継承を行えるようにするのは、現在Teedaコミッタ間でも検討中のようです。
なぜ継承するのか？
Teedaでは、Pageクラスのプロパティが画面の項目とマッピングされますが、何度も同じプロパティを定義しなくても済むようにするためです。
具体的には、以下のようなケースです。
分岐か分割か？
次に、サブアプリケーション内での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）では、その画面に必要な処理だけを記述することに注力できます。
実装量と単純さのバランスだと思いますが、特に画面数が多い場合は、多少実装量が増えたとしても、単純さを優先する方がトータルの生産性は高くなると思います。
