![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
#author("2021-06-22T06:00:33+00:00","","") #author("2021-06-22T06:01:20+00:00","","") [[SpringBoot]] * Spring Boot における各レイヤの責務 [#d216c4ba] 2020-05-18 中村 - 2020-05-18 中村 - 2021-06-22 中村 Spring Boot (Spring MVC)における各レイヤの責務をまとめる Entity, DTO, Form の役割も書いておく ** 概要 [#vf3d58cb] Spring Bootにおける各レイヤのコンポーネント (@Controller, @Service, @Repository) を設計・実装する際に，「この処理はどのコンポーネントで実装すべきなのか？」 と迷うことがある． NTTデータが出しているSpring MVCの詳細なプラクティス [[TeraSoluna:http://terasolunaorg.github.io/guideline/5.5.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html]] を参考にその 設計基準をまとめてみる． ** Springのレイヤード・アーキテクチャ [#bff17aa8] &attachref(spring_layered_architecture2.png); ** ブラウザ [#a4322976] ユーザに対して，Webアプリケーションを操作するユーザインタフェースを提供する． 主な責務 - 情報の表示 - 情報の入力 - ボタン操作 - リクエスト送信 - レスポンス受信 ** ビュー [#z761da04] ブラウザに表示するための画面を生成する． Webアプリの場合，以下の2パターンの実装がある： + サーバ側でViewを生成するパターン(Thymeleaf) -- 初等的なWebアプリで採用される．本コースで学ぶやり方 -- 実装しやすいが画面遷移を伴うためUXはイマイチ + クライアント側でViewを生成するパターン(HTML5+JavaScript) -- モダンなWebアプリケーションで採用される -- 1つのHTMLページを動的に書き換えてUXを向上．SPA (Single Page Application) -- コントローラはRestControllerとして，画面生成せずにデータだけを返す（マイクロサービス） --- RestControllerはブラウザ以外からも呼び出せるので，ネイティブアプリにも利用できる ** コントローラ [#l3d7850c] Webと業務プログラムの仲立ちをする． ブラウザからのリクエストを受け取り，業務処理を指示し，処理結果をビューに指示する コントローラの役割は業務ロジック（サービス）を利用するために必要な''前処理・後処理を行うこと''であり， 業務ロジックそのものに関連する処理を行ってはならない． 主な責務 - リクエストマッピング - 入力データチェック（''バリデーション''）→ 参考：[[SpringBoot/バリデーション]] - Form/DTO ⇔ Entity の変換 (業務ルールに依存しない範囲で) - 業務ロジックの呼び出し（具体的な処理の中身はService層に委譲） - 業務ロジックの結果をもとに，画面生成を指示 - 例外 → HTTPエラーマッピング (@RestControllerAdvice) [[SpringBoot/例外処理]] を参照 ** サービス [#ueac7a11] アプリケーション固有の''業務ロジック''を実行する． 業務ロジックは，ビジネスルールの実行，および，それに伴う業務データの参照，更新， ビジネスルールのチェックなどで構成される． サービスのの役割は，''ビジネスルールに関わる処理に専念''することとし， 業務データ（Entity）のDBへの出し入れはRepositoryに委譲する． 主な仕事 - ビジネスルールの実行 - ルールのチェックとビジネス例外のスロー - DTO ⇔ Entity変換 (業務ルールに依存する部分．Entity作成日時の付与，更新日時の付与など) - Repository経由での業務データ(Entity)の参照，更新 - トランザクション境界を宣言する (@Transactional) -- 一つのメソッド内で，複数のEntityを更新する場合，すべて成功してはじめて一つの処理（＝トランザクション）の成功とする．どれかが失敗したら，なかったことにしてやり直す -- TransactionはControllerでやってはならない．Serviceの1つのメソッド内に押し込めること． *** 参考：ControllerとServiceで実装するロジックの責任分界点について [#n660f0ba] Terasoluna より 本ガイドラインでは、ControllerとServiceで実装するロジックは、以下のルールに則って実装することを推奨する。 + クライアントからリクエストされたデータに対する単項目チェック、相関項目チェックはController側(Bean ValidationまたはSpring Validator)で行う。 + Serviceに渡すデータへの変換処理(Bean変換、型変換、形式変換など)は、ServiceではなくController側で行う。 + ビジネスルールに関わる処理はServiceで行う。業務データへのアクセスは、RepositoryまたはO/R Mapperに委譲する。 + ServiceからControllerに返却するデータ（クライアントへレスポンスするデータ）に対する値の変換処理(型変換、形式変換など)は、Serviceではなく、Controller側（Viewクラスなど）で行う。 ** レポジトリ [#r101eea0] 業務データの操作(CRUD)を行う． Java Beans (POJO)で保持されたEntityを，DBに入れて永続化するが， 具体的なDB操作の詳細はService層からは隠ぺいされる．(DAOのようなもの) Repository層の役割は，以下の2つである． + Entityのライフサイクル(CRUD)を制御する操作インタフェースを提供すること + Entityiの永続化を行う処理の実装を提供すること Springの場合，CrudRepository等の出来合いのコンポーネントが用意されているので，1や2を自力で実装する必要がない． - 参考： [[SpringBoot/JPA]] 主な仕事 - EntityのCRUD - カスタムクエリ - メソッド → SQL の変換 - オブジェクト → RDBのマッピング (O/R マッピング) ** DTO, Form, Entityの区別 [#efb587b9] - [[SpringBoot/DTO]] を参照 * 参考文献 [#bbca63fc] - TeraSoluna ドメイン装の実装 -- http://terasolunaorg.github.io/guideline/5.5.1.RELEASE/ja/ImplementationAtEachLayer/DomainLayer.html
