Springで依存関係の解決をカスタマイズする

こんにちは 私の名前はアンドレイ・ネベドムスキーで、私はSberTechのチーフエンジニアです。 私は、ESF（Unified Frontal System）のシステムサービスの1つを開発するチームで働いています。 私たちの仕事では、Spring Framework、特にそのDIを積極的に使用していますが、Springで依存関係を解決することは私たちにとって十分に賢くないという事実に時々直面しています。 この記事は、それをよりスマートにし、それがどのように機能するかを一般的に理解しようとする私の試みの結果です。 春の装置について、そこから何か新しいことを学べることを願っています。







記事を読む前に、 Boris Yevgeny EvgenyBorisovのレポート： Spring Ripper、Part 1を読むことを強くお勧めします。 スプリングリッパー、パート2 まだそれらのプレイリストがあります 。

はじめに

運命と星占いを予測するサービスの開発を依頼されたと想像してみましょう。 サービスにはいくつかのコンポーネントがありますが、主なものは2つです。

• FortuneTellerインターフェイスを実装し、運命を予測するGloba。
  
  
  
  
  
  
  
  

• Gypsy。HoroscopeTellerインターフェイスを実装し、ホロスコープを作成します。
  
  
  
  
  
  
  
  

また、このサービスには、実際に運命と星占いの予測を受信するためのいくつかのエンドポイント（コントローラー）があります。 また、コントローラーメソッドに適用されるアスペクトを使用して、IPによるアプリケーションへのアクセスを制御し、次のようになります。





そのようなIPからのアクセスが許可されていることを確認するには、 ipIsAllowed



述語の実装を使用します。 一般に、この側面のサイトでは、たとえば認証を実行するなど、他の何かがあるかもしれません。



それで、私たちはアプリケーションを開発しました、そして、すべてが私たちにとって素晴らしい作品です。 しかし、今からテストについて話しましょう。

それをテストするには？

アスペクトのアプリケーションをテストする方法について話しましょう。 これを行うにはいくつかの方法があります。



スプリングコンテキストを上げることなく、アスペクトとコントローラーに別々のテストを書くことができます（コントローラーのアスペクトを使用してプロキシを作成します。これについては公式ドキュメントで詳細を読むことができます ）。 コントローラと期待どおりに動作します。



アプリケーションの完全なコンテキストを上げるテストを作成できますが、この場合は次のようになります。

• テストは十分に長く実行されます。 すべてのビンが上昇します。
• NPEを同時にスローすることなく、ビン間の呼び出しのチェーン全体を通過できる有効なテストデータを準備する必要があります。

しかし、アスペクトが何を適用し、その仕事をしているかを正確にテストしたいと思います。 コントローラによって呼び出されるサービスをテストしたくないので、テストデータに困惑して起動時間を犠牲にしたくありません。 したがって、コンテキストの一部のみを発生させるテストを作成します。 つまり このコンテキストでは、実際のアスペクトBeanと実際のコントローラーBeanがあり、他のすべてはモカミになります。

モカ豆の作り方

春にモカ豆を作る方法はいくつかあります。 わかりやすくするために、例として、サービスのコントローラーの1つであるPersonalizedHoroscopeTellController



を取り上げます。そのコードは次のようになります。

各テストの依存関係を持つJava Config

各テスト用にJava Configを作成できます。ここでは、コントローラーBeanとアスペクトBean、およびコントローラー依存関係moksを持つBeanの両方を記述します。 Beanの作成方法が明示的にSpringに通知されるため、Beanを記述するこの方法は必須です。



この場合、コントローラーのテストは次のようになります。





このようなテストはかなり面倒に見えます。 この場合、コントローラーごとにJava Configを作成する必要があります。 内容は異なりますが、意味は同じです。コントローラーBeanと依存関係用のmokiを作成します。 したがって、本質的には、すべてのコントローラーで同じになります。 私は、プログラマと同じように怠け者なので、このオプションをすぐに拒否しました。

依存関係のある各フィールドに対する@MockBeanアノテーション

@MockBeanアノテーションは、Spring Boot Testバージョン1.4.0で登場しました。 これはMockitoの@Mockと似ています （実際、内部で使用することさえあります）が、 @MockBean



を使用@MockBean



と、作成されたモックが自動的にスプリングコンテキストに配置される点が異なります。 mokを宣言するこの方法は、これらのmokの作成方法を正確にspringに伝える必要がないため、宣言的です。



この場合、テストは次のようになります。





このオプションにはまだJava Configがありますが、はるかにコンパクトです。 欠点の中でも-コントローラー依存関係を持つフィールド（ @MockBean



アノテーションを持つフィールド）を宣言する必要がありましたが、それらはテストでさらに使用されていません。 何らかの理由でバージョン1.4.0より前のSpring Bootを使用している場合は、このアノテーションを使用できません。



そのため、私は、もう1つのオプションのモーキングのアイデアを思いつきました。 私はそれがこのように働くことを望みます...

依存コンポーネント上の@Automockedアノテーション

@Automocked



アノテーションを@Automocked



したいのですが、これはコントローラーのあるフィールドの上にのみ配置でき、このコントローラーに対して@Automocked



が自動的に作成され、コンテキストに配置されます。



この場合のテストは次のようになります。





ご覧のとおり、このオプションは提示されたものの中で最もコンパクトであり、コントローラーBean（およびアスペクトの述語）のみがあり、 @Automocked



アノテーションが@Automocked



にあり、 Beanを作成してコンテキストに配置するすべての魔法が一度書かれ、すべてで使用できますテスト。

どのように機能しますか？

それがどのように機能し、これに必要なものを見てみましょう。

TestExecutionListener

spring - TestExecutionListenerにはそのようなインターフェースがあります。 たとえば、テストクラスのインスタンスの作成時、テストメソッドの呼び出し前後など、テスト実行プロセスにさまざまな段階で埋め込むためのAPIを提供します。 彼には、すぐに使える実装がいくつかあります。 たとえば、 DirtiesContextTestExecutionListenerは、適切な注釈を付けるとコンテキストをクリーンアップします。 DependencyInjectionTestExecutionListener-テストなどで依存性注入を実行します。 カスタムリスナーをテストに適用するには、その上に@TestExecutionListeners



アノテーションを配置し、実装を示す必要があります。

注文済み

また、春にはOrderedインターフェイスがあります。 オブジェクトを何らかの方法でソートする必要があることを示すために使用されます。 たとえば、同じインターフェイスの複数の実装があり、それらをコレクションに注入する場合、このコレクションではOrderedに従って順序付けられます。 TestExecutionListenerの場合、この注釈は、適用する順序を示します。



そのため、リスナーはTestExecutionListenerとOrderedの 2つのインターフェースを実装します。 AutomockTestExecutionListenerと呼び、 次のようになります。





ここで何が起こっていますか？ まず、 prepareTestInstance()



メソッドで、 @Automocked



アノテーションが付いたすべてのフィールドを検索します。

 for (val field : testContext.getTestClass().getDeclaredFields()) { if (field.getAnnotation(Automocked.class) == null) { continue; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、これらのフィールドを書き込み可能にします。

 makeAccessible(field);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、 findConstructorToAutomock()



メソッドで、適切なコンストラクターを検索します。

 Constructor<?> fallBackConstructor = clazz.getDeclaredConstructors()[0]; for (val constructor : clazz.getDeclaredConstructors()) { if (constructor.getParameterTypes().length > fallBackConstructor.getParameterTypes().length) { fallBackConstructor = constructor; } val autowired = getAnnotation(constructor, Autowired.class); if (autowired != null) { return constructor; } } return fallBackConstructor;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合に適しているのは、 @ Autowiredアノテーションが付いたコンストラクター、または引数の数が最も多いコンストラクターです。



次に、見つかったコンストラクターが引数としてcreateBeanWithMocks()



メソッドに渡され、 createBeanWithMocks()



メソッドがcreateBeanWithMocks()



メソッドを呼び出します。このメソッドでは、コンストラクター引数のモックが作成され、コンテキストに登録されます。

 val constructorArgsAmount = constructor.getParameterTypes().length; for (int i = 0; i < constructorArgsAmount; i++) { val parameterType = forConstructorParameter(constructor, i); val beanName = parameterType.toString(); if (!beanFactory.containsBean(beanName)) { beanFactory.registerSingleton( beanName, mock(parameterType.resolve(), withSettings().stubOnly()) ); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

引数の型の文字列表現が（ジェネリックと一緒に）ビンの名前として使用されることに注意することが重要です。 つまり、タイプpackages.Function<String, String>



引数の場合packages.Function<String, String>



ストリング表現はストリング"packages.Function<java.lang.String, java.lang.String>"



ます。 これは重要です。これに戻ります。



すべての引数のモックを作成してコンテキストに登録した後、依存クラスのBean（つまり、この場合はコントローラー）の作成に戻ります。

 if (!beanFactory.containsBean(beanName)) { val bean = beanFactory.createBean(clazz); beanFactory.registerSingleton(beanName, bean); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、 Order 1900を使用したことに注意してください。 これは、リスナーが新しいビンを作成するため、 DirtiesContextBeforeModesTestExecutionListener 'ohm context（order = 1500）をクリアした後、 DependencyInjectionTestExecutionListener ' th依存性注入（order = 2000）の前にリスナーを呼び出す必要があるためです。

AutowireCandidateResolver

AutowireCandidateResolverは 、 BeanDefinitionが依存関係の説明と一致するかどうかを判断するために使用されます。 彼には、いくつかの実装が「すぐに使える」うちにあります。

• QualifierAnnotationAutowireCandidateResolver-依存関係がQualifier'aに基づいて適切かどうかを判断します。
• GenericTypeAwareAutowireCandidateResolver-ジェネリックに基づいて依存関係が適切かどうかを判断します。
• その他。

同時に、「箱から出して」実装は、継承からのロシアの人形です。 それらは互いに拡張します。 デコレータを作成します。なぜなら より柔軟です。



リゾルバーは次のように機能します。

1. Springは依存関係記述子-DependencyDescriptorを取ります。
   
   
2. 次に、適切なクラスのすべてのBeanDefinitionを取得します。
   
   
3. レゾルバのisAutowireCandidate()
   
   
   
   メソッドを呼び出して、受信したBeanDefinitionsを反復処理します。
   
   
4. Beanの説明が依存関係の説明に適合するかどうかに応じて、メソッドはtrueまたはfalseを返します。
   
   

リゾルバーが必要な理由は何ですか？

次に、コントローラーの例にリゾルバーが必要な理由を考えてみましょう。

 public class PersonalizedHoroscopeTellController { private final HoroscopeTeller horoscopeTeller; private final Function<String, ZodiacSign> zodiacSignConverter; private final Function<String, String> nameNormalizer; public PersonalizedHoroscopeTellController( final HoroscopeTeller horoscopeTeller, final Function<String, ZodiacSign> zodiacSignConverter, final Function<String, String> nameNormalizer ) { this.horoscopeTeller = horoscopeTeller; this.zodiacSignConverter = zodiacSignConverter; this.nameNormalizer = nameNormalizer; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、同じタイプの2つの依存関係-Functionがありますが、ジェネリックは異なります。 1つのケースでは、 StringおよびZodiacSign 、もう1つのケースでは、 StringおよびStringです。 そして、これに関する問題は、 Mockitoがジェネリックを考慮してモックを作成できないことです。 つまり これらの依存関係のmokaを作成してコンテキストに配置すると、Springはジェネリックに関する情報を含まないため、このクラスにそれらを挿入できません。 また、コンテキストにはFunctionクラスのBeanが複数あるという例外があります。 レゾルバの助けを借りて解決するのはまさにこの問題です。 結局、覚えているように、リスナーの実装では、ビンの名前としてジェネリックを持つ型を使用しました。つまり、必要なのは、依存関係のタイプとビンの名前を比較するようにスプリングに教えるだけです。

AutomockedBeanByNameAutowireCandidateResolver

したがって、リゾルバーは上記で説明したとおりの処理を行い、 isAutowireCandidate()



メソッドの実装は次のようになります。





ここでは、依存関係の説明から依存関係タイプの文字列表現を取得し、BeanDefinition（Beanタイプの文字列表現を既に含む）からBean名を取得し、それらを比較し、一致する場合はtrueを返します。 それらが一致しない場合、内部リゾルバに委任します。

ビン湿潤オプションのテスト

合計で、テストでは、ビンの湿潤に次のオプションを使用できます。

• Java Config-定型文を使用する必要があり、扱いにくくなりますが、おそらく、可能な限り有益です。
  
  
• @MockBean
  
  
  
  宣言型であり、Java Configよりも煩雑ではありませんが、テスト自体では使用されない依存関係を持つフィールドの形式で小さな定型文が残ります。
  
  
• @Automocked
  
  
  
  +カスタムリゾルバー-テストおよびボイラープレートの最小限のコードですが、潜在的にかなり狭いスコープであり、これはまだ記述する必要があります。 しかし、スプリングがプロキシを正しく作成することを確認したい場合には非常に便利です。
  
  

デコレータを追加する

私たちのチームは、その柔軟性のためにデコレータのデザインテンプレートを気に入っています。 実際、アスペクトはこの特定のパターンを実装しています。 ただし、注釈付きのSpringコンテキストを構成し、パッケージスキャンを使用する場合、問題が発生します。 コンテキスト内に同じインターフェースの実装が複数ある場合、アプリケーションの起動時にNoUniqueBeanDefinitionExceptionが発生します。 春は、どの豆を注入するべきかを判断できません。 この問題にはいくつかの解決策があり、それらを見ていきますが、最初にアプリケーションがどのように変化するかを考えましょう。



FortuneTellerおよびHoroscopeTellerインターフェースには1つの実装がありますが、各インターフェースにさらに2つの実装を追加します。

• キャッシュ...-キャッシュデコレータ。
  
  
• Logging ...はロギングデコレータです。
  
  

では、Beanの順序を決定する問題をどのように解決しますか？

トップレベルデコレータを使用したJava Config

Java Configを再び使用できます。 この場合、Beanをconfigクラスのメソッドとして記述し、Beanのコンストラクターをメソッドの引数として呼び出すために必要な引数を指定する必要があります。 ビンのコンストラクターが変更された場合、設定を変更する必要がありますが、これはあまりクールではありません。 このオプションの利点：

• デコレータ間の接続性は低くなります。 それらの間の接続は、設定で説明されます。 彼らはお互いについて何も知らないでしょう。
  
  
• デコレータの順序の変更はすべて、1つの場所、つまり構成にローカライズされます。
  
  

この場合、Java Configは次のようになります。





ご覧のとおり、各インターフェイスに対して1つのBeanのみがここで宣言され、メソッドには、内部に作成されたすべてのオブジェクトの依存関係が引数に含まれています。 この場合、Beanを作成するためのロジックはかなり明白です。

予選

@Qualifierアノテーションを使用できます。 これはJava Configよりも宣言的ですが、この場合、現在のBeanが依存するBeanの名前を明示的に指定する必要があります。 欠点が意味するもの：ビン間の接続性の向上。 また、接続性が向上するため、デコレータの順序が変更された場合でも、変更はコード全体に均等に塗りつぶされます。 つまり、たとえばチェーンの途中で新しいデコレータが追加された場合、変更は少なくとも2つのクラスに影響します。





, , ( , FortuneTeller , ), @Primary . internal @Qualifier



, — cachingFortuneTeller . .

Custom qualifier

2.5 Qualifier', . .



enum :

 public enum DecoratorType { LOGGING, CACHING, NOT_DECORATOR }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, qualifier':

 @Qualifier @Retention(RUNTIME) public @interface Decorator { DecoratorType value() default NOT_DECORATOR; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

: , @Qualifier



, CustomAutowireConfigurer , .



Qualifier' :





– , @Decorator



, , – , , FortuneTeller ', – Globa .



Qualifier' - , - . , , . , - – , , .

DecoratorAutowireCandidateResolver

– ! ! :) , - , Java Config', . , - , . :





– Java Config' , – . , !



- . , , , . :

 @FunctionalInterface public interface OrderConfig<T> { List<Class<? extends T>> getClasses(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BeanDefinitionRegistryPostProcessor

BeanDefinitionRegistryPostProcessor , BeanFactoryPostProcessor, , , , BeanDefinition'. , BeanFactoryPostProcessor, .



:

• BeanDefinition';
  
  
• BeanDefinition' , OrderConfig '. , .. BeanDefinition' ;
  
  
• , OrderConfig ', BeanDefinition', , () .
  
  

BeanFactoryPostProcessor

BeanFactoryPostProcessor , BeanDefinition' , . , « Spring-».







, , – AutowireCandidateResolver':

DecoratorAutowireCandidateResolver

:



descriptor' (dependencyType) (dependentType):

 val dependentType = descriptor.getMember().getDeclaringClass(); val dependencyType = descriptor.getDependencyType();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

bdHolder' BeanDefinition:

 val candidateBeanDefinition = (AbstractBeanDefinition) bdHolder.getBeanDefinition();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

. , :

 dependencyType.isAssignableFrom(dependentType)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, , .. .



BeanDefinition' :

 val candidateQualifier = candidateBeanDefinition.getQualifier(OrderQualifier.class.getTypeName());
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

, :

 if (candidateQualifier != null) { return dependentType.getTypeName().equals(candidateQualifier.getAttribute("value")); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

– (), – false.

• , ConfigurationClassBeanDefinitionReader ';
  
  
• , BeanDefintion' Qualifier'. , .
  
  

, :

• Java Config – , , , ;
  
  
• @Qualifier
  
  
  
  – , - ;
  
  
• Custom qualifier – , Qualifier', ;
  
  
• - – , , , .
  
  

結論

, , . – : . , , , . – , JRE. , , .



, – , , - . !



: https://github.com/monosoul/spring-di-customization .