もう迷わない！Spring Frameworkの仕組みをわかりやすく図解

By /

はい、承知いたしました。
Spring Frameworkの仕組みをわかりやすく図解した、約5000語の詳細な解説記事を作成します。

もう迷わない！Spring Frameworkの仕組みをわかりやすく図解

はじめに

「Spring Frameworkは、まるで魔法のようだ」

JavaでWebアプリケーションを開発する多くのエンジニアが、一度はそう感じたことがあるのではないでしょうか。アノテーションをいくつか付けるだけで、複雑なオブジェクトの管理や、本来ならあらゆる場所に記述すべき共通処理が、いつの間にか実行されている。その便利さの裏側で、一体何が起きているのか。その「魔法」の正体がわからず、漠然とした不安を抱えながら開発を進めている方も少なくないでしょう。あるいは、過去に学習を試みたものの、DI、AOP、IoCコンテナといった専門用語の壁にぶつかり、挫折してしまった経験があるかもしれません。

この記事は、そんなあなたのために書かれました。Spring Frameworkが決して「魔法」ではなく、非常に合理的で優れた設計思想に基づいた「仕組み」であることを、一つひとつ丁寧に、そして図を多用しながら解き明かしていきます。

この記事を読み終える頃には、あなたは以下のことを深く理解できるようになっているはずです。

  • Springの心臓部である「DI（依存性の注入）」が、なぜアプリケーションを柔軟でテストしやすくするのか。
  • 横断的な処理を美しく分離する「AOP（アスペクト指向プログラミング）」の強力な概念とその実現方法。
  • Webリクエストがどのように処理され、画面に表示されるのかという「Spring MVC」の全体的な流れ。

私たちは、難解に見えるSpringの内部構造を一枚ずつ剥がしていき、その核心に迫ります。もう「何となく動くからOK」で終わらせるのはやめにしましょう。仕組みを理解することで、エラー発生時のトラブルシューティング能力は飛躍的に向上し、より高度なアプリケーションを自信を持って設計できるようになります。さあ、Spring Frameworkという名の巨大な山の、確かな地図を手に入れる旅に出かけましょう。

第1章: Spring Frameworkの全体像 – なぜ「フレームワークのフレームワーク」と呼ばれるのか？

Spring Frameworkの具体的な仕組みに足を踏み入れる前に、まずは少し視野を広げて、Springがどのような立ち位置にあるのか、その全体像を把握しておきましょう。

Springの誕生と哲学

Spring Frameworkは、2003年頃にRod Johnson氏によって生み出されました。当時のJavaエンタープライズ開発は、EJB (Enterprise JavaBeans) という技術が主流でしたが、その仕様は非常に複雑で重量級でした。開発者は、ビジネスロジックそのものよりも、EJBの「お作法」に準拠するための定型的なコード（ボイラープレートコード）を大量に書く必要があり、生産性の低下やテストの困難さが大きな問題となっていました。

Springは、この「複雑なJ2EE（現・Jakarta EE）からの解放」を大きな目的として登場しました。POJO (Plain Old Java Object)、つまり「普通のJavaオブジェクト」をそのままビジネスロジックに使えるようにし、特定の技術に縛られない、軽量で柔軟な開発スタイルを提唱したのです。この哲学が多くの開発者に支持され、SpringはJavaの世界でデファクトスタンダードの地位を確立しました。

Spring Ecosystemの全体像

今日の「Spring」という言葉は、単一のフレームワークを指すだけでなく、巨大なエコシステム全体を指すことが多くなっています。その中心に位置するのが、この記事で解説するSpring Frameworkです。そして、その周りには様々な目的を持ったプロジェクトが存在します。

“`mermaid
graph TD
A[Spring Ecosystem] –> B[Spring Framework];
A –> C[Spring Boot];
A –> D[Spring Data];
A –> E[Spring Security];
A –> F[Spring Cloud];
A –> G[…その他多数];

B -- 中核機能を提供 --> A;
C -- 設定の自動化と迅速なアプリ開発 --> A;
D -- データアクセス層の簡素化 --> A;
E -- 認証・認可機能 --> A;
F -- マイクロサービス構築支援 --> A;

subgraph "Core Engine"
    B
end

subgraph "Application Starters"
    C
end

subgraph "Specialized Modules"
    D
    E
    F
    G
end

style B fill:#f9f,stroke:#333,stroke-width:2px

“`
【図1: Spring Ecosystemの全体像】

  • Spring Framework: DI、AOP、トランザクション管理、Spring MVCなど、すべての基本となる中核機能を提供します。まさにエコシステムの土台です。
  • Spring Boot: Spring Frameworkを利用したアプリケーション開発を、劇的に簡単にするためのプロジェクトです。「設定より規約」の思想に基づき、面倒なXML設定などをほぼ不要にし、実行可能なアプリケーションを迅速に構築できます。
  • Spring Data: データベースアクセスの実装を驚くほど簡潔にします。JPA (Java Persistence API) やJDBCなどをラップし、簡単なインターフェースを定義するだけでデータ操作が可能になります。
  • Spring Security: 認証・認可といったセキュリティ機能を、宣言的にアプリケーションに組み込むことができます。
  • Spring Cloud: マイクロサービスアーキテクチャを構築するためのツール群を提供します。

これらのプロジェクトはすべて、土台であるSpring Frameworkの仕組み（特に後述するDI）の上に成り立っています。だからこそ、Springは「フレームワークのフレームワーク」と呼ばれることがあるのです。

この記事では、この広大なエコシステムの根幹をなす「Spring Framework」の3つの柱、DI、AOP、Spring MVCの仕組みに焦点を当てて、その謎を解き明かしていきます。これを理解すれば、Spring Bootやその他のプロジェクトが、なぜあのように便利に動作するのかも自ずと見えてくるでしょう。

第2章: Springの心臓部 – IoCコンテナとDI（依存性の注入）

Springを理解する上で、避けては通れない最も重要な概念が「IoC (Inversion of Control: 制御の反転)」と「DI (Dependency Injection: 依存性の注入)」です。この章では、この2つの概念が何であり、なぜアプリケーション開発に革命をもたらしたのかを、図と共に徹底的に解説します。

2-1. そもそも「依存性」とは何か？

DIの「D」、すなわちDependency（依存性）とは何でしょうか。プログラミングにおいて、あるクラスが別のクラスの機能を利用するとき、そこには「依存関係」が生まれます。

例えば、ユーザー情報を扱うUserServiceが、データベースとやり取りするUserRepositoryを必要とするケースを考えてみましょう。従来の開発スタイルでは、次のように書くのが一般的でした。

【従来のコード例】
“`java
public class UserRepository {
// データベースからユーザー情報を取得するメソッド
public User findById(Long id) {
// … DBアクセス処理 …
System.out.println(“データベースからユーザーを取得しました。”);
return new User(id, “Taro Yamada”);
}
}

public class UserService {
// UserServiceがUserRepositoryを「直接」生成している
private UserRepository userRepository = new UserRepository();

public User findUser(Long id) {
    return userRepository.findById(id);
}

}

// 実行コード
public class Main {
public static void main(String[] args) {
UserService userService = new UserService();
User user = userService.findUser(1L);
System.out.println(user.getName()); // Taro Yamada
}
}
“`

このコードには、一見すると何の問題もないように見えます。しかし、ソフトウェアが大規模化・複雑化するにつれて、以下のような問題が顕在化します。

  1. 密結合 (Tight Coupling): UserServiceはUserRepositoryの実装と固く結びついています。もしUserRepositoryを、テスト用のダミーオブジェクト（モック）や、別のデータベース（例: MongoUserRepository）に差し替えたい場合、UserServiceのコード（new UserRepository()の部分）を直接修正する必要があります。これは変更に弱いことを意味します。
  2. テストの困難さ: UserServiceの単体テストを行いたいのに、UserRepositoryがデータベースに接続しようとするため、純粋なUserServiceのロジックだけをテストすることが困難です。テストのためにデータベースを起動しなければならなくなります。

これらの問題の根源は、「UserServiceが、自身が必要とするUserRepositoryオブジェクトの生成と管理を、自分自身で行ってしまっている」点にあります。

2-2. IoC (Inversion of Control: 制御の反転) とは？

ここで登場するのがIoC（制御の反転）という考え方です。
IoCとは、その名の通り「制御を反転させる」ことです。何と何の制御を反転させるのでしょうか？

それは、「オブジェクトの生成と管理のライフサイクルに関する制御」です。

従来の開発では、オブジェクト（UserService）が、自身が必要とする依存オブジェクト（UserRepository）の生成を能動的に制御していました。IoCの世界では、この制御を放棄し、その責任を外部の第三者（フレームワーク）に委ねます。オブジェクトは、自分が必要なものをただ待っているだけでよくなります。

“`mermaid
graph TD
subgraph 従来の開発 (開発者が制御)
A[UserService] — new UserRepository() –> B[UserRepositoryを生成];
A — 制御 –> B;
end

subgraph IoC (フレームワークが制御)
    C[IoCコンテナ] -- UserRepositoryを生成 --> D[UserRepository];
    C -- UserServiceを生成 --> E[UserService];
    C -- 依存関係を解決 --> E;
    E -- 制御される (受け身) --> D;
end

“`
【図2: 従来の開発 vs IoC】

図2が示すように、オブジェクトの生成とそれらの間の配線（依存関係の解決）という面倒な作業を、開発者に代わって行ってくれる存在。それがSpringにおける「IoCコンテナ」です。

2-3. DI (Dependency Injection: 依存性の注入) とは？

IoCは設計思想であり、その思想を実現するための具体的なテクニック（デザインパターン）がDI（依存性の注入）です。

DIとは、IoCコンテナが、あるオブジェクトが必要とする別のオブジェクト（依存性）を、外部から「注入（Injection）」してくれる仕組みのことです。先ほどのUserServiceを、DIを使って書き換えてみましょう。

【DIを使ったコード例 (コンストラクタインジェクション)】
“`java
// Springに管理を任せるBeanであることを示すアノテーション
@Component
public class UserRepository {
public User findById(Long id) {
// … DBアクセス処理 …
System.out.println(“データベースからユーザーを取得しました。”);
return new User(id, “Taro Yamada”);
}
}

@Component
public class UserService {
// final宣言して不変にすることが推奨される
private final UserRepository userRepository;

// コンストラクタで依存オブジェクトを受け取る
// @Autowiredはコンストラクタが1つの場合は省略可能
public UserService(UserRepository userRepository) {
    this.userRepository = userRepository;
}

public User findUser(Long id) {
    return userRepository.findById(id);
}

}
“`

注目すべきはUserServiceのコンストラクタです。new UserRepository()というコードはどこにもありません。代わりに、コンストラクタの引数でUserRepositoryを受け取っています。

一体誰が、このコンストラクタを呼び出し、UserRepositoryのインスタンスを渡してくれるのでしょうか？

答えは「IoCコンテナ」です。

SpringのIoCコンテナは、起動時に@Componentなどのアノテーションが付いたクラスを探し出し、それらのオブジェクトを生成して自身の内部で管理します。そして、UserServiceのオブジェクトを生成しようとしたとき、「お、このクラスはコンストラクタでUserRepositoryを欲しがっているな」と検知します。すると、コンテナは自身が管理しているUserRepositoryのオブジェクトを見つけ出し、それを引数としてコンストラクタに注入してくれるのです。

“`mermaid
graph LR
subgraph IoCコンテナ (ApplicationContext)
direction LR
BeanA[“UserRepository Bean”]
BeanB[“UserService Bean”]
end

IoCコンテナ -- "① UserRepositoryのインスタンスを生成" --> BeanA;
IoCコンテナ -- "② UserServiceのコンストラクタを呼び出す" --> BeanB;
BeanA -- "③ 引数として注入 (Inject)" --> BeanB;

“`
【図3: DIの仕組み（コンテナがオブジェクトを組み立てる様子）】

このように、依存性の解決を外部のコンテナに任せることで、UserServiceはUserRepositoryの具体的な実装から解放され、疎結合が実現します。テスト時には、本物のUserRepositoryの代わりに、テスト用のモックオブジェクトを簡単に注入できるようになり、テスト容易性が劇的に向上します。

DIには主に3つの方法があります。

  1. コンストラクタインジェクション（推奨）:

    • コンストラクタで依存性を注入する方法。
    • 依存関係が不変（finalを付けられる）になり、オブジェクトが生成された時点で必要なものがすべて揃っていることが保証されるため、最も推奨される方法です。

  2. セッターインジェクション:

    • セッターメソッド経由で依存性を注入する方法。
    • @Autowiredをセッターメソッドに付けます。
    • 依存関係がオプショナルである場合や、循環参照を解決するために使われることがあります。

  3. フィールドインジェクション:

    • フィールドに直接依存性を注入する方法。
    • @Autowiredをフィールドに直接付けます。
    • コードが簡潔になるためよく使われますが、DIコンテナなしではオブジェクトを生成できなくなる、フィールドが隠蔽されてしまうなどの理由から、一般的には非推奨とされています。

2-4. IoCコンテナの正体 – ApplicationContextとBeanFactory

Springのドキュメントを読んでいると、BeanFactoryやApplicationContextという言葉が出てきます。これらがIoCコンテナの本体です。

  • BeanFactory: DIの基本的な機能を提供する最もシンプルなコンテナです。Beanの生成と管理のコア機能を持っています。
  • ApplicationContext: BeanFactoryの全機能を引き継ぎ、さらに多くのエンタープライズ向け機能を追加した、より高機能なコンテナです。AOPの統合、メッセージリソースの処理、イベント発行メカニズムなど、私たちが普段Springアプリケーションで利用する機能のほとんどはApplicationContextによって提供されています。通常、私たちが「IoCコンテナ」と言うとき、それはApplicationContextを指します。

コンテナは、管理対象のオブジェクト（Beanと呼ばれます）のライフサイクル全体を管理します。

mermaid
graph TD
A[コンテナ起動] --> B{Bean定義の読み込み};
B -- @Component, @Configurationなど --> C[Beanインスタンス化];
C --> D[依存性の注入 (DI)];
D --> E[初期化コールバック実行<br>(@PostConstructなど)];
E --> F[Beanが使用可能な状態];
F --> G[コンテナ停止];
G --> H[破棄コールバック実行<br>(@PreDestroyなど)];
H --> I[Beanの破棄];
【図4: Beanのライフサイクル（概念図）】

2-5. Beanの定義方法 – @Component, @Service, @Repository, @Controller

では、どのようにしてクラスをコンテナの管理対象（Bean）として登録するのでしょうか。最も一般的なのは、クラスにステレオタイプアノテーションを付ける方法です。

  • @Component: 最も基本的なアノテーションで、「これはSpringが管理すべきコンポーネントです」と示す汎用的なマーカーです。
  • @Service: ビジネスロジック層のコンポーネントに付けるアノテーションです。機能的には@Componentと同じですが、開発者がコードの役割を理解しやすくするためのものです。
  • @Repository: データアクセス層（永続化層）のコンポーネントに付けるアノテーションです。これも機能的には@Componentとほぼ同じですが、特定のデータベース例外をSpringの統一的な例外（DataAccessException）に変換してくれるという追加機能があります。
  • @Controller: プレゼンテーション層（Web層）のコンポーネントに付けるアノテーションです。Spring MVCでリクエストを処理するコントローラークラスに使われます。

これらのアノテーションが付いたクラスを、Springは起動時にスキャン（コンポーネントスキャン）し、自動的にIoCコンテナにBeanとして登録します。

2-6. まとめ：DIがもたらす絶大なメリット

DIという仕組みは、私たちの書くコードに以下のような素晴らしいメリットをもたらします。

  • 疎結合: クラス間の依存関係が緩やかになり、一方の変更が他方に影響を与えにくくなります。
  • テスト容易性: 依存オブジェクトをモックに差し替えることが容易になり、テストの信頼性と効率が向上します。
  • 再利用性: 特定の実装に依存しないコンポーネントは、他の場所でも再利用しやすくなります。
  • 可読性と保守性: オブジェクトの生成と管理という「関心事」がコードから分離されるため、ビジネスロジックが明確になり、コードがクリーンに保たれます。

DIはSpring Frameworkの根幹をなす最も重要な概念です。この「依存性の管理を外部に委ねる」という発想が、次章で解説するAOPや、その先のSpring MVCの動作にも深く関わってきます。

第3章: Springのもう一つの柱 – AOP（アスペクト指向プログラミング）

DIがオブジェクト間の縦の依存関係を整理する技術だとすれば、AOP（Aspect-Oriented Programming: アスペクト指向プログラミング）は、アプリケーションの様々な場所に散らばる横断的な関心事を整理する技術です。これもまた、Springの「魔法」を解き明かす上で欠かせない重要な概念です。

3-1. なぜAOPが必要なのか？ – 横断的関心事の問題

アプリケーションを開発していると、複数の異なるモジュールやクラスに、同じような処理が繰り返し現れることがあります。例えば、以下のような処理です。

  • ロギング: メソッドの開始時と終了時にログを出力する。
  • トランザクション管理: メソッドの開始時にトランザクションを開始し、終了時にコミットまたはロールバックする。
  • セキュリティチェック: メソッドの実行前に、ユーザーが適切な権限を持っているかチェックする。
  • パフォーマンス計測: メソッドの実行時間を計測する。

これらの処理は、特定のビジネスロジック（例: ユーザー登録、商品検索）とは直接関係ありませんが、システムの品質を保つ上で不可欠です。このような、アプリケーションの様々な場所に横断的に現れる関心事を「横断的関心事 (Cross-Cutting Concerns)」と呼びます。

クラスA クラスB クラスC
+---------------------+ +---------------------+ +---------------------+
| | | | | |
| [ロギング処理] | | [ロギング処理] | | [ロギング処理] |
| [セキュリティ] | | [セキュリティ] | | [セキュリティ] |
| +-----------------+ | | +-----------------+ | | +-----------------+ |
| | メソッド1の | | | | メソッド2の | | | | メソッド3の | |
| | ビジネスロジック| | | | ビジネスロジック| | | | ビジネスロジック| |
| +-----------------+ | | +-----------------+ | | +-----------------+ |
| [トランザクション] | | [トランザクション] | | [トランザクション] |
| | | | | |
+---------------------+ +---------------------+ +---------------------+
【図5: 横断的関心事のイメージ図】

もしAOPがなければ、これらの横断的関心事をすべての必要なメソッドに手作業で記述しなければなりません。その結果、以下のような問題が発生します。

  • コードの重複: 同じようなコードがアプリケーションの至る所に散らばります。
  • 可読性の低下: 本来のビジネスロジックが、横断的関心事のコードに埋もれてしまい、読みにくくなります。
  • 保守性の悪化: ロギングの仕様を変更したい場合、関係するすべての箇所を修正する必要があり、修正漏れのリスクが高まります。

AOPは、この問題をエレガントに解決します。

3-2. AOPとは何か？

AOPとは、これらの横断的関心事を、本来のビジネスロジックから分離し、独立したモジュールとして定義・管理するプログラミング手法です。分離された横断的関心事を「アスペクト (Aspect)」と呼びます。

AOPを使うと、ビジネスロジックを実装するクラスは、自身の本来の責務に集中できます。ロギングやトランザクション管理といった処理は、アスペクトとして一箇所にまとめて定義します。そして、フレームワークが実行時に、定義されたアスペクトを適切な場所（メソッド呼び出しの前後など）に動的に織り込んで（Weaving）くれます。

これにより、ビジネスロジックのコードはクリーンなままで、必要な機能を追加できるのです。

3-3. AOPの主要な用語を図解で理解する

AOPを理解するには、いくつかの専門用語に慣れる必要があります。これらは一見難しそうですが、関係性を図で捉えれば怖くありません。

  • Aspect (アスペクト): 横断的関心事をカプセル化したモジュール。Springでは@Aspectアノテーションを付けたクラスがこれに当たります。アスペクトは、複数のアドバイスとポイントカットを含みます。
  • Join Point (ジョインポイント): 「結合点」。アドバイスを適用できるプログラムの実行地点のこと。メソッドの実行、例外のスロー、フィールドの変更など、様々なジョインポイントが存在しますが、Spring AOPでは、現実的にメソッドの実行が唯一のジョインポイントです。
  • Advice (アドバイス): アスペクトが実行する具体的な処理そのもの（例: ロギング処理）。アドバイスは、ジョインポイントのどのタイミングで実行されるかによって、いくつかの種類があります。
    • @Before: ジョインポイント（メソッド）の実行前に実行。
    • @After: ジョインポイントの実行後に実行（成功しようが例外で終わろうが必ず実行）。
    • @AfterReturning: ジョインポイントが正常に終了した後に実行。
    • @AfterThrowing: ジョインポイントが例外をスローした後に実行。
    • @Around: ジョインポイントの実行を前後から挟み込むように実行。メソッドの実行を制御したり、引数や戻り値を変更したりできる最も強力なアドバイス。
  • Pointcut (ポイントカット): 「切断点」。数あるジョインポイントの中から、どのアドバイスをどこに適用するかを定義するための式（セレクタ）です。例えば、「com.example.serviceパッケージ内の、すべてのpublicメソッド」のように指定します。
  • Target Object (ターゲットオブジェクト): アドバイスを適用される側のオブジェクト。本来のビジネスロジックを持つPOJOです。（例: UserService）
  • Proxy (プロキシ): AOPが適用された後のオブジェクトのこと。Springは、ターゲットオブジェクトをラップするプロキシオブジェクトを動的に生成し、IoCコンテナにはこのプロキシが格納されます。

これらの関係性を図で見てみましょう。

“`mermaid
graph TD
subgraph Aspect[“Aspect (@Aspect)”]
direction LR
A[Advice
@Before, @Around etc.]
P[Pointcut
“execution(…)”]
end

subgraph Client
    C[呼び出し元コード]
end

subgraph "IoC Container"
    Proxy["Proxy (AOP適用後)"]
end

Target["Target Object<br>(UserServiceなど)"]

P -- "どこに？" --> Target
A -- "何を？" --> Target

C -- "呼び出し" --> Proxy
Proxy -- "1. Advice(Before)実行" --> A
Proxy -- "2. 本来のメソッド呼び出し" --> Target
Target -- "処理結果" --> Proxy
Proxy -- "3. Advice(After)実行" --> A
Proxy -- "レスポンス" --> C

“`
【図6: AOP用語の関係図と動作イメージ】

3-4. Spring AOPの仕組み – 動的プロキシ

では、SpringはどのようにしてこのAOPを実現しているのでしょうか。その鍵を握るのが「動的プロキシ (Dynamic Proxy)」です。

Spring AOPは、コンパイル時にコードを書き換えるのではなく、実行時にAOPを適用します。IoCコンテナがBeanを生成する際、AOPの適用対象となるBean（ターゲットオブジェクト）を見つけると、そのターゲットオブジェクトを直接コンテナに登録する代わりに、ターゲットオブジェクトを内包した「プロキシオブジェクト」を動的に生成し、コンテナに登録します。

アプリケーションの他の部分（例えばControllerからServiceを呼び出す場合）がそのBeanをDIで受け取るとき、実際に注入されるのはこのプロキシオブジェクトです。

“`mermaid
graph TD
Client[Controllerなど] — “userService.doSomething()” –> Proxy[UserServiceプロキシ];

subgraph Proxy
    direction TB
    Before[Before Advice];
    TargetCall["Target (UserService) の<br>doSomething() を呼び出す"];
    After[After Advice];

    Before --> TargetCall;
    TargetCall --> After;
end

Proxy -- "内部でラップしている" --> Target[本物のUserServiceオブジェクト];

“`
【図7: AOPの動作フロー（プロキシによる処理の流れ）】

  1. クライアントコードがプロキシオブジェクトのメソッドを呼び出します。
  2. プロキシは、呼び出されたメソッドがポイントカットの条件に一致するかどうかをチェックします。
  3. 一致する場合、プロキシは定義されたアドバイス（例: @Beforeのアドバイス）を実行します。
  4. アドバイスの実行後、プロキシは内部に保持している本物のターゲットオブジェクトのメソッドを呼び出します。
  5. ターゲットオブジェクトのメソッドが終了すると、プロキシは再び制御を取り戻し、次のアドバイス（例: @AfterReturningのアドバイス）を実行します。
  6. 最後に、プロキシはメソッドの実行結果をクライアントコードに返します。

このように、クライアントコードやターゲットオブジェクトは、プロキシやアスペクトの存在を一切意識する必要がありません。これがSpring AOPの強力さの秘密です。
（補足: Springは、ターゲットがインターフェースを実装している場合はJava標準のJDK Dynamic Proxyを、実装していない場合はCGLIBというライブラリを使ってサブクラスを生成する形でプロキシを作成します。）

3-5. AOPの具体例 – メソッド実行時間の計測

言葉だけでは分かりにくいので、@Aroundアドバイスを使ってメソッドの実行時間を計測する簡単なアスペクトのコード例を見てみましょう。

“`java
// アスペクトを定義するクラス
@Aspect
@Component
public class PerformanceLoggingAspect {

// ポイントカットの定義: com.example.serviceパッケージ以下の全クラスの全メソッドを対象
@Pointcut("execution(* com.example.service..*.*(..))")
private void serviceLayer() {}

// Aroundアドバイスを定義
@Around("serviceLayer()")
public Object logPerformance(ProceedingJoinPoint joinPoint) throws Throwable {
    long startTime = System.currentTimeMillis();

    // ターゲットメソッドの実行
    Object result = joinPoint.proceed();

    long endTime = System.currentTimeMillis();

    System.out.println(
        joinPoint.getSignature() + " executed in " + (endTime - startTime) + "ms"
    );

    return result;
}

}

// ターゲットとなるサービスクラス
@Service
public class MyService {
public void doSomething() {
// 何らかの重い処理
try {
Thread.sleep(100);
} catch (InterruptedException e) {
// …
}
System.out.println(“ビジネスロジックを実行中…”);
}
}
``
このMyServiceのdoSomething()`メソッドを呼び出すだけで、コンソールには自動的に次のようなログが出力されます。

ビジネスロジックを実行中...
void com.example.service.MyService.doSomething() executed in 102ms

MyServiceクラスには、時間計測のコードは一切ありません。ビジネスロジックとパフォーマンス計測という横断的関心事が、AOPによって美しく分離されていることが分かります。Springの@Transactionalアノテーションなども、このAOPの仕組みを利用して実現されています。

3-6. まとめ：AOPがもたらす美しさ

AOPは、一見すると複雑に見えるかもしれませんが、その目的は非常にシンプルです。

  • 関心の分離: アプリケーションのコアな関心事（ビジネスロジック）と、横断的な関心事を分離する。
  • コードのクリーン化: ビジネスロジックのクラスから、定型的なコードを排除し、本来の責務に集中させる。
  • 保守性の向上: 横断的関心事の変更が必要になった場合、アスペクトクラスを修正するだけで済み、影響範囲を最小限に抑えられる。

DIとAOP。この2つの強力な柱を理解すれば、Spring Frameworkの半分以上を理解したと言っても過言ではありません。次の章では、これらの仕組みを土台として構築されたWebフレームワーク、Spring MVCの内部を探っていきます。

第4章: Webアプリケーションの骨格 – Spring MVC

DIとAOPという強力な基盤の上に、SpringはWebアプリケーションを構築するための包括的なフレームワークを提供しています。それがSpring MVCです。Spring Bootの登場により、私たちは複雑な設定を意識することなくWebアプリケーションを開発できるようになりましたが、その裏側では、今も変わらずこのSpring MVCの洗練されたアーキテクチャが動いています。ここでは、ブラウザからのリクエストがどのように処理され、レスポンスが返されるのか、その一連の流れを解剖していきます。

4-1. MVCモデルとは？

まず基本として、MVCモデルについて簡単におさらいしましょう。MVCは、アプリケーションのUI部分を3つの役割に分割する設計パターンです。

  • Model: アプリケーションのデータとビジネスロジックを扱う部分。ViewやControllerに依存しない、純粋なドメインオブジェクトやサービス層がこれに当たります。
  • View: ユーザーに表示されるUI部分。HTML、JSP、Thymeleafテンプレートなどが該当します。Modelのデータを参照して、最終的な表示を生成します。
  • Controller: ユーザーからの入力（リクエスト）を受け取り、Modelを操作し、表示すべきViewを決定する役割を担います。ModelとViewの間の橋渡し役です。

Spring MVCは、この古典的なMVCパターンを、Webアプリケーションに適用するためのフレームワークです。

4-2. Spring MVCの心臓部 – DispatcherServlet

Spring MVCのアーキテクチャの中心には、DispatcherServlet という名のサーブレットが存在します。これは、デザインパターンでいう「フロントコントローラーパターン」を実装したものです。

Webアプリケーションに送られてくるすべてのリクエストは、まず最初にこのDispatcherServletがたった一人で受け取ります。 DispatcherServletは司令塔のような役割を担い、自身でリクエストを直接処理するのではなく、リクエストの内容に応じて、様々な専門コンポーネントに処理をディスパッチ（委譲）していきます。このDispatcherServletを中心とした連携プレイこそが、Spring MVCの処理フローの核心です。

4-3. リクエスト処理の全体フローを図解

それでは、ユーザーがブラウザでURLにアクセスしてから、HTMLが画面に表示されるまでの詳細な流れを、シーケンス図を使って見ていきましょう。

“`mermaid
sequenceDiagram
participant Client as クライアント
(ブラウザ)
participant DS as DispatcherServlet
(司令塔)
participant HM as HandlerMapping
(ハンドラマッパー)
participant HA as HandlerAdapter
(ハンドラアダプター)
participant C as Controller
(ハンドラ)
participant VR as ViewResolver
(ビューリゾルバ)
participant V as View
(JSP, Thymeleafなど)

Client ->>+ DS: 1. HTTPリクエスト
DS ->>+ HM: 2. このリクエストを<br>処理できるハンドラはどれ？
HM -->>- DS: 3. Controllerの<br>hoge()メソッドです

DS ->>+ HA: 4. このハンドラ(hoge())を<br>実行できるアダプタはどれ？<br>実行して！
HA ->>+ C: 5. hoge()メソッドを実行
Note right of C: ビジネスロジック実行<br>Modelにデータを格納<br>View名を返す
C -->>- HA: 6. ModelとView名("user/detail")を返す
HA -->>- DS: 7. 処理結果(ModelAndView)を返す

DS ->>+ VR: 8. View名("user/detail")に対応する<br>Viewオブジェクトはどれ？
VR -->>- DS: 9. ThymeleafViewオブジェクトです

DS ->>+ V: 10. Modelデータを使って<br>HTMLをレンダリングして！
V -->>- DS: 11. レンダリング結果(HTML)を返す

DS -->>- Client: 12. HTTPレスポンス

“`
【図8: Spring MVCのリクエスト処理フロー】

この一連の流れを、各ステップで詳しく見ていきましょう。

  1. リクエスト受信: クライアント（ブラウザ）からリクエスト（例: /users/1）が送られると、WebサーバーはそれをDispatcherServletに渡します。

  2. ハンドラマッピング (HandlerMapping): DispatcherServletは、まずHandlerMappingに問い合わせます。「このリクエストURL (/users/1) を処理するのは、どのコントローラーのどのメソッド（これをハンドラと呼びます）ですか？」と。HandlerMappingは、@RequestMappingや@GetMappingなどのアノテーション情報を元に、リクエストに最適なハンドラ（例: UserControllerのgetUser()メソッド）を見つけ出し、DispatcherServletに返します。

  3. ハンドラアダプタの検索・実行 (HandlerAdapter): DispatcherServletは、見つかったハンドラを直接実行するわけではありません。次にHandlerAdapterに「このハンドラを実行してください」と依頼します。なぜこのようなワンクッションを挟むかというと、ハンドラの形式が多様である可能性があるためです。HandlerAdapterは、様々な種類のハンドラを統一的なインターフェースで実行するための「アダプター」の役割を果たします。

  4. コントローラーの実行 (Controller): HandlerAdapterは、特定されたコントローラーのメソッドを、リクエストパラメータ（@RequestParam, @PathVariable, @RequestBodyなど）を適切に解決しながら実行します。コントローラーは、必要に応じてサービスクラスを呼び出してビジネスロジックを実行し、その結果をModelオブジェクトに格納します。そして、次に表示すべき画面の論理的な名前（論理ビュー名、例: "user/detail"）を返します。このModelと論理ビュー名をまとめたものがModelAndViewオブジェクトです。

  5. ビューの解決 (ViewResolver): コントローラーからModelAndViewを受け取ったDispatcherServletは、次にViewResolverに問い合わせます。「この論理ビュー名 ("user/detail") に対応する、実際のViewはどれですか？」と。ViewResolverは、設定（例: spring.thymeleaf.prefix=/templates/, spring.thymeleaf.suffix=.html）に基づいて、物理的なビューの場所（例: /templates/user/detail.html）を特定し、そのビューをレンダリングするためのViewオブジェクト（例: ThymeleafView）を生成して返します。

  6. ビューのレンダリング (View): DispatcherServletは、最後にViewオブジェクトにレンダリングを依頼します。「このModelのデータを使って、レスポンスを生成してください」と。Viewオブジェクト（例: Thymeleafエンジン）は、Modelのデータをテンプレートファイルに埋め込み、最終的なHTMLを生成します。

  7. レスポンス返却: 生成されたHTMLがDispatcherServlet経由でクライアントに返却され、ブラウザに画面が表示されます。

これがSpring MVCにおけるリクエスト処理の王道パターンです。最近のAPI開発でよく使われる@RestControllerや@ResponseBodyは、このフローの一部をショートカットします。これらが付いたメソッドが値を返すと、ViewResolverやViewの処理はスキップされ、戻り値が直接JSONなどの形式に変換されてレスポンスボディとして返されます。しかし、その場合でもDispatcherServlet、HandlerMapping、HandlerAdapterは同様に動作しています。

4-4. Spring Bootの登場による変化

Spring Boot登場以前は、このDispatcherServletやHandlerMapping、ViewResolverといったコンポーネントを、すべてweb.xmlやJavaConfigクラスに手動でBean登録する必要があり、非常に手間がかかりました。

Spring Bootは、クラスパス上にSpring MVC関連のライブラリ（spring-boot-starter-web）が存在することを検知すると、これらすべてのコンポーネントを、最も一般的で最適な設定で自動的にセットアップしてくれます。 これが、私たちが設定をほとんど書かなくてもSpring MVCが「魔法のように」動く理由です。

しかし、重要なのは、Spring Bootは魔法で動いているのではなく、このSpring MVCの洗練されたアーキテクチャを自動設定してくれているだけだということです。この内部フローを理解していれば、リクエストが期待通りに処理されない場合や、より高度なカスタマイズが必要になった場合に、どこを調査・変更すればよいのかが明確になります。

第5章: まとめ – Spring Frameworkを使いこなすために

長い旅路でしたが、これで私たちはSpring Frameworkという巨大な山の、3つの主要な登山ルートを踏破しました。

  1. DI（依存性の注入）: オブジェクトの生成と管理をコンテナに委ね、クラス間の依存関係を疎にする、Springの土台となる考え方。
  2. AOP（アスペクト指向プログラミング）: ロギングやトランザクションといった横断的関心事をビジネスロジックから分離し、プロキシを用いて動的に織り込む技術。
  3. Spring MVC: DispatcherServletを司令塔として、リクエストを複数のコンポーネントに委譲しながら処理する、柔軟で拡張性の高いWebフレームワーク。

これらは決して独立した概念ではなく、互いに深く関連し合っています。DispatcherServletも、HandlerMappingも、そして私たちが作るControllerやServiceも、すべてはDIコンテナによって管理されるBeanです。そして、@Transactionalのような便利な機能は、AOPの仕組みを使って、私たちのビジネスロジックに適用されています。

もう、Springはあなたにとって「魔法」ではないはずです。そこには、複雑な問題を解決するための、明確で合理的な「仕組み」が存在します。この仕組みを理解することは、単に知識が増えるということ以上の意味を持ちます。

  • 問題解決能力の向上: エラーメッセージが何を意味しているのか、どのコンポーネントが関係しているのかを推測できるようになります。
  • 設計能力の向上: Springの思想を理解することで、より疎結合でテストしやすく、保守性の高いアプリケーションを設計できるようになります。
  • 自信と楽しさ: 「なぜ動くのか」を知っているという自信は、プログラミングをより楽しく、創造的な活動にしてくれます。

この記事は、あなたのSpring学習における出発点です。ここからさらに、Spring Bootの便利な自動設定の裏側、Spring Data JPAによるデータアクセスの簡素化、Spring Securityによる堅牢な認証・認可の仕組みへと、学びを広げていってください。そのすべての根底には、今日学んだDIとAOPの思想が流れています。

Spring Frameworkは、確かに巨大で学ぶべきことは多いですが、その核心にある設計思想は驚くほど一貫しており、エレガントです。この地図を手に、自信を持ってSpringの世界を探求し続けてください。あなたのエンジニアとしての道が、より確かなものになることを願っています。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール