Spring には、一度設定が完了すると変更されない設定が多く、ほとんどの Bean の依存関係など、変更する必要がないためです。これらの変更されない設定をすべて XML に含めることは意味がありません。Spring 3.x は設定が多すぎると批判され、設定ベースのプログラミングになりました。したがって、実際には、これらのほぼ静的な構成をコードに含める方が良いでしょう。 XML は変更が容易で、コンパイルなしで有効にできるため、環境やビジネスに応じて変更が必要な設定は XML に記述した方がよいでしょう。 Spring Boot は Rails の規約ベースの構成を吸収するため、構成が大幅に削減されます。ただし、その基礎となる構成がどのように構成されているかをよく知らないと、多くの問題が発生する可能性があります。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
チェーン プログラミングを使用すると、コード内で構成を記述することがより直観的かつ簡単になります (一部の構成は Spring Boot 自体によって行われます)。 。 。
Maven の依存関係を使用すると、より新鮮になります。
しかし、もっと落とし穴があると思います
Spring には、一度設定が完了すると変更されない設定が多く、ほとんどの Bean の依存関係など、変更する必要がないためです。これらの変更されない設定をすべて XML に含めることは意味がありません。Spring 3.x は設定が多すぎると批判され、設定ベースのプログラミングになりました。したがって、実際には、これらのほぼ静的な構成をコードに含める方が良いでしょう。
XML は変更が容易で、コンパイルなしで有効にできるため、環境やビジネスに応じて変更が必要な設定は XML に記述した方がよいでしょう。
Spring Boot は Rails の規約ベースの構成を吸収するため、構成が大幅に削減されます。ただし、その基礎となる構成がどのように構成されているかをよく知らないと、多くの問題が発生する可能性があります。
これについては私も少し言葉を失います。
説明する必要がある場合、Spring 時代以前の Java 構成は命令型 (実行順序に応じてすべて記述される) でしたが、Spring Boot 時代には宣言型 Java 構成 (分散型) に変更されました。注釈付きメソッドが複数ある場合、実行順序はそれに依存しません)。
他の多くの設定は application.properties でオーバーライドできます。これはずっと前に行われるべきでした。
リーリー