使用する AOP 宣言スタイルの選択

アスペクトが特定の要件を実装するための最良のアプローチであると判断したら、Spring AOP または AspectJ を使用するか、アスペクト言語（コード）スタイル、@AspectJ アノテーションスタイル、Spring XML スタイルの間でどのように決定しますか？ これらの決定は、アプリケーション要件、開発ツール、AOP に対するチームの知識など、多くの要因の影響を受けます。

Spring AOP または Full AspectJ ？

動作できる最も単純なものを使用してください。Spring AOP は、AspectJ コンパイラー / ウィーバーを開発およびビルドプロセスに導入する必要がないため、フル AspectJ を使用するよりも簡単です。Spring Bean での操作の実行のみをアドバイスする必要がある場合は、Spring AOP が正しい選択です。Spring コンテナーで管理されていないオブジェクト（通常はドメインオブジェクトなど）を通知する必要がある場合は、AspectJ を使用する必要があります。また、単純なメソッドの実行以外のジョインポイントをアドバイスする場合は、AspectJ を使用する必要があります（たとえば、フィールドの取得またはジョインポイントの設定など）。

AspectJ を使用する場合、AspectJ 言語構文 (「コードスタイル」とも呼ばれます) または @AspectJ アノテーションスタイルを選択できます。設計でアスペクトが大きなロールを果たし、Eclipse に AspectJ 開発ツール (AJDT) (英語) プラグインを使用できる場合は、AspectJ 言語構文が推奨されるオプションです。言語はアスペクトを書くために意図的に設計されているため、よりクリーンでシンプルです。Eclipse を使用しない場合、またはアプリケーションで主要なロールを果たさないいくつかのアスペクトしかない場合は、@AspectJ スタイルの使用、IDE での通常の Java コンパイルの使用、アスペクトウィービングフェーズの追加を検討することをお勧めします。ビルドスクリプト。

@AspectJ または Spring AOP の XML

Spring AOP を使用することを選択した場合、@AspectJ または XML スタイルを選択できます。考慮すべきさまざまなトレードオフがあります。

XML スタイルは、既存の Spring ユーザーに最も馴染みのあるものであり、正規の POJO によってサポートされています。エンタープライズサービスを構成するためのツールとして AOP を使用する場合、XML が適切な選択になります（適切なテストは、ポイントカット式を構成の一部と見なして、個別に変更する必要があるかどうかです）。XML スタイルを使用すると、システムにどのアスペクトが存在するかが構成から明らかに明確になります。

XML スタイルには 2 つの欠点があります。第 1 に、対応する要件の実装が 1 か所に完全にカプセル化されていません。DRY の原則では、システム内のあらゆる知識について、単一の明確で信頼できる表現が存在する必要があります。XML スタイルを使用する場合、要件がどのように実装されるかについての知識は、バッキング Bean クラスの宣言と構成ファイル内の XML に分割されます。@AspectJ スタイルを使用すると、この情報は単一のモジュールであるアスペクトにカプセル化されます。第二に、XML スタイルは @AspectJ スタイルよりも表現できる内容がわずかに制限されています。「シングルトン」アスペクトインスタンス化モデルのみがサポートされており、XML で宣言された名前付きポイントカットを結合することはできません。例: @AspectJ スタイルでは、次のように記述できます。

  • Java

  • Kotlin

@Pointcut("execution(* get*())")
public void propertyAccess() {}

@Pointcut("execution(com.xyz.Account+ *(..))")
public void operationReturningAnAccount() {}

@Pointcut("propertyAccess() && operationReturningAnAccount()")
public void accountPropertyAccess() {}
@Pointcut("execution(* get*())")
fun propertyAccess() {}

@Pointcut("execution(com.xyz.Account+ *(..))")
fun operationReturningAnAccount() {}

@Pointcut("propertyAccess() && operationReturningAnAccount()")
fun accountPropertyAccess() {}

XML スタイルでは、最初の 2 つのポイントカットを宣言できます。

<aop:pointcut id="propertyAccess"
		expression="execution(* get*())"/>

<aop:pointcut id="operationReturningAnAccount"
		expression="execution(com.xyz.Account+ *(..))"/>

XML アプローチの欠点は、これらの定義を組み合わせて accountPropertyAccess ポイントカットを定義できないことです。

@AspectJ スタイルは、追加のインスタンス化モデルとより豊富なポイントカット構成をサポートします。アスペクトをモジュラーユニットとして維持できるという利点があります。また、Spring AOP と AspectJ の両方が @AspectJ アスペクトを理解できる (したがって消費できる) という利点もあります。そのため、後で追加の要件を実装するために AspectJ の機能が必要であると判断した場合は、従来の AspectJ セットアップに簡単に移行できます。一般に、Spring チームは、エンタープライズサービスの単純な構成を超えたカスタムのアスペクトに @AspectJ スタイルを優先します。