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

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

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

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

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して利用することになります。