Teeda Extension featuring Goya 〜アーキテクチャ【コンポーネント】〜

Seasar2 Teeda

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

今回は、各コンポーネントの役割についてです。

Action

役割 プレゼンテーションロジック。画面項目の表示／非表示切替や、ボタンを押下したときの処理などを記述する。
インプット 操作シナリオ
作成単位 画面単位
命名ルール 画面名+Action（例:EmpListAction）
  • Teedaのルール上、ボタンに付けたid（do〜）がメソッド名となります。
  • 初期化メソッドは、initialize/prerenderとなる。前者は、画面が表示される最初の1回だけ呼び出され、後者は、画面表示の度（バリデーションエラー時やポストバック時など）に呼び出されます。

Page

役割 プレゼンテーションモデル。Actionと分離しない場合は、プレゼンテーションロジックも兼ねることになる。画面項目と1対1のプロパティを持つ。
インプット 画面項目説明
作成単位 画面単位
命名ルール 画面名+Page（例:EmpListPage）
  • Pageクラスは、プロパティが重複することが多いため、業務機能単位の親クラスを作成しておくと良いでしょう。これは、業務機能単位がCRUD（追加／読込／更新／削除）のパターンになることが多いためです。命名ルールは、「Abstract+業務機能名+Page」となります。
  • Teedaでは「サブアプリケーション」という単位がありますが、それが業務機能にあたります。

Dto

役割 プレゼンテーションモデル。一覧など、1つの画面中に繰り返し表示をする必要がある場合に利用する。ドロップダウンリストやコンボボックスなどのデータは、リスト要素（実際は、java.util.Listのデータ）で表示が可能であるため、作成する必要はない。
インプット 画面項目説明
作成単位 画面項目単位
命名ルール 画面項目名+Dto（例:EmpDto）
※DBテーブルと1:1になる場合は、テーブル名+Dtoとしておく。

Service

役割 プレゼンテーションロジックとドメインロジックの仲介役。メソッドは、Actionからの呼び出し単位で作成する。
インプット 操作シナリオ
作成単位 画面単位
インタフェースと実装クラスを分離する。
命名ルール 画面名+Service（例:EmpListService）
画面名+ServiceImpl（例:EmpListServiceImpl）

Dxo

役割 プレゼンテーションモデル（Page、Dto）とドメインモデル（Entity）との変換を行う。
インプット 画面項目説明
作成単位 画面単位、もしくはDBテーブル単位
マスターデータは、後者となるケースが多い。
命名ルール 画面名+Dxo（例:EmpListDxo）
DBテーブル名+Dxo（例:EmpDxo）
  • S2ではインタフェースを書くだけで済みます。一覧のデータは、EntityのリストからDtoのリスト（もしくは配列）、ドロップダウンリストやコンボボックスのデータは、EntityのリストからMap要素のリストに変換します。
  • マスターデータは、後者となるケースが多いです。

Logic

役割 ドメインロジック。
インプット 操作シナリオ、処理レシピ
作成単位 業務機能（サブアプリケーション）単位、もしくは処理レシピ単位
命名ルール 業務機能名+Logic（例:EmpLogic）
  • 処理レシピ単位で作成したロジックは、操作シナリオ単位で作成したロジックから呼び出すようにし、ActionやServiceから直接呼び出さないようにします。

Dao

役割 データアクセスロジック。
インプット DB設計
作成単位 DBテーブル単位
命名ルール DBテーブル名+Dao（例:EmpDao）

Entity

役割 ドメインモデル。
インプット DB設計
作成単位 DBテーブル単位
命名ルール DBテーブル名（例:Emp）

補足

  • Page／Dto／Action／Dao／Entityは、Doltengを使うことで、ほぼ自動生成してしまいます。
  • 上記に当てはまらないコンポーネントとしては、Util／Helperなどがあります。
    • Utilは、staticなメソッドで実現できるユーティリティです。
    • Helperは、パラメータを設定したり、インスタンスを管理したりするために、diconで定義する必要のあるユーティリティです。
  • ServiceやLogicにおいて、複数機能に渡って共通的に呼び出されるような処理は、上記の単位にこだわらず、共通処理として括り出しておいた方が良いでしょう（AppCommonService、AppCommonLogic等）。それらは、他のService、LogicにDIして利用することになります。