概要
Spirng-AOPモジュールは、Springフレームワークのコアモジュールです。 Spring IOCコンテナはAOPに依存していませんが、AOPはIOCの実装に対する強力で柔軟なソリューションを提供します。
春のフレームワークでは、AOPは主に2つの目的に使用されます。
機能的な観点から、AOPはOOPプログラミング方法の補完と見なされる場合があり、異なるコードまたはシステム組織の方法を提供します。 OOPのコアコンセプトはクラスであり、AOPでは側面です。
Spirng-AOPモジュールは、Springフレームワークのコアモジュールです。 Spring IOCコンテナはAOPに依存していませんが、AOPはIOCの実装に対する強力で柔軟なソリューションを提供します。
春のフレームワークでは、AOPは主に2つの目的に使用されます。
Spring AOPは純粋なJavaに実装されており、特別なコンピレーション処理を必要とせず、クラスローダーの階層を制御する必要はないため、サーブレットコンテナやその他のアプリケーションサーバーに使用できます。
Spring AOPは現在、メソッドレベルの切り替えまたは傍受のみをサポートしており、属性の傍受は現在サポートされていません。属性をインターセプトする場合は、AspectJ言語の使用を検討できます。
スプリングAOPは、他のほとんどのAOPフレームワークとは異なる方法で使用されています。その主な目的は、AOP実装の大規模で包括的なセットを提供することではなく、さまざまなAOP実装を統合し、Spring IOCと協力していくつかの一般的な問題を解決することです。
Spring AOPは、多くの場合、良いサポートを提供しないことが多く、このシナリオはAspectJを考慮していることが多いことに注意する必要があります。それでも、一般的な経験では、Spring AOPの強力なメカニズムは、ほとんどのシナリオで問題を解決できます。
Springの公式文書の元のテキストを引用して、Spring AOPとAspectJをどのように表示する必要がありますか。
Spring AOPは、包括的なAOPソリューションを提供するためにAspectJと競争するのに苦労することはありません。 Spring AOPなどのプロキシベースのフレームワークとAspectJなどの本格的なフレームワークは両方とも価値があり、競争ではなく完全であると考えています。 Springは、Spring AOPとIOCをAspectJとシームレスに統合し、AOPのすべての使用を一貫したスプリングベースのアプリケーションアーキテクチャ内で提供できるようにします。この統合は、Spring AOP APIまたはAOP Alliance APIには影響しません。SpringAOPは後方互換のままです。
すべてのSpring Frameworkモジュール設計では、常に順守されているコア教義の1つは非侵襲的です。
したがって、Spring AOPを使用する場合、特定のクラスまたはインターフェイスをビジネスコードに導入することを強制しません。これにより、コードを清潔に保ち、最大限に切り離すことができます。ただし、Springは別のオプションも提供します。特定のシナリオがある場合は、コードにSpring AOPを直接導入できます。 Spring Frameworksのほとんどすべてのモジュールは、ユーザーがシナリオにより適した方法を選択できるように、使用方法のさまざまな選択肢を提供します。 AspectJまたはSpring AOPを使用し、注釈またはXML構成法を使用し、Uに依存します。
Spring AOPの元の意図と使用法のシナリオを理解した後、その一般的な実装の原則を見てみましょう
ソフトウェアの世界のほとんどの問題は、レイヤーを追加することで解決できます。
ここで言及したレイヤーはもちろん広い意味であり、これは抽象化またはキャッシュである可能性があります。これは、隔離とデカップリングのカテゴリをほぼ意味します。
春の世界では、各モジュールの導入、またはサードパーティテクノロジーの統合は常に抽象化レイヤーを提供し、ユーザーに統一されたAPIを提供し、異なる実装間のすべての実装の詳細と違いをブロックします。たとえば、Spring-Cache、Spring-JDBC、Spring-JMS、Spirngメッセージなどのモジュールはすべて、抽象化の層を提供します。
Spring AOPの実装は、デフォルトでJDKダイナミックプロキシを使用するプロキシベースのメカニズムであり、CGLIBプロキシを使用することもできます。 2つの違いは、主にプロキシされているオブジェクト間の違いです。ターゲットオブジェクトがインターフェイスである場合、JDKダイナミックプロキシはプロキシを完了できますが、ターゲットオブジェクトがインターフェイスクラスを実装しない場合（インターフェイス指向のプログラミングは良い習慣です）、CGLIBプロキシを使用してプロキシを完成させる必要があります。もちろん、インターフェイスにCGLIBをプロキシとして使用するように強制することもできます。さらに、特定のタイプを注入または参照する必要がある場合、参照されるオブジェクトが正確にプロキシオブジェクトである場合、CGLIBメソッドも使用する必要があります。
機能的な設計と実装は、2つの主要な部分に分けることができます
AOPの作成
プロキシオブジェクトを生成するコアクラス、proxyfactorybean getobject（）
次の図は、プロキシを生成するときにJDKまたはCGLIBを使用するかどうかの選択ロジックです。
発電エージェントの特定の執行者を見つけた後、この操作はいつ呼び出されますか？スプリングビーンズのライフサイクルを理解した人は、豆が作成されたときに、ユーザーがカスタム動作を挿入してBeanの特性の一部に影響を与えるための一連のコールバックインターフェイスがあることを知っておく必要があります。 BeanPostProcessorはインターフェイスの1つです。以前の記事が導入されました（スプリングビーンズで遊ぶための究極の武器）。 Spring AOPは、この機会を利用して、豆を作成するプロセスにトリックを挿入しました。作成される豆がAOPターゲットである場合、プロキシを作成し、最後にプロキシオブジェクトをIOCに返します。
AbstractAutoproxyCreatorこのクラスは、プロキシの作成に使用され、このプロセッサの後処理方法を参照し、最後にCreateProxy（）メソッドによって返されたプロキシを返します。
AOPセクションの強化された実行
ターゲットオブジェクト上のすべてのインターセプターチェーンへの呼び出しとして理解できます
Spring AOP、JDK Dynamic ProxyとCGLIBには2つの特定の実装があるため、インターセプターを実行する方法は異なります。詳細については、ソースコードjdkdynamicaopproxy Invokeメソッドを読むことができます
ターゲットメソッドへの呼び出しは、最終的にReflectiveMethodinvocationに依存しています。
ReflectiveMethodinvocationでのプロセス処理は、再帰的な方法を使用してインターセプターチェーンを処理します。
cglibaopproxyの傍受方法
cglibmethodinvocationはreffermemethododinvocationを継承し、上記のプロセス（）メソッドはインターセプターチェーンを処理するために使用されます。
スプリングAOPを使用する場合に注意すべき2つの詳細：
1。SpringAOPは、クラス内のメソッドを呼び出すときに機能しません（セルフインフォーク）。内部呼び出しはプロキシオブジェクトを渡さず、直接使用されるためです。ソリューションは次のとおりです。
2。豆を注入するときは、インターフェイスの代わりに特定のタイプの豆を注入する場合は、cglibを使用します
Spring AOPには、強力な機能と巧妙なデザインがあります。主なコンテキストはここで整理されており、詳細については1つずつ議論されません。
要約します
上記は、この記事のコンテンツ全体です。この記事の内容には、すべての人の研究や仕事に特定の参照値があることを願っています。ご質問がある場合は、メッセージを残してコミュニケーションをとることができます。 wulin.comへのご支援ありがとうございます。