導入
@ConfigurationProperties は Spring フレームワークのアノテーションで、構成ファイルのプロパティを Java オブジェクトのフィールドにマップするために使用されます。その主な目的は、構成ファイルと Java オブジェクトの間のマッピング プロセスを簡素化し、構成をより便利で読みやすくし、タイプセーフなプロパティ アクセスを提供することです。
目的と特徴
-
プロパティのマッピング: 構成ファイル内のプロパティを Java オブジェクトのフィールドにマップします。このようにして、Java クラスでフィールドを定義することで、アプリケーションの構成を整理し、アクセスできるようになります。
-
タイプ セーフ: Java 型のアノテーションを使用することで、タイプ セーフなプロパティ アクセスを実現できます。設定ファイル内のプロパティが Java の型と一致しない場合、Spring は起動時にエラーを報告して、設定エラーを事前に検出します。
-
ネストされたプロパティ: 構成ファイル内のプロパティを Java オブジェクトのネストされたフィールドにネストすることをサポートし、構成情報をより構造化された方法で編成できるようにします。
-
複数環境のサポート: アノテーションでプレフィックス属性を指定して、複数環境の構成を実現することで、異なる環境の構成情報をグループ化できます。
-
デフォルト値: フィールドにデフォルト値を設定できます。設定ファイルに対応する属性がない場合は、デフォルト値が使用されます。
-
動的リフレッシュ: Spring Boot では、@ConfigurationProperties も動的リフレッシュをサポートしており、構成が変更された場合、アプリケーションを再起動せずに @RefreshScope アノテーションを通じて動的リフレッシュを実現できます。
-
プロパティの検証: @Validated アノテーションを JSR 303 標準検証アノテーションと組み合わせて使用して、構成プロパティを検証できます。
例は次のとおりです。
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
@Component
@ConfigurationProperties(prefix = "myapp")
public class MyAppProperties {
private String appName;
private int maxConnections;
// other properties...
// getters and setters...
}
上記の例では、 @ConfigurationProperties アノテーションは接頭辞属性を「myapp」として指定し、構成ファイル内のプロパティの接頭辞として「myapp」を付ける必要があることを示しています。たとえば、構成ファイル内のプロパティは myapp.appName および myapp.maxConnections などです。これらのプロパティは、MyAppProperties クラスの対応するフィールドにマップされます。
@Valueとの違い
@ConfigurationProperties と @Value は、Spring で構成情報を取得する 2 つの異なる方法です。
- タイプセーフティ:
@ConfigurationProperties はタイプセーフな構成バインディングを提供します。 Java クラスを作成し、構成プロパティをクラスのフィールドにマップすると、Spring は構成ファイル内の値を対応するフィールドに自動的にバインドし、型変換を実行します。型が一致しない場合、Spring は起動時にエラーを報告します。
@Value は SpEL (Spring Expression Language) に基づいています。これは文字列式であり、型安全性は提供されません。型変換は手動で行う必要があり、型が一致しない場合は実行時エラーが発生する可能性があります。
- 複数の属性のバインディング:
@ConfigurationProperties は、複数のプロパティを 1 つのクラスにバインドすることをサポートしているため、構成がより構造化され、複雑な構成情報の整理に適しています。
@Value は通常、単一の属性の挿入に使用され、複雑な構成情報を整理するのは困難です。
- 該当するシーン:
@ConfigurationProperties は、多数の構成プロパティと複数の関連する構成プロパティ、特に複雑な構成情報が存在する状況に適しています。
@Value は、少数の構成項目に対する単純なプロパティの挿入に適しています。
最大的区别在于第一点类型安全上
:
@ConfigurationProperties を使用すると、構成ファイル内のプロパティを Java クラスのフィールドに直接マッピングできます。 Spring は、起動時に設定ファイル内の値を宣言されたフィールドの型に変換しようとします。 型が一致しない場合、Spring は起動時にそれを検出し、エラーを報告します。この型チェックはアプリケーションの起動時に行われ、実行時の予期しない動作ではなく、構成エラーを事前に検出するのに役立ちます。
第 2 に、構成属性は Java クラスを通じて管理できるため、構成属性が多数ある場合にそれらをより統合できます。
@value の利点は、次のような、ほとんど関係のない 2 つの構成に反映されています。myapp.aaa.ccc.bbb=1そしてmyapp.qqq=2次の 2 つの構成
@ConfigurationProperties アノテーションが使用されている場合は、次のように、コンテンツを取得するためにネストされたメソッドが必要です。
import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;
@Component
@ConfigurationProperties(prefix = "myapp")
public class MyAppProperties {
private final AAA aaa = new AAA();
private int qqq;
public static class AAA {
private final CCC ccc = new CCC();
public static class CCC {
private int bbb;
public int getBbb() {
return bbb;
}
public void setBbb(int bbb) {
this.bbb = bbb;
}
}
public CCC getCcc() {
return ccc;
}
}
public AAA getAaa() {
return aaa;
}
public int getQqq() {
return qqq;
}
public void setQqq(int qqq) {
this.qqq = qqq;
}
}
結論は
@ConfigurationProperties の利点を組み合わせると、構成ファイルに同意するときに、同じビジネス構成には統一されたプレフィックスが必要になり、ネストが削減されます (アンダースコアまたは水平バーを使用したマッピング クラスのキャメル ケース命名を通じて)。また、異なるビジネス構成では異なるものになります。接頭辞。これにより、構成クラスを使用した管理が容易になります。例は次のとおりです。
補充する
他の同様のスプリングの注釈を追加します
- @ConditionalOnproperity
@ConditionalOnProperty は Spring Boot の条件付きアノテーションで、構成プロパティの値に基づいて構成クラス、Bean、またはコンポーネントを有効にするかどうかを決定するために使用されます。このアノテーションは、次のシナリオで特に役立ちます。
特定の構成スイッチ: @ConditionalOnProperty を使用して、構成ファイル内のプロパティ値に基づいて構成を有効にするかどうかを決定できます。たとえば、 特定のBean または設定クラスは、特定のプロパティが設定ファイルに設定されている場合にのみ有効になります。
@Configuration
@ConditionalOnProperty(name = "myapp.feature.enabled", havingValue = "true")
public class MyFeatureConfiguration {
// 配置类的内容...
}
myapp.feature.enabled=true なので、プロパティ myapp.feature.enabled の値が true のときに構成クラス MyFeatureConfiguration が有効になります。
- @ConditionalOnMissingBean
@ConditionalOnMissingBean は Spring Boot の条件付きアノテーションで、特定の Bean がまだ存在しない場合に構成クラス、Bean、またはコンポーネントを有効にするために使用されます。このアノテーションは、次のシナリオで特に役立ちます。
デフォルトの実装: 複数の実装を持つインターフェイスまたは抽象クラスがある場合、 @ConditionalOnMissingBean アノテーションを使用してデフォルトの実装を提供できます。特定の実装の Bean がコンテナ内にすでに存在する場合、このデフォルト実装の Bean は作成されません。
@Service
public class DefaultMyService implements MyService {
// 默认实现的内容...
}
@Service
@ConditionalOnMissingBean(MyService.class)
public class CustomMyService implements MyService {
// 自定义实现的内容...
}
この例では、コンテナ内にタイプ MyService の Bean (DefaultMyService など) がすでに存在する場合、CustomMyService は作成されません。そうでない場合は、CustomMyService が作成されます。
プラグイン拡張機能: 開発者がアプリケーションにカスタム実装を登録できるようにするプラグイン メカニズムを提供する場合は、 @ConditionalOnMissingBean を使用します。このように、ユーザーが自分で実装を定義した場合はユーザーの実装が使用され、それ以外の場合はデフォルトの実装が使用されます。
@Configuration
public class MyConfig {
@Bean
@ConditionalOnMissingBean
public MyPlugin myPlugin() {
return new DefaultMyPlugin();
}
}
この例では、MyPlugin タイプの Bean がコンテナ内にすでに存在する場合、myPlugin メソッドは新しい Bean を作成しません。それ以外の場合は、デフォルトの DefaultMyPlugin Bean が作成されます。