Spring AOPとAspectJ

Spring AOPは、カスタムJava5アノテーションをフレームワークとして使用するため、セキュリティ、ロギング、トランザクションなどのアプリケーション固有のタスクに最適に使用されていると感じています。ただし、AspectJは、より賢明なデザインパターンのようです。

誰かがSpringアプリケーションでSpring AOPとAspectJを使用することのさまざまな長所と短所を強調できますか？

Spring-AOPプロ

• LTW（ロード時ウィービング）またはAspectJコンパイラーを使用する必要がないため、AspectJよりも使用が簡単です。

• プロキシパターンとデコレータパターンを使用します

Spring-AOPの短所

• これはプロキシベースのAOPであるため、基本的にはメソッド実行ジョインポイントのみを使用できます。
• 同じクラス内で別のメソッドを呼び出す場合、アスペクトは適用されません。
• 実行時のオーバーヘッドが少し発生する可能性があります。
• Spring-AOPは、Springファクトリによって作成されていないものにアスペクトを追加できません

AspectJプロ

• これはすべてのジョインポイントをサポートします。つまり、何でもできるということです。
• 実行時のオーバーヘッドは、Spring AOPよりも少なくなります。

AspectJの短所

• 注意してください。あなたのアスペクトがあなたが織りたいと思っていたものだけに織り込まれているかどうかチェックしてください。
• AspectJコンパイラーで追加のビルドプロセスが必要か、LTW（ロード時ウィービング）をセットアップする必要がある

他の人が述べたこととは別に-言い換えればthere are two major differences：

1. 1つは、織りのタイプに関連しています。
2. ジョインポイント定義のもう1つ。

Spring-AOP：プロキシを介したランタイムウィービングのコンセプトを使用dynamic proxy if interface exists or cglib library if direct implementation provided.

AspectJ：AspectJ Java Tools(ajc compiler)ソースが利用可能な場合はコンパイル時のウィービング、またはコンパイル後のウィービング（コンパイル済みファイルを使用）。また、Springを使用したロード時のウィービングを有効にできaspectjます。これには、定義ファイルが必要であり、柔軟性があります。

コンパイル時のウィービングはパフォーマンス（場合によっては）の利点を提供し、さらに joinpoint definition in Spring-aop is restricted to method definition only which is not the case for AspectJ.

追加の注記：高負荷でのパフォーマンスが重要な場合は、Spring AOPより9〜35倍速いAspectJが必要です。10ns対355nsはそれほど聞こえないかもしれませんが、たくさんのアスペクトを使用している人を見てきました。10K相当のアスペクト。このような場合、リクエストは数千の側面に影響を与える可能性があります。その場合、そのリクエストにmsを追加します。

ベンチマークをご覧ください。

春のユーザーマニュアルは、馬の口から直接、多くの情報を提供します。

6.4章-どちらのAOP宣言スタイルを使用するかの選択は、両方の長所と短所について説明しているので、あなたにとってはもう終わりです。

段落6.1.2-Spring AOPの機能と目標と章6.2-@Aspectサポートおよび6.8-SpringアプリケーションでのAspectJの使用は特に興味深いはずです。

Spring AOPは、Springフレームワークの重要な部分の1つです。非常に基本的な段階では、春のフレームワークはIoCとAOPに基づいています。春の公式コースには、次のようなスライドがあります。

AOPはフレームワークの最も重要な部分の1つです。

SpringでAOPがどのように機能するかを理解するための重要な点は、Springでアスペクトを作成するときに、オブジェクトのプロキシを構築してフレームワークをインストルメント化することJDKDynamicProxyです。インターフェース。バージョン3.2より前のSpringを使用している場合は、クラスパスにcglib 2.2が必要であることに注意してください。Spring 3.2以降では、cglib 2.2がコアに含まれていたため、それは役に立たない。

Bean作成時のフレームワークは、オブジェクトをラップするプロキシを作成し、セキュリティ、トランザクション管理、ロギングなどの横断的な懸念事項を追加します。

この方法でのプロキシ作成は、フレームワークをインスツルメントして、どのBeanとメソッドをプロキシとして作成するかを決定するポイントカット式から始めて適用されます。アドバイスはあなたのコードよりも責任があります。このプロセスでは、ポイントカットはfinalとして宣言されていないパブリックメソッドのみをキャプチャすることに注意してください。

これで、Spring AOPでは、アスペクトのウィービングはコンテナの起動時にコンテナによって実行されますが、AspectJでは、バイトコードの変更によるコードのポストコンパイルでこれを実行する必要があります。このため、私の意見では、SpringのアプローチはAspectJよりも単純で扱いやすいです。

一方、Spring AOPでは、コードの変更ではなくプロキシを介して実装が行われるため、AOPのすべての機能を使用することはできません。

AspectJと同様に、SpringAOPでロード時ウィービングを使用できます。春にこの機能を利用すると、エージェントと特別な構成、@EnabledLoadWeavingまたはXMLで実装されます。名前空間を例として使用できます。ただし、Spring AOPでは、すべてのケースを傍受することはできません。たとえば、このnewコマンドはSpring AOPではサポートされていません。

ただし、Spring AOPでは、Spring aspectof構成Beanでファクトリーメソッドを使用することにより、AspectJの使用から利益を得ることができます。

Spring AOPは基本的にコンテナから作成されたプロキシであるため、Spring Beanに対してのみAOPを使用できます。AspectJを使用すると、すべてのBeanでアスペクトを使用できます。比較のもう1つのポイントは、デバッグとコードの動作の予測可能性です。Spring AOPでは、ジョブはすべてJavaコンパイラーから実行され、アスペクトはSpring Beanのプロキシを作成するための非常に優れた方法です。AspectJでは、コードを変更する場合、より多くのコンパイルが必要であり、アスペクトが織り込まれている場所を理解することは難しい場合があります。Springでウィービングをシャットダウンすることも簡単です。Springを使用すると、構成からアスペクトを削除し、再起動すると機能します。AspectJでは、コードを再コンパイルする必要があります！

読み込み時のウィービングでは、SpringはAspectJのすべてのオプションをサポートしていないため、AspectJはSpringより柔軟です。しかし、私の意見では、Beanの作成プロセスを変更したい場合は、新しいオペレーターの動作を変更するアスペクトのロード時のウィービングではなく、ファクトリーでカスタムログインを管理する方が良いでしょう。

AspectJとSpring AOPのこのパノラマが2つの部分の違いを理解するのに役立つことを願っています

アスペクトがミッションクリティカルになるかどうか、およびコードがデプロイされる場所を検討することが重要です。Spring AOPは、ロード時のウィービングに依存していることを意味します。これは織りに失敗する可能性があり、私の経験では、ログに記録されたエラーが存在する可能性があることを意味しますが、アスペクトコードなしでアプリケーションが実行されるのを妨げることはありません[これができないように構成することが可能な場合があるという警告を追加します場合; しかし、私はそれを個人的に知りません。コンパイル時のウィービングはこれを回避します。

さらに、AspectJをaspectj-maven-pluginと組み合わせて使用​​すると、CI環境でアスペクトに対してユニットテストを実行でき、ビルドされたアーティファクトがテストされ、正しく織り込まれていることを確信できます。Spring駆動の単体テストを確実に作成できますが、デプロイされたコードがLTWが失敗した場合にテストされたものであるという保証はありません。

別の考慮事項は、サーバー/アプリケーションの起動の成功または失敗を直接監視できる環境でアプリケーションをホストしているかどうか、または監視下にない環境にアプリケーションがデプロイされているかどうかです。クライアントによってホストされています]。繰り返しますが、これは時間織りをコンパイルする方法を示します。

5年前は、操作が簡単で、IDEを起動する可能性が低いという単純な理由から、Springで構成されたAOPのほうがはるかに好きでした。ただし、コンピューティング能力と使用可能なメモリが増加したため、これは問題のはるかに少なくなり、上記で概説した理由に基づいて、aspectj-maven-pluginを使用したCTWが私の作業環境でより良い選択になりました。

この記事では、このトピックについても説明しています。

Spring AOPとAspectJの目標は異なります。

Spring AOPは、プログラマーが直面する最も一般的な問題を解決するために、Spring IoC全体にシンプルなAOP実装を提供することを目的としています。

一方、AspectJは完全なAOPソリューションを提供することを目的とした独自のAOPテクノロジーです。

AOPと比較すると、AspectJはコンパイル時にターゲットクラスを拡張する必要がありません。代わりに、実行時にターゲットクラスのプロキシクラスを生成します。これは、ターゲットクラスと同じインターフェイスを実装するか、ターゲットクラスのサブクラスです。

要約すると、プロキシクラスのインスタンスは、ターゲットクラスのインスタンスとして使用できます。一般に、実行時拡張AOPフレームワークは実行するたびに動的な拡張が必要になるため、コンパイル時拡張AOPフレームワークの方がパフォーマンスの点で有利です。