Spring Web MVC はこれで十分だと認識しています

バージョン 5.3.30-SNAPSHOThttps://docs.spring.io/spring-framework/docs/5.3.30-SNAPSHOT/reference/html/web.html# mvc-サーブレット構成

Spring Web MVC は、Servlet API をベースにしたオリジナルの Web フレームワークであり、最初から Spring フレームワークに含まれています。正式名「Spring Web MVC」はソースモジュールの名前 (Spring -webmvc) に由来していますが、より一般的な名前は「Spring MVC」です。

Spring Web MVC と並行して、Spring Framework 5.0 ではリアクティブスタック Web フレームワークが導入されています。その名前「Spring WebFlux」もソースモジュール (Spring - WebFlux) に基づいています。

Spring Web MVC について詳しく説明する前に、MVC パターンとフロントエンドコントローラーパターンという 2 つの概念を理解する必要があります。

-1MVCモード

MVC はソフトウェア設計パターンです。 MVC パターンは、Model-View-Controller パターンの略です。このパターンは、アプリケーションの階層化開発に使用されます。

モデル - モデルは、データにアクセスするオブジェクトまたは JAVA POJO を表します。データが変更されたときにコントローラーを更新するロジックを含めることもできます。
ビュー - ビューは、モデルに含まれるデータの視覚化を表します。
コントローラ - コントローラはモデルとビューに作用します。モデルオブジェクトへのデータフローを制御し、データが変更されたときにビューを更新します。ビューをモデルから分離します。

ここに画像の説明を挿入します

-1.1 実装

Car モデルオブジェクトを作成します。CarView は、コンソールに Car 情報を出力するビュークラスです。CarController は、モデルデータをコントローラークラスに保存し、対応するモデル情報を CarView ビューに更新します。

車

package com.example.demo.mvc;

/**
 * @Author yrz
 * @create 2023/7/27 14:10
 * @Description TODO
 */

public class Car {
    public Car() {
    }

    public Car(String plateNo, String color) {
        this.plateNo = plateNo;
        this.color = color;
    }

    /**
     * 车牌
     */
    private String plateNo;
    /**
     * 车颜色
     */
    private String color;

    public String getPlateNo() {
        return plateNo;
    }

    public void setPlateNo(String plateNo) {
        this.plateNo = plateNo;
    }

    public String getColor() {
        return color;
    }

    public void setColor(String color) {
        this.color = color;
    }
}

カービュー

package com.example.demo.mvc;

/**
 * @Author yrz
 * @create 2023/7/27 14:14
 * @Description TODO
 */

public class CarView {
    public void printCarInfo(Car car){
        System.out.println(car.getPlateNo() + " " + car.getColor());
    }
}

カーコントローラー

package com.example.demo.mvc;

/**
 * @Author yrz
 * @create 2023/7/27 14:16
 * @Description TODO
 */

public class CarController {
    private Car car;
    private CarView carView;

    public CarController(Car car, CarView carView) {
        this.car = car;
        this.carView = carView;
    }

    public void setCarPlateNo(String plateNo){
        car.setPlateNo(plateNo);
    }

    public void setCarColor(String color){
        car.setColor(color);
    }

    public void updateCarView(){
        carView.printCarInfo(car);
    }
}

MVCPパターンデモ

package com.example.demo.mvc;

/**
 * @Author yrz
 * @create 2023/7/27 14:19
 * @Description TODO
 */

public class MVCPatternDemo {
    public static void main(String[] args) {
        Car car = new Car("冀E6666", "红色");
        CarView carView = new CarView();
        CarController carController = new CarController(car, carView);
        carController.updateCarView();
        car.setColor("蓝色");
        carController.updateCarView();
    }
}

-1.2 分業

MVC フレームワークに基づく一般的な B/S アーキテクチャアプリケーションソフトウェアでは、フロントエンド (クライアント側) とバックエンド (サーバー側) が異なるタスクと責任を負います。

フロントエンド (クライアント) は主に次の側面を担当します。

ビュー: フロントエンドは、UI のレイアウト、スタイル、インタラクションなどのユーザーインターフェイスの作成とレンダリングを担当します。ユーザーにデータを表示し、ユーザーからの入力を受け取る役割を果たします。

ユーザーインタラクション: フロントエンドは、ユーザーのクリック、入力、操作の受信、それに応じたビューの更新など、ユーザー入力とインタラクションを処理します。

バックエンド (サーバー側) は主に次の側面を担当します。

モデル: バックエンドは、データベースやその他の永続ストレージとの対話を含む、ビジネスロジックとデータの永続性の処理を担当します。データの構造とルールを定義し、データに対する CRUD (作成、読み取り、更新、削除) 操作を提供します。
コントローラー (Controller): バックエンドはビジネスロジックの制御と処理を担当し、ユーザーの要求に応じて対応する処理を実行します。フロントエンドからリクエストを受け取り、リクエストを処理してモデルを操作し、結果をフロントエンドに返します。
データのストレージと管理: バックエンドは、データの読み取り、書き込み、変更、削除など、永続ストレージ (データベースなど) とのやり取りを担当します。また、データをキャッシュしてパフォーマンスを向上させ、同時アクセスやセキュリティなどの問題を処理することもできます。
一般に、MVC フレームワークでは、フロントエンドがユーザーインターフェイスの表示とユーザーインタラクションの処理を担当し、バックエンドがビジネスロジックの処理とデータストレージを担当します。フロントエンドとバックエンドは、明確に定義されたインターフェイスとプロトコルを通じて通信します。フロントエンドは、ユーザーのリクエストを処理のためにバックエンドに送信し、バックエンドから返されたデータと結果を受信して、完全なアプリケーションを実装します。。

0フロントエンドコントローラーモード

フロントコントローラーパターンは、Web アプリケーションのリクエスト処理フローを構築するために使用されるソフトウェア設計パターンです。これは、すべてのリクエストを集中的に処理し、リクエストのタイプと内容に基づいて対応するハンドラーをスケジュールするための集中コンポーネントであるフロントエンドコントローラーを提供します。

フロントエンドコントローラーモードでは、すべてのリクエストは最初にフロントエンドコントローラーを通過し、次に要求された情報に基づいて適切なハンドラーに分配され、実際の処理ロジックが実行されます。この集中リクエスト処理により、次のような利点が得られます。

集中リクエスト処理: フロントエンドコントローラーはアプリケーションのエントリポイントとして機能し、すべてのリクエストの受信と処理を担当します。この集中処理方法により、リクエストの分散と処理のロジックが簡素化され、コードの保守性と再利用性が向上します。
統合リクエスト処理: フロントエンドコントローラーを通じて、リクエストの統合処理を実現できます。たとえば、認証、リクエストのログ記録、例外処理などの一般的な処理ステップをフロントコントローラーに実装して、各ハンドラーで同じコードを繰り返し記述することを回避できます。
多様なリクエスト処理戦略のサポート: フロントエンドコントローラーは、リクエストのタイプ、コンテンツ、またはその他の識別情報に基づいて、適切なハンドラーを動的に選択できます。この柔軟性により、システムはさまざまな要求要件に応じて処理をカスタマイズでき、システムの拡張性と適応性が向上します。
複雑なリクエストの分散とルーティングをサポートします。フロントエンドコントローラーは、リクエストのルーティング情報に基づいて、リクエストをさまざまなハンドラーに分散できます。この柔軟なリクエスト分散メカニズムは、URL、リクエストパラメータ、リクエストヘッダーなどに基づくルーティングと分散など、複雑なリクエストルーティング戦略をサポートできます。

要約すると、フロントエンドコントローラーパターンは、集中フロントエンドコントローラーコンポーネントを導入してリクエストの分散と処理を 1 か所で集中化することにより、Web アプリケーションを処理および管理するための構造化されたスケーラブルな方法を提供します。コード構造を簡素化し、コードの再利用性を向上させ、柔軟なリクエスト処理戦略をサポートできます。

フロントコントローラーパターンは、集中リクエスト処理メカニズムを提供するために使用され、すべてのリクエストは単一のハンドラーによって処理されます。ハンドラーは、認証/認可/ロギングを実行したり、リクエストを追跡したりして、そのリクエストを適切なハンドラーに渡すことができます。このデザインパターンの実体は以下の通りです。

フロントコントローラ - Web ベースのアプリケーションかデスクトップベースのアプリケーションプログラムかを問わず、アプリケーションに対するあらゆる種類のリクエストを処理する単一のハンドラ。
ディスパッチャー - フロントコントローラーはディスパッチャーオブジェクトを使用して、リクエストを対応する特定のハンドラーにディスパッチできます。
ビュー - ビューはリクエストに対して作成されるオブジェクトです。

フロントエンドコントローラー + スケジューラー = MVC のコントローラー

0.1実装

Front としてFrontController と Dispatcher をそれぞれ作成します。 -end コントローラーとスケジューラー。 HomeView と StudentView は、フロントコントローラーによって受信されるさまざまなリクエストとビューを表します。作成した。

FrontControllerPatternDemo のデモクラスは、FrontController を使用してフロントコントローラーの設計パターンを示します。

ここに画像の説明を挿入します

ホームビュー

public class HomeView {
   public void show(){
      System.out.println("Displaying Home Page");
   }
}

StudentView

public class StudentView {
   public void show(){
      System.out.println("Displaying Student Page");
   }
}

発車係

public class Dispatcher {
   private StudentView studentView;
   private HomeView homeView;
   public Dispatcher(){
      studentView = new StudentView();
      homeView = new HomeView();
   }
 
   public void dispatch(String request){
      if(request.equalsIgnoreCase("STUDENT")){
         studentView.show();
      }else{
         homeView.show();
      }  
   }
}

フロントコントローラー

public class FrontController {
   
   private Dispatcher dispatcher;
 
   public FrontController(){
      dispatcher = new Dispatcher();
   }
 
   private boolean isAuthenticUser(){
      System.out.println("User is authenticated successfully.");
      return true;
   }
 
   private void trackRequest(String request){
      System.out.println("Page requested: " + request);
   }
 
   public void dispatchRequest(String request){
      //记录每一个请求
      trackRequest(request);
      //对用户进行身份验证
      if(isAuthenticUser()){
         dispatcher.dispatch(request);
      }  
   }
}

フロントコントローラーパターンデモ

public class FrontControllerPatternDemo {
   public static void main(String[] args) {
      FrontController frontController = new FrontController();
      frontController.dispatchRequest("HOME");
      frontController.dispatchRequest("STUDENT");
   }
}

1サーブレットAPI

サーブレット: (特に Java 言語で) サーバー上で実行される小さなアプリケーション、小さなサービスプログラム

サーブレット API は、Java ベースの Web アプリケーションを開発するための標準 API (https://jakarta.ee/specations/servlet/) です。 HTTP リクエストとレスポンスを処理するための一連のインターフェイスとクラスを提供し、動的でスケーラブルな Web アプリケーションの開発を可能にします。一般的に使用されるサーブレット API インターフェイスとクラスの一部を次に示します。

javax.servlet.Servlet: すべてのサーブレットクラスが実装する必要があるインターフェイス。サーブレットのライフサイクルメソッドとサービスメソッドを定義します。
javax.servlet.http.HttpServlet: Servlet インターフェイスから継承された HttpServlet クラスは、doGet()、doPost() 待ってください。
javax.servlet.ServletConfig：サーブレットの初期化パラメータなどの設定情報を示します。
javax.servlet.ServletContext: サーブレットのコンテキストを表し、サーブレットに共有リソースと情報を提供します。
javax.servlet.http.HttpServletRequest: リクエスト URI、リクエストパラメータ、リクエストヘッダーなどのクライアントの HTTP リクエスト情報をカプセル化します。
javax.servlet.http.HttpServletResponse: クライアントに送信される HTTP 応答情報 (応答ステータスコード、応答ヘッダー、出力ストリームなど) をカプセル化します。
javax.servlet.http.HttpSession: クライアントとサーバー間のセッションステータスを追跡し、ユーザー関連のデータを保存するために使用されます。
javax.servlet.RequestDispatcher: リクエストを他のサーブレットまたは JSP ページに転送して処理するために使用されます。
javax.servlet.Filter: リクエストがサーブレットに到達する前、またはレスポンスがクライアントに返される前に、リクエストとレスポンスの前処理および後処理に使用されます。
javax.servlet.annotation.WebServlet: アノテーションを通じてサーブレットを構成するために使用されます。

上記はサーブレット API のインターフェイスとクラスの一部にすぎません。サーブレット API には、セッション管理、Cookie、ファイルのアップロードとダウンロード、非同期処理などを処理するための他の多くのインターフェイスとクラスも含まれています。これらのインターフェイスとクラスは、Web アプリケーションの構築に必要なコア機能を提供します。

2Dispatcherサーブレット

他の多くの Web フレームワークと同様に、Spring MVC はフロントコントローラーパターンを中心に設計されており、中央の Servlet DispatcherServlet がリクエスト処理用の共有アルゴリズムを提供し、実際の作業は構成可能なデリゲートコンポーネントによって実行されます。このモデルは柔軟性があり、さまざまなワークフローをサポートします。

DispatcherServlet は、他のサーブレットと同様、Java 構成または web.xml を使用して、サーブレット仕様に従って宣言およびマップする必要があります。次に、DispatcherServlet は Spring 構成を使用して、リクエストマッピング、ビュー解決、例外処理などに必要なデリゲートコンポーネントを検出します。

2.1 DispatcherServlet のカスタマイズ

次の Java 構成例では、サーブレットコンテナによって自動的に検出される DispatcherServlet を登録して初期化します。

public class MyWebApplicationInitializer implements WebApplicationInitializer {

    @Override
    public void onStartup(ServletContext servletContext) {

        // Load Spring web application configuration
        AnnotationConfigWebApplicationContext context = new AnnotationConfigWebApplicationContext();
        context.register(AppConfig.class);

        // Create and register the DispatcherServlet
        DispatcherServlet servlet = new DispatcherServlet(context);
        ServletRegistration.Dynamic registration = servletContext.addServlet("app", servlet);
        registration.setLoadOnStartup(1);
        registration.addMapping("/app/*");
    }
}

このコードは、WebApplicationInitializer インターフェイスを実装する一般的なクラスです。これは、Spring Web ベースのアプリケーションを構成および初期化するために使用されます。

onStartup メソッドでは、主に次のタスクが実行されます。

Spring Web アプリケーションの構成クラスを作成して登録する: AnnotationConfigWebApplicationContext オブジェクトを作成し、アプリケーションの構成クラスを登録することで Spring に通知しますAppConfig.class Web の構成とアプリケーションの関連コンポーネントをアセンブルします。
DispatcherServlet の作成と登録: DispatcherServlet オブジェクトを作成し、以前に作成した AnnotationConfigWebApplicationContext オブジェクトをパラメータとして渡します。 DispatcherServlet は、すべてのリクエストを受信して処理するコアコントローラーです。次に、 servletContext オブジェクトの addServlet メソッドを使用して DispatcherServlet を登録し、サーブレット名を「app」として指定し、そのサーブレット名を設定します。読み込み順は1です。
DispatcherServlet の URL マッピングルールを設定します。registration オブジェクトの addMapping メソッドを呼び出して、「/」を変更します。 app/* ” この URL パターンは、作成したばかりの DispatcherServlet にマッピングされます。これは、「/app」で始まるすべてのリクエストがこの DispatcherServlet によって処理されることを意味します。

上記のコードは、Spring Web アプリケーションの初期化と構成に使用されます。 WebApplicationInitializer の実装クラスを通じて、アプリケーションの起動動作をカスタマイズし、Spring 構成のロード、サーブレットの登録、URL マッピングの設定など、必要に応じてさまざまな構成操作を実行できます。この方法は、web.xml 構成に基づく従来の方法よりも柔軟性が高く、拡張が簡単です。

上記のコードでは、AppConfig は、Spring Web アプリケーションの関連コンポーネントを構成およびアセンブルするために使用されるアプリケーション構成クラスです。具体的には、 AppConfig クラスは通常、 @Configuration アノテーションでマークされており、Bean、インターセプタ、ビューリゾルバなどを定義するために他のアノテーションを使用する場合があります。

以下は、AppConfig クラスの実装例です。

@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "com.example")
public class AppConfig implements WebMvcConfigurer {
    
    

    // 配置视图解析器
    @Bean
    public ViewResolver viewResolver() {
    
    
        InternalResourceViewResolver viewResolver = new InternalResourceViewResolver();
        viewResolver.setPrefix("/WEB-INF/views/");
        viewResolver.setSuffix(".jsp");
        return viewResolver;
    }

    // 配置静态资源
    @Override
    public void configureDefaultServletHandling(DefaultServletHandlerConfigurer configurer) {
    
    
        configurer.enable();
    }

    // 配置拦截器
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
    
    
        registry.addInterceptor(new MyInterceptor());
    }

    // 配置请求处理器
    @Override
    public void addViewControllers(ViewControllerRegistry registry) {
    
    
        registry.addViewController("/").setViewName("index");
        registry.addViewController("/about").setViewName("about");
    }
    
    // ...
}

この例では、AppConfig クラスは @Configuration アノテーションを使用して、それが構成クラスであることを示します。アノテーション @EnableWebMvc により、Spring MVC の自動構成が有効になり、いくつかのカスタム構成を実行することもできます。

AppConfig では、ビューリゾルバー、インターセプターなどのさまざまな Bean を定義できます。この例では、viewResolver メソッドを通じてビューパーサーが定義され、ビューファイルのプレフィックスとサフィックスが設定されます。 configureDefaultServletHandling メソッドは、静的リソースを処理するためのデフォルトのプロセッサを構成するために使用されます。 addInterceptors メソッドはインターセプタを追加するために使用されます。 addViewControllers メソッドは、特定の URL リクエストを処理する単純なリクエストハンドラを定義するために使用されます。

もちろん、実際の開発では、AppConfig クラスの具体的な実装はプロジェクトの要件に応じて異なる場合があります。他の Bean の定義、データソース、トランザクションの構成など、プロジェクトの特定の条件に従って AppConfig クラスのコンテンツをカスタマイズできます。

簡単に言うと、AppConfig このクラスの役割は、Spring Web アプリケーションの関連コンポーネントを構成およびアセンブルして、アプリケーションが正しく実行され、必要な機能を提供できるようにすることです。

Spring Boot プロジェクトでは、通常、を構成するために WebApplicationInitializer インターフェイスを手動で実装する必要はありません。これは、Spring Boot がこれらの構成を自動的に処理し、デフォルトの構成メソッドを提供しているためです。 DispatcherServlet

Spring Boot は、自動構成と構成よりも規約の原則を通じて、Spring アプリケーションの開発を簡素化し、加速します。プロジェクト内の依存関係とファイル構造を自動的に検出し、規則に従ってアプリケーションのデフォルトの構成と動作を提供します。

Spring Boot では、依存関係 spring-boot-starter-web を追加すると、フレームワークが DispatcherServlet を自動的に構成し、規則に従ってルートパス「/」にマッピングします。 Spring Boot はDispatcherServlet を自動的にロードして初期化し、いくつかのデフォルトのプロセッサ、ビューパーサー、例外ハンドラーなどを自動的に構成します。

DispatcherServlet の自動構成に加えて、Spring Boot はサーブレット、フィルター、リスナーの自動登録、データソース、トランザクションの自動構成など、他の多くの自動構成機能も提供します。、など。

カスタム構成が必要な場合、Spring Boot にはデフォルト構成をオーバーライドまたは拡張するためのさまざまな方法が用意されています。アプリケーションの構成クラスで @EnableWebMvc、 @RequestMapping などのアノテーションを使用して、URL マッピングルールと処理ロジックをカスタマイズできます。 application.properties または application.yml ファイルでカスタムプロパティを構成することで、デフォルトの構成をオーバーライドすることもできます。

Spring MVC は、複数のDispatcherServlet インスタンスの定義をサポートしています。各 DispatcherServlet インスタンスには、独自の独立したコンテキストとリクエスト処理フローがあります。

通常、Spring MVC アプリケーションで複数のDispatcherServletインスタンスを定義できるシナリオは次のとおりです。

さまざまな URL パターンのリクエストを処理する: さまざまな URL パターンのリクエストをさまざまなプロセッサに分散したい場合は、URL パターンごとに独立した DispatcherServlet インスタンスを構成できます。これにより、要求された URL に基づいてさまざまな処理ロジックを選択できます。
複数の Web アプリケーションの集約: 場合によっては、複数の独立した Web アプリケーションを親プロジェクトに集約する必要があります。このシナリオを実装するには、各サブアプリケーションのリクエストを個別に処理するように、各サブアプリケーションに独立した DispatcherServlet インスタンスを構成します。
異なるビューテクノロジーを使用する: 同じアプリケーションで異なるビューテクノロジー (JSP、Thymeleaf、FreeMarker など) を同時に使用する必要がある場合は、ビューごとに独立したビューテクノロジーを構成できます< /span> DispatcherServlet インスタンス。これにより、要求されたビューテクノロジーに基づいて、適切なビューリゾルバーとテンプレートエンジンを選択できるようになります。

各DispatcherServlet インスタンスはアプリケーション内で一意の名前を持ち、独立したマッピングパスを使用して構成する必要があることに注意することが重要です。 web.xml で構成することも、Spring Boot でアプリケーション構成クラスの @ServletComponentScan アノテーションを使用してカスタマイズすることもできます。 DispatcherServlet

つまり、Spring MVC は柔軟な構成オプションを提供しており、アプリケーション内で複数の独立したDispatcherServletインスタンスを定義して、さまざまなニーズやシナリオに対応できます。

Spring Boot Web プロジェクトには、デフォルトで 2 つのDispatcherServlet インスタンスがあります。

マスター DispatcherServlet インスタンス: デフォルトのマッピングパスは「/*」で、Web リクエストの処理に使用されます。このインスタンスは、@SpringBootApplication アノテーションによって自動的に作成されます。アプリケーションのすべての構成をロードし、クライアントからの Web リクエストを処理します。
管理 DispatcherServlet 例: デフォルトのマッピングパスは「/actuator」で、Spring Boot の管理エンドポイントリクエストを処理するために使用されます。このインスタンスは Spring Boot によって自動的に追加され、アプリケーションの実行ステータスを監視および管理するための一連の管理エンドポイントを提供します。たとえば、アプリケーションの健全性ステータスは、「/actuator/health」エンドポイントを通じて取得できます。

2 つのDispatcherServlet インスタンスには、異なるタイプのリクエストを区別するための異なるマッピングパスがあります。マスター DispatcherServlet は一般的な Web リクエストを処理し、管理者 DispatcherServlet は管理エンドポイントのリクエストを処理します。

デフォルトでは DispatcherServlet インスタンスは 2 つだけですが、特定のビジネスに適応するためにカスタマイズして DispatcherServlet インスタンスを追加することもできることに注意してください。ニーズ。

要約すると、Spring Boot Web プロジェクトには、デフォルトで 2 つのDispatcherServlet インスタンスがあり、1 つは一般的な Web リクエストの処理に使用され、もう 1 つは Web リクエストの処理に使用されます。管理エンドポイント要求。

2.2 コンテキスト階層

DispatcherServlet は、独自の構成のために WebApplicationContext (通常の ApplicationContext の拡張) を必要とします。 WebApplicationContext には、ServletContext とそれに関連付けられたサーブレットへのリンクがあります。また、アプリケーションが WebApplicationContext にアクセスする必要があるときに、RequestContextUtils の静的メソッドを使用してそれを見つけることができるように、ServletContext にもバインドされます。

多くのアプリケーションでは、シングルトンの WebApplicationContext で十分です。また、ルート WebApplicationContext が複数の DispatcherServlet (または他のサーブレット) インスタンス間で共有され、それぞれが子 WebApplicationContext の独自の構成を持つコンテキスト階層が存在する場合もあります。

ルート WebApplicationContext には通常、複数のサーブレットインスタンス間で共有する必要があるデータリポジトリやビジネスサービスなどのインフラストラクチャ Bean が含まれています。これらの Bean は効果的に継承され、サーブレット固有の子 WebApplicationContext でオーバーライド (つまり、再宣言) できます。WebApplicationContext には通常、指定されたサーブレットのネイティブ Bean が含まれます。以下の図は、この関係を示しています。

ここに画像の説明を挿入します

上の図を 2.1 の DispatcherServlet 構成コードと組み合わせたものを見ると、DispatcherServlet には WebApplicationContext (AnnotationConfigWebApplicationContext) が含まれ、Controllers、ViewResolver、HandlerMapping (AppConfig.class) が定義されている必要があります。これらのインスタンスは、DispatcherServlet コンテキスト階層を形成します。

こうやって理解しましょう|ू•ૅω•́)ᵎᵎᵎ

2.3 特殊な Bean タイプ

DispatcherServlet は、リクエストを処理し、適切な応答をレンダリングするために特別な Bean に委任します。「特別な Bean」とは、フレームワークコントラクトを実装する Spring 管理対象オブジェクトインスタンスを指します。通常、これらには組み込みのコントラクトが付属していますが、プロパティをカスタマイズして拡張または置き換えることができます。

次の表に、DispatcherServlet によって検出される特別な Bean を示します。

豆の種類	説明
`HandlerMapping`	リクエストをハンドラーと [インターセプター] のリストにマッピングします (https://docs.spring.io/spring-framework/docs/5.3.30-SNAPSHOT/reference/html/web.html#mvc-handlermapping-interceptor)前処理と後処理に。マッピングはいくつかの標準に基づいており、その詳細は「 HandlerMapping 」実装によって異なります。 2 つの主な "HandlerMapping" 実装は、"RequestMappingHandlerMapping" ("@RequestMapping" アノテーション付きメソッドをサポート) と "SimpleUrlHandlerMapping" (ハンドラーの URI パスパターンの明示的な登録を維持します) です。
`HandlerAdapter`	ハンドラーが実際にどのように呼び出されるかに関係なく、「DispatcherServlet」がリクエストにマップされたハンドラーを呼び出すのを支援します。たとえば、アノテーション付きコントローラーを呼び出すには、アノテーションを解析する必要があります。「 HandlerAdapter 」の主な目的は、「 DispatcherServlet 」をこれらの詳細から保護することです。
`HandlerExceptionResolver`	例外を解決するための戦略。場合によっては例外をハンドラー、HTML エラービュー、またはその他のターゲットにマッピングします。 (例外)(https://docs.spring.io/spring-framework/docs/5.3.30-SNAPSHOT/reference/html/web.html mvc-Exceptionhandlers) を参照してください。
`ViewResolver`	ハンドラーから返された論理 ' String ' ベースのビュー名を実際の ' view ' に解析し、それを使用して応答にレンダリングします。「ビューの解像度」と「ビューのテクノロジー」をご覧ください。
`LocaleResolver`、LocaleContextResolver	国際化されたビューを提供できるように、クライアントが使用している「ロケール」と、場合によってはタイムゾーンを解決します。 (ロケール)(https://docs.spring.io/spring-framework/docs/5.3.30-SNAPSHOT/reference/html/web.html mvc-localeresolver) を参照してください。
`ThemeResolver`	Web アプリケーションで使用できるテーマに対応します (たとえば、パーソナライズされたレイアウトを提供するなど)。 (テーマ)(https://docs.spring.io/spring-framework/docs/5.3.30-SNAPSHOT/reference/html/web.html mvc-themeresolver) を参照してください。
`MultipartResolver`	抽象化は、いくつかのマルチパート解析ライブラリを利用してマルチパートリクエスト (ブラウザフォームファイルのアップロードなど) を解析するために使用されます。「マルチパートパーサー」をご覧ください。
`FlashMapManager`	「入力」と「出力」の「FlashMap」を保存および取得します。これらの「FlashMap」は、通常はリダイレクトを通じて、あるリクエストから別のリクエストに属性を渡すために使用できます。 Flash プロパティを参照してください。

表内のこれらのクラスまたはインターフェイスはすべて DispatcherServlet のメンバー属性です。メンバー属性の役割を理解すると、実際には DispatcherServlet の役割も理解できます。

2.4 カスタム DispatcherServlet の補足

2 つの部分:

Web MVC Config: 一致する Bean タイプがない場合に、DispatcherServlet.properties にリストされているデフォルトのタイプにフォールバックする特別な Bean を 2.3 で定義します。
Servlet Config:参考2.1。

2.5 加工プロセス

ここに画像の説明を挿入します

2.6 パスのマッチング

Spring MVC 5.3 より前のバージョンでは、requestURI (要求された URI) のデコードで次の問題が発生しました。

URL エンコードの問題: ブラウザが特殊文字または非 ASCII 文字を含むリクエストを送信すると、これらの文字はブラウザによって自動的に URL エンコードされます。つまり、特殊文字は < に変換されます。 a i=1> 文字の ASCII 表現が続きます。たとえば、スペースはとしてエンコードされ、漢字はとしてエンコードされます。 Spring MVC の古いバージョンでは、はデフォルトでエンコードを維持します。つまり、URL はデコードされません。 %%20%E4%BD%A0requestURI
中国語の文字化けコードの問題: requestURI はブラウザがエンコードした後にサーバーに渡されるため、サーバーは% 以降の ASCII 表現をデフォルトではオリジナルの文字が表示されますが、中国語の場合、古いバージョンの Spring MVC では中国語の文字化けの問題が発生します。たとえば、%E4%BD%A0 は、正しい中国語の文字ではなく、文字化けした文字にデコードされます。

これらの問題により、アプリケーションが特殊文字または非 ASCII 文字を含むリクエストを正しく処理できなくなり、文字化けやパラメータ解析エラーなどの問題が発生する可能性があります。

PathPattern と AntPathMatcher は、パスパターンを照合するための 2 つのツールです。

AntPathMatcher:
AntPathMatcher は、Spring フレームワークで提供されるパスマッチャーの 1 つで、Ant スタイルのパスパターンマッチングに基づいています。 Ant スタイルのパスパターンでは、ワイルドカードを使用してパスの特定の部分を表します。たとえば、 ? は任意の 1 文字と一致し、 * は任意の数の文字 (0 文字を含む) と一致します。文字)、** は、任意の数のパス (0 個のパスセグメントを含む) と一致することを意味します。 AntPathMatcher を使用して、ファイルパス、URL パスなどを照合できます。

たとえば、AntPathMatcher を使用すると、次のパスの一致を実行できます。

/user/? は /user/1 と一致しますが、とは一致しません/user/1/friends
/user/* は /user/1 およびと一致します/user/1/friends
/user/** は /user/1 およびと一致します/user/1/friends

パスパターン：

PathPattern は、URL パスパターンマッチングの問題を解決するために Spring Framework 5.3 で導入されたクラスです。 Web アプリケーション開発では、入力 URL パスの照合と解析が一般的な要件です。 PathPattern は、URL パスパターンを処理するためのより柔軟かつ強力な方法を提供します。

PathPattern次の問題が解決されました。

URL パスの柔軟なマッチング: 従来の URL パスマッチングは文字列マッチングに基づいており、複雑なパスパターンマッチング要件には対応できません。 PathPattern 柔軟な URL パスマッチングパターンを構築するための、パス変数、ワイルドカード、正規表現などの使用をサポートします。たとえば、、、および /{category}/{id} を介した他のパスと一致し、と一致することができます。 < /span> が変数として抽出されます。 /books/123/movies/456{category}{id}
パスパラメータの抽出と解析:PathPattern 一致する URL パスからパスパラメータを抽出し、対応するデータ型に変換できます。パスパラメータを使用すると、データを動的に渡すことができます。たとえば、/books/123 の 123 をパスパラメータとして抽出して解析できます。
RESTful ルーティングとリソースマッピング:PathPattern は、RESTful ルーティングとリソースマッピングのために Spring Web MVC または Spring WebFlux と統合できます。パスパターンを定義して照合することにより、リクエストを対応するプロセッサメソッドにマッピングすることがより簡単になり、複数の柔軟なパスマッチングパターンがサポートされます。
安全なパスマッチング:PathPattern URL パスを正規化および標準化することで、より安全なパスマッチングが実現します。 URL のエンコード、デコード、正規化を処理し、パスの一致を処理する際の潜在的なセキュリティホールの導入を回避します。

AntPathMatcher と比較して、PathPattern はより豊富で柔軟なパスマッチング機能を提供します。 PathPattern は、より厳格なパスの検証を実行し、パスセグメントマッチング、パスパラメーターマッチング、クエリパラメーターマッチングなどを含む、より多くのパターンマッチングルールをサポートします。

たとえば、PathPattern を使用すると、次のパスマッチングを実行できます。

/user/{id} は /user/1 と一致しますが、とは一致しません/user/1/friends
/user/{id}/** は /user/1 およびと一致します/user/1/friends
/user/{id:\\d+} は /user/1 と一致しますが、とは一致しません/user/abc

プロジェクトで Spring Boot 2.6.x を使用する場合、そのパスマッチング形式は PathPattern です。Swagger を統合する場合は、起動時にエラーが報告されることに注意してください。Spring MVC のパスマッチングルールを Ant に変更する必要があります。スタイル：

spring.mvc.pathmatch.matching-strategy=ant_path_matcher

2.7 ビュー分析

Spring MVC は、特定のビューテクノロジに束縛されずにブラウザーでモデルをレンダリングできるようにする ViewResolver および View インターフェイスを定義します。 ViewResolver は、ビュー名と実際のビューの間のマッピングを提供します。ビューは、特定のビューテクノロジにデータを引き渡す前に、データの準備を処理します。

次の表に、ViewResolver 階層の詳細を示します。

ビューリゾルバー	説明
`AbstractCachingViewResolver`	「AbstractCachingViewResolver」のサブクラスは、解決するビューインスタンスをキャッシュします。キャッシュにより、特定のビューテクノロジのパフォーマンスが向上します。「cache」プロパティを「false」に設定すると、キャッシュをオフにできます。さらに、実行時に特定のビューを更新する必要がある場合 (たとえば、FreeMarker テンプレートが変更されたとき)、「removeFromCache(String viewName, Locale loc)」メソッドを使用できます。
`UrlBasedViewResolver`	明示的なマッピング定義を必要とせずに、論理ビュー名を URL に直接解決できる ViewResolver インターフェイスのシンプルな実装。これは、任意のマッピングを必要とせずに、論理名がビューリソースの名前と直接一致する場合に適しています。
`InternalResourceViewResolver`	「InternalResourceView」（実際にはサーブレットと jsps）および「JstlView」や「TilesView」などのサブクラスをサポートする「UrlBasedViewResolver」の便利なサブクラス。 'setViewClass(...)' を使用して、このパーサーによって生成されるすべてのビューのビュークラスを指定できます。詳細については、「UrlBasedViewResolver」 javadoc を参照してください。
`FreeMarkerViewResolver`	FreeMarkerView およびカスタムサブクラスをサポートする便利な UrlBasedViewResolver サブクラス。
`ContentNegotiatingViewResolver`	「ViewResolver」インターフェースの実装。リクエストファイル名または「Accept」ヘッダーに基づいてビューを解決します。 [コンテンツネゴシエーション](https://docs.spring.io/spring-framework/docs/5.3.30-SNAPSHOT/reference/html/web.html#mvc-multiple-representations) を参照してください。
`BeanNameViewResolver	ViewResolver 現在のアプリケーションコンテキストでビュー名を Bean 名に解釈するインターフェイスの実装。これは非常に柔軟なバリアントであり、異なるビュー名に基づいて異なるビュータイプを混合および一致させることができます。このような各「ビュー」は、XML や構成クラスなどの Bean として定義できます。

2.8マルチパートリゾルバー

MultipartResolver は、マルチパートリクエスト (ファイルアップロードを含む) を解析するための戦略です。 Commons FileUpload に基づいた実装と、Servlet 3.0 マルチパートリクエストの解析に基づいた実装があります。

Commons FileUpload は従来、POST リクエストでのみ機能しますが、あらゆるマルチパート/コンテンツタイプを受け入れます。詳細と構成オプションについては、commonsmmultipartresolver javadoc を参照してください。

Servlet 3.0 マルチパート解析は、Servlet コンテナ設定を通じて有効にする必要があります。デフォルトでは、任意の HTTP メソッドを使用して任意の multipart/content-type を解析しようとしますが、これはすべてのサーブレットコンテナでサポートされているわけではありません。詳細と構成オプションについては、StandardServletMultipartResolver javadoc を参照してください。

3 アノテーション付きコントローラーハンドラー

Spring MVC は、アノテーションベースのプログラミングモデルを提供します。このモデルでは、@Controller コンポーネントと @RestController コンポーネントがアノテーションを使用して、リクエストマッピング、リクエスト入力、例外処理などを表現します。アノテーション付きコントローラーには柔軟なメソッドシグネチャがあり、基本クラスを拡張したり、特定のインターフェイスを実装したりする必要はありません。次の例は、アノテーションによって定義されたコントローラーを示しています。

@Controller
public class HelloController {

    @GetMapping("/hello")
    public String handle(Model model) {
        model.addAttribute("message", "Hello World!");
        return "index";
    }
}

前の例では、このメソッドはモデルを受け入れ、ビュー名を文字列として返しますが、他にも多くのオプションがあります。これについてはこの章で後ほど説明します。

@RestController は複合アノテーションであり、それ自体に @Controller および @ResponseBody のメタアノテーションがあり、コントローラーの各メソッドがタイプレベルの @ResponseBody アノテーションを継承するため、HTML テンプレートを使用する代わりに応答本文を直接書き込みます。解析とレンダリング。したがって、Spring Boot プロジェクトでは、ページルーティングを定義するときに、WebController は @RestController の代わりに @Controller アノテーションを使用する必要があります。

3.1リクエストのマッピング

@RequestMapping アノテーションを使用して、リクエストをコントローラーメソッドにマップできます。 URL、HTTP メソッド、リクエストパラメーター、ヘッダー、メディアタイプに基づいて照合できるさまざまなプロパティがあります。これをクラスレベルで使用して共有マッピングを表すことも、メソッドレベルで使用して特定のエンドポイントマッピングに絞り込むこともできます。

@RequestMapping の HTTP メソッド固有のショートカットバリアントもあります。

@GetMapping
@PostMapping
@PutMapping
@DeleteMapping
@PatchMapping

デフォルトですべての HTTP メソッドに一致する @RequestMapping を使用する代わりに、ほとんどのコントローラーメソッドを特定の HTTP メソッドにマップする必要があるため、ショートカットはカスタムアノテーションを提供することです。共有マッピングを表現するには、クラスレベルで @RequestMapping が依然として必要です。

次の例には、タイプとメソッドのレベルのマッピングがあります。

@RestController
@RequestMapping("/persons")
class PersonController {

    @GetMapping("/{id}")
    public Person getPerson(@PathVariable Long id) {
        // ...
    }

    @PostMapping
    @ResponseStatus(HttpStatus.CREATED)
    public void add(@RequestBody Person person) {
        // ...
    }
}

3.2 メソッドパラメータ

コントローラーメソッドの引数	説明
`WebRequest`、`NativeWebRequest`	サーブレット API を直接使用せずに、リクエストパラメータ、リクエストおよびセッション属性への汎用アクセス。
`javax.servlet.ServletRequest`、`javax.servlet.ServletResponse`	特定のリクエストまたはレスポンスのタイプを選択します — 例: `ServletRequest`、`HttpServletRequest`、Spring の `MultipartRequest`、`MultipartHttpServletRequest`.
`javax.servlet.http.HttpSession`	セッションの存在を強制します。結果として、そのような議論は決して `null` ではありません。セッションへのアクセスはスレッドセーフではないことに注意してください。複数のリクエストによるセッションへの同時アクセスが許可されている場合は、 `RequestMappingHandlerAdapter` インスタンスの `synchronizeOnSession` フラグを `true` に設定することを検討してください。
`javax.servlet.http.PushBuilder`	プログラムによる HTTP/2 リソースプッシュ用のサーブレット 4.0 プッシュビルダー API。サーブレット仕様に従って、クライアントが HTTP/2 機能をサポートしていない場合、挿入された `PushBuilder` インスタンスは null になる可能性があることに注意してください。
`java.security.Principal`	Currently authenticated user — possibly a specific `Principal` implementation class if known.Note that this argument is not resolved eagerly, if it is annotated in order to allow a custom resolver to resolve it before falling back on default resolution via `HttpServletRequest#getUserPrincipal`. For example, the Spring Security `Authentication` implements `Principal` and would be injected as such via `HttpServletRequest#getUserPrincipal`, unless it is also annotated with `@AuthenticationPrincipal` in which case it is resolved by a custom Spring Security resolver through `Authentication#getPrincipal`.
`HttpMethod`	The HTTP method of the request.
`java.util.Locale`	The current request locale, determined by the most specific `LocaleResolver` available (in effect, the configured `LocaleResolver` or `LocaleContextResolver`).
`java.util.TimeZone` + `java.time.ZoneId`	The time zone associated with the current request, as determined by a `LocaleContextResolver`.
`java.io.InputStream`, `java.io.Reader`	For access to the raw request body as exposed by the Servlet API.
`java.io.OutputStream`, `java.io.Writer`	For access to the raw response body as exposed by the Servlet API.
`@PathVariable`	For access to URI template variables. See URI patterns.
`@MatrixVariable`	For access to name-value pairs in URI path segments. See Matrix Variables.
`@RequestParam`	For access to the Servlet request parameters, including multipart files. Parameter values are converted to the declared method argument type. See `@RequestParam` as well as Multipart.Note that use of `@RequestParam` is optional for simple parameter values. See “Any other argument”, at the end of this table.
`@RequestHeader`	For access to request headers. Header values are converted to the declared method argument type. See `@RequestHeader`.
`@CookieValue`	For access to cookies. Cookies values are converted to the declared method argument type. See `@CookieValue`.
`@RequestBody`	For access to the HTTP request body. Body content is converted to the declared method argument type by using `HttpMessageConverter` implementations. See `@RequestBody`.
`HttpEntity<B>`	For access to request headers and body. The body is converted with an `HttpMessageConverter`. See HttpEntity.
`@RequestPart`	For access to a part in a `multipart/form-data` request, converting the part’s body with an `HttpMessageConverter`. See Multipart.
`java.util.Map`, `org.springframework.ui.Model`, `org.springframework.ui.ModelMap`	For access to the model that is used in HTML controllers and exposed to templates as part of view rendering.
`RedirectAttributes`	Specify attributes to use in case of a redirect (that is, to be appended to the query string) and flash attributes to be stored temporarily until the request after redirect. See Redirect Attributes and Flash Attributes.
`@ModelAttribute`	For access to an existing attribute in the model (instantiated if not present) with data binding and validation applied. See `@ModelAttribute` as well as Model and `DataBinder`.Note that use of `@ModelAttribute` is optional (for example, to set its attributes). See “Any other argument” at the end of this table.
`Errors`, `BindingResult`	For access to errors from validation and data binding for a command object (that is, a `@ModelAttribute` argument) or errors from the validation of a `@RequestBody` or `@RequestPart` arguments. You must declare an `Errors`, or `BindingResult` argument immediately after the validated method argument.
`SessionStatus` + class-level `@SessionAttributes`	For marking form processing complete, which triggers cleanup of session attributes declared through a class-level `@SessionAttributes` annotation. See `@SessionAttributes` for more details.
`UriComponentsBuilder`	For preparing a URL relative to the current request’s host, port, scheme, context path, and the literal part of the servlet mapping. See URI Links.
`@SessionAttribute`	For access to any session attribute, in contrast to model attributes stored in the session as a result of a class-level `@SessionAttributes` declaration. See `@SessionAttribute` for more details.
`@RequestAttribute`	For access to request attributes. See `@RequestAttribute` for more details.
Any other argument	If a method argument is not matched to any of the earlier values in this table and it is a simple type (as determined by BeanUtils#isSimpleProperty), it is resolved as a `@RequestParam`. Otherwise, it is resolved as a `@ModelAttribute`.

上述表格中为@Controller中方法的参数和参数注解，具体含义不翻译了可自行百度。有几个常见的、重要的还是有必要去了解的：javax.servlet.ServletRequest, javax.servlet.ServletResponse，javax.servlet.http.HttpSession，@RequestBody,@PathVariable,@RequestParam

3.3返回值

Controller method return value	Description
`@ResponseBody`	The return value is converted through `HttpMessageConverter` implementations and written to the response. See `@ResponseBody`.
`HttpEntity<B>`, `ResponseEntity<B>`	The return value that specifies the full response (including HTTP headers and body) is to be converted through `HttpMessageConverter` implementations and written to the response. See ResponseEntity.
`HttpHeaders`	For returning a response with headers and no body.
`String`	A view name to be resolved with `ViewResolver` implementations and used together with the implicit model — determined through command objects and `@ModelAttribute` methods. The handler method can also programmatically enrich the model by declaring a `Model` argument (see Explicit Registrations).
`View`	A `View` instance to use for rendering together with the implicit model — determined through command objects and `@ModelAttribute` methods. The handler method can also programmatically enrich the model by declaring a `Model` argument (see Explicit Registrations).
`java.util.Map`, `org.springframework.ui.Model`	Attributes to be added to the implicit model, with the view name implicitly determined through a `RequestToViewNameTranslator`.
`@ModelAttribute`	An attribute to be added to the model, with the view name implicitly determined through a `RequestToViewNameTranslator`.Note that `@ModelAttribute` is optional. See “Any other return value” at the end of this table.
`ModelAndView` object	The view and model attributes to use and, optionally, a response status.
`void`	A method with a `void` return type (or `null` return value) is considered to have fully handled the response if it also has a `ServletResponse`, an `OutputStream` argument, or an `@ResponseStatus` annotation. The same is also true if the controller has made a positive `ETag` or `lastModified` timestamp check (see Controllers for details).If none of the above is true, a `void` return type can also indicate “no response body” for REST controllers or a default view name selection for HTML controllers.
`DeferredResult<V>`	Produce any of the preceding return values asynchronously from any thread — for example, as a result of some event or callback. See Asynchronous Requests and `DeferredResult`.
`Callable<V>`	Produce any of the above return values asynchronously in a Spring MVC-managed thread. See Asynchronous Requests and `Callable`.
`ListenableFuture<V>`, `java.util.concurrent.CompletionStage<V>`, `java.util.concurrent.CompletableFuture<V>`	Alternative to `DeferredResult`, as a convenience (for example, when an underlying service returns one of those).
`ResponseBodyEmitter`, `SseEmitter`	Emit a stream of objects asynchronously to be written to the response with `HttpMessageConverter` implementations. Also supported as the body of a `ResponseEntity`. See Asynchronous Requests and HTTP Streaming.
`StreamingResponseBody`	Write to the response `OutputStream` asynchronously. Also supported as the body of a `ResponseEntity`. See Asynchronous Requests and HTTP Streaming.
Reactor and other reactive types registered via `ReactiveAdapterRegistry`	A single value type, e.g. `Mono`, is comparable to returning `DeferredResult`. A multi-value type, e.g. `Flux`, may be treated as a stream depending on the requested media type, e.g. “text/event-stream”, “application/json+stream”, or otherwise is collected to a List and rendered as a single value. See Asynchronous Requests and Reactive Types.
Other return values	If a return value remains unresolved in any other way, it is treated as a model attribute, unless it is a simple type as determined by BeanUtils#isSimpleProperty, in which case it remains unresolved.

3.4Jackson

Jackson是一个Java库，用于处理JSON格式的数据。它提供了一组强大的功能，可以在Java对象和JSON之间进行转换，包括序列化（将Java对象转换为JSON字符串）和反序列化（将JSON字符串转换为Java对象）。

以下是Jackson的主要作用：

对象序列化和反序列化：Jackson可以将Java对象转换为JSON字符串，以及将JSON字符串转换为Java对象。这对于在Java应用程序和前端或其他服务之间传递数据时非常有用。
数据绑定：Jackson可以将JSON数据绑定到Java对象上，并将JSON数据中的属性值映射到Java对象的相应属性上。这使得在处理JSON数据时可以轻松地将其转换为Java对象，并进行操作。
数据格式化和解析：Jackson提供了灵活的方式来格式化（美化）JSON数据并解析复杂的JSON结构。它支持各种JSON格式，如数组、嵌套对象、键值对等。
支持注解：Jackson支持在Java对象中使用注解，以控制JSON序列化和反序列化的行为。通过注解，可以自定义属性的命名、忽略某些属性、处理日期格式等。
支持流式API：Jackson提供了流式的API，可以逐行读取JSON数据，并进行处理，而不需要将整个JSON字符串加载到内存中。这对于处理大型JSON数据或实时流式数据非常有用。

Spring框架提供了对Jackson JSON库的全面支持，包括以下几个方面的应用：

JSON序列化和反序列化：Spring使用Jackson库作为默认的JSON序列化和反序列化工具。在处理HTTP请求和响应时，Spring MVC框架会自动将Java对象转换为JSON格式的响应数据，并将接收到的JSON数据转换为Java对象。这使得开发人员可以在控制器方法中直接使用Java对象，而不需要手动处理JSON数据的转换。
HTTP メッセージコンバータ: Spring は、Jackson ライブラリを使用した JSON 形式用のコンバータを含む、一連の HTTP メッセージコンバータを提供します。これらのコンバーターを使用すると、開発者は HTTP リクエストと応答を処理するときに Java オブジェクトと JSON データの間で簡単に変換できます。
アノテーションのサポート: Spring は、@JsonSerialize、@JsonDeserialize、@JsonProperty などの Jackson ライブラリアノテーションのサポートを提供します。これらのアノテーションを通じて、開発者は、属性の名前付け、型変換、日付の書式設定など、Java オブジェクトの JSON シリアル化および逆シリアル化ルールをカスタマイズできます。
構成オプション: Spring を使用すると、開発者は Jackson ライブラリの構成をきめ細かく制御できます。たとえば、JSON 出力をインデントするかどうか、null 属性を無視するかどうかなど、Jackson の特性を構成できます。開発者は構成オプションを通じて、特定のニーズに基づいて JSON のシリアル化と逆シリアル化の動作を調整できます。
他の JSON ライブラリのサポート: Spring はデフォルトで JSON 処理に Jackson ライブラリを使用しますが、Gson、FastJson などの他の JSON ライブラリもサポートします。開発者は、好みやプロジェクトのニーズに応じて統合に適切な JSON ライブラリを選択し、Spring で設定できます。

つまり、Spring の Jackson JSON ライブラリのサポートにより、開発者は JSON データをより便利に処理し、Java オブジェクトと JSON データの間で変換できるようになります。これにより、RESTful API の開発やフロントエンドとバックエンドのデータ対話の処理などのシナリオに利便性が提供され、開発効率とコードの可読性が向上します。

4非同期リクエスト

Spring MVC は、Servlet 3.0 の非同期リクエスト処理と広範に統合されています。

コントローラーメソッドの DeferredResult および Callable 戻り値は、単一の非同期戻り値の基本的なサポートを提供します。

コントローラーは、SSE や生データを含む複数の値をストリーミングできます。

4.1遅延結果

サーブレットコンテナで非同期リクエスト処理機能が有効になると、次の例に示すように、コントローラーメソッドは、サポートされているコントローラーメソッドの戻り値を DeferredResult でラップできます。

@GetMapping("/quotes")
@ResponseBody
public DeferredResult<String> quotes() {
    DeferredResult<String> deferredResult = new DeferredResult<String>();
    // Save the deferredResult somewhere..
    return deferredResult;
}

// From some other thread...
deferredResult.setResult(result);

コントローラーは、外部イベント (JMS メッセージ)、スケジュールされたタスク、またはその他のイベントに応答して、さまざまなスレッドから非同期に戻り値を生成できます。

4.2呼び出し可能

コントローラーは、サポートされている戻り値を java.util.concurrent でラップできます。次の例に示すように、呼び出すことができます。

@PostMapping
public Callable<String> processUpload(final MultipartFile file) {

    return new Callable<String>() {
        public String call() throws Exception {
            // ...
            return "someView";
        }
    };
}

戻り値は、構成された TaskExecutor を通じて指定されたタスクを実行することによって取得できます。