なぜ、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の命名が問題である。ここはプロジェクトによって全く違う処理が書かれるはず。整った運用としては、ある程度業務用語をリストアップして、その中から選ぶような形がいい。業務で特に使用される用語がればそれを英語にする。