なぜ、Controller-Serivce-DAOの構成で作るのか?
エンタープライズアプリケーションでは、プレゼンテーション層-ビジネス層-インテグレーション層に分けるのが一般的です。インテグレーション層は主にデータベースアクセスとなりますが、その場合はデータアクセス層と呼ぶことがある。
層を分割するのは、分けることで保守性しやすくるするためです。
@Controller(プレゼンテーション層)
役割とやること
役割はHTTPリクエストをさばくこと。
- HTTPリクエストの受けとる
- リクエスト内容のチェック(単項目チェック・相関チェック)
- ビジネスロジックの呼び出し
- レスポンスする
作成単位とパッケージ構成
URL単位が分かりやすくて良い(と思っている)
実装方針
- パッケージは機能ID単位でわけるのがわかりやすい。(と思っている)
- @Controllerをクラスにつける。
- Controllerはインターフェースは作らない。
- クラス名はURLをそのままつけるか、APIのIDが振られていればID+Controllerも分かりやすい。
- コントローラはできるだけ薄く(少ないコード行数に)保つようにする。
@Service(ビジネス層)
役割とやること
- ビジネスロジックの実行
作成単位とパッケージ構成
実装方針
- Serviceはインターフェースを作る。
- 実装クラスにのみ@Serviceを付ければよい。(インターフェースには不要)
- 機能ごとの共通ロジックの置き場として、機能名サービスを作成し、機能内のサービスは機能名サービスを継承するようにする。
@Dao(データアクセス層)
役割とやること
作成単位とパッケージ構成
テーブル単位が管理しやすい。
実装方針
Doma2を使用することが前提として、Daoはインターフェースを作る。
実装クラスはAnnotation Processingによってコンパイル時に自動生成される。
JOIN句のあるSELECT文はFROM句に指定するテーブルのDaoに入れる。
publicメソッド命名規約
各層のメソッド名はこのようにつける。
CRUD | @Controller | @Service | @Dao |
- | HTTPメソッド名をそのまま使用する。 | 業務用語を英訳する。@Controllerや@Daoと被らないようにしておく。 | SQLの文法に合わせる。 |
Read | @GetMapping get | findXxx downloadXxx | selectXxxByYyy |
Create | @PostMapping post | registerXxx | insertXxx |
Update | @PatchMapping patch | editXxx | updateXxx |
Delete | @DeleteMapping delete | removeXxx | deleteXxxByYyy |
この命名規約にしたい理由は、シンプルさ・明快さである。
@ContollerはHTTPリクエストの処理が役割であるから、メソッド名をHTTPメソッド名にしておくことで、誰が作っても同じ命名になるはず。
@DaoもやることはSQLのSELECT/INSERT/UPDATE/DELETEの発行しかないから、メソッド名の冒頭部分は統一できるはず。
層を分離させておく観点から、@Daoの命名には業務用語は混ぜるべきではない。DB回りの用語に限定した命名とするのが良い。
@Serviceの命名が問題である。ここはプロジェクトによって全く違う処理が書かれるはず。整った運用としては、ある程度業務用語をリストアップして、その中から選ぶような形がいい。業務で特に使用される用語がればそれを英語にする。