⇧「シャーディング」によるメリットは分かったのですが、
⇧「デメリット」もあると。
Spring Framework公式のドキュメントのSpring Web MVCのControllerとリクエストの関係についてのアーキテクチャが分かり辛い
まぁ、そもそもシーケンス図とかも用意されていないっぽいので、Spring Web MVCの処理フローがブラックボックスなんよね...
更に言うと、
⇧ 旧いバージョンのドキュメントにしか、フロー図が無いのも問題だと思うのだけど、リクエストとControllerの間に、
⇧「DispatcherServlet」なるものが存在するらしいのだけど、何故、全体的なフロー図の方で省略するのか意味が分からない...
Spring Web MVCでリクエストに関する例外が起こり得る場所を整理してみる
最新のドキュメントには、そもそもアーキテクチャ図が無いのだけど、Spring Web MVCのドキュメントの「例外」のページを確認したところ、
⇧ という説明になっている。
う~む、それぞれのクラスの関係性が分かり辛い...
このあたり、有識者の方がフロー図をまとめてくださっており、
⇧ 上図のような処理フローになっている模様。
なので、リクエストに関するエラーを受け付ける場所としては、
- Controllerクラスに辿り着く前後
- Controllerクラスのリクエストを受け付けるメソッド内部
- Controllerクラス内で例外を捕捉する
ということになりそう。
つまり、
- Controllerクラスに辿り着く前に起こるようなエラー
- Controllerクラスでリクエストを受け付けるメソッドの引数が不正で起こるようなエラー
を捕捉したい場合は、Controllerクラス以外でエラーハンドリングできるようにしておく必要がありますと。
とりあえずは、
- @RestControllerAdvice
- @ControllerAdvice
のどちらかを用意しておけば良いんかな?
昨今の風潮から鑑みるに、「@RestControllerAdvice」を利用する感じになるんかな。
フロントエンド側からリクエストを受けたら、データだけレスポンスとして返して、フロントエンド側はそのデータを元に表示するページを作るっていうのが多い気がしますしな。
それにしても、Spring Web MVCのドキュメントでシーケンス図とか公開して欲しいですな。
どういう実装が可能なのか分かり辛くて仕方ない...
毎度モヤモヤ感が半端ない...
今回はこのへんで。