Spring AOPとAspectJを比較する

簡単に言えば、Spring AOPとAspectJには異なる目標があります。

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

これは完全なAOPソリューションとしての使用を意図したものではありません

– それはSpringコンテナによって管理されるbeanにのみ適用することができます。

一方、

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

Spring AOPよりも堅牢ですが、かなり複雑です。 AspectJをすべてのドメインオブジェクトに適用できることも注目に値します。

AspectJとSpring AOPはどちらも、パフォーマンスと使いやすさに関する行動に影響を与えるさまざまな種類のウィービングを使用しています。

AspectJは3種類の織り方を利用します。

私たちのアスペクトと私たちのアプリケーションのソースコードと編まれたクラスを生成します
出力としてのファイル
。

ポストコンパイルウィービング

:これはバイナリウィービングとしても知られています。それは

既存のクラスファイルとJARファイルを私たちのアスペクトで織り込むために使用
。

ロードタイムウィービング

:これは以前のバイナリウィービングとまったく同じです。

クラスローダーがクラスファイルをJVMにロードするまで、ウィービングは延期されるという違い

AspectJ自体に関するより詳細な情報については、/aspectjをリンクしてください。

AspectJはコンパイル時とクラスロード時のウィービングを使用するので、

Spring AOPはランタイムウィービング

を利用します。

ランタイムウィービングを使用すると、JDK動的プロキシまたはCGLIBプロキシのいずれかを使用して、ターゲットオブジェクトのプロキシを使用してアプリケーションの実行中にアスペクトが織り込まれます。

リンク:/uploads/springaop-process.png%201279w[]

Spring AOPはプロキシベースのAOPフレームワークです。つまり、ターゲットオブジェクトにアスペクトを実装するには、そのオブジェクトのプロキシを作成します。これは、2つの方法のいずれかを使用して達成されます。

ターゲットオブジェクトは1つのインタフェースでさえ実装し、その後JDK動的プロキシ
使用されます
。 CGLIBプロキシ – ターゲットオブジェクトがインターフェースを実装していない場合

それからCGLIBプロキシを使用できます

Spring AOPプロキシの仕組みについての詳細はhttps://docs.spring.io/spring/docs/current/spring-framework-reference/core.html#aop-proxying[公式のドキュメント]をご覧ください。

一方、AspectJは、クラスがアスペクトで直接コンパイルされるため、実行時には何もしません。

そのため、Spring AOPとは異なり、デザインパターンを必要としません。コードにアスペクトを織り込むために、AspectJコンパイラ（ajc）と呼ばれるコンパイラを導入し、それを通してプログラムをコンパイルしてから、小さい（<100K）ランタイムライブラリを提供して実行します。

セクション3.3では、Spring AOPがプロキシパターンに基づいていることを示しました。

このため、対象となるJavaクラスをサブクラス化し、それに応じて分野横断的な懸念を適用する必要があります。

しかしそれには限界があります。オーバーライドできないため、実行時例外が発生する可能性があるため、「最終的」なクラスに横断的な懸念（またはアスペクト）を適用することはできません。

静的メソッドと最終メソッドにも同じことが当てはまります。それらをオーバーライドすることはできないため、Springの側面を適用することはできません。したがってSpring AOPはこれらの制限のため、メソッド実行のジョインポイントのみをサポートします。

しかし、AspectJは実行前に横断的な懸念を直接実際のコードに織り込みます。サポートされているジョインポイントの概要は次のとおりです。

| =================================================== = | Joinpoint | Spring AOPサポート| AspectJサポート|メソッド呼び出し|いいえ|はい|メソッド実行|はい|はい|コンストラクタ呼び出し|いいえ|はい|コンストラクタ実行|いいえ|はい|静的イニシャライザ実行|いいえ|はい|オブジェクト初期化|いいえ|はい|フィールド参照|いいえ|はい|フィールド割り当て|いいえ|はい|ハンドラーの実行|いいえ|はい|アドバイスの実行|いいえ|はい| ================== ===================================

Spring AOPでは、同じクラス内で呼び出されるメソッドにアスペクトが適用されていないことも注目に値します。

これは明らかに、同じクラス内のメソッドを呼び出したときに、Spring AOPが提供するプロキシのメソッドを呼び出していないためです。

この機能が必要な場合は、別のBeanに別のメソッドを定義するか、AspectJを使用する必要があります。

Spring AOPは明らかに単純です。ビルドプロセスの間に余分なコンパイラやウィーバーを導入することはないからです。ランタイムウィービングを使用するため、通常のビルドプロセスとシームレスに統合されます。

それは単純に見えますが、それはSpringによって管理されているbeanでのみ機能します。

ただし、AspectJを使用するには、AspectJコンパイラ（ajc）を導入し、すべてのライブラリを再パッケージする必要があります（ポストコンパイルまたはロード時のウィービングに切り替えない限り）。

もちろん、これは前者よりも複雑です。これは、AspectJ Javaツール（コンパイラ（ajc）、デバッガ（ajdb）、ドキュメンテーションジェネレータ（ajdoc）、プログラム構造ブラウザ（ajbrowser）を含みます）を導入しているからです。 IDEかビルドツールのどちらかと統合する必要があります。

パフォーマンスに関しては、** コンパイル時の製織はランタイムの製織よりはるかに高速です。 Spring AOPはプロキシベースのフレームワークなので、アプリケーションの起動時にプロキシが作成されます。また、アスペクトごとにさらに2、3のメソッド呼び出しがあり、これはパフォーマンスに悪影響を及ぼします。

一方、AspectJはアプリケーションが実行される前にアスペクトをメインコードに織り込むので、Spring AOPとは異なり、追加のランタイムオーバーヘッドはありません。

これらの理由から、https://web.archive.org/web/20150520175004/https://docs.codehaus.org/display/AW/AOPベンチマーク[ベンチマーク]によると、AspectJはおよそ8倍から35倍速いという春のAOP