PostSharp、bltoolkit、Castle、Cecil、Microsoft の Policy Injection Block など、よく知られている .Net 用の AOP 指向のフレームワークをいくつか見てきました。おそらく私は無知ですが、これらのフレームワークは、クラスが仮想マシンによってロードされている間、アプリケーションに表示される前にコードを挿入する機能を提供していないようです。それらはすべて、アセンブリのコンパイル時の操作に必要なメタデータを提供するファクトリまたはクラス/メソッド レベルの属性のアプリケーション使用に依存しているようです。私が探している java.lang.instrumentの重要な機能は、ソース (メソッド/クラスの属性) を変更したり、既存のアセンブリを再構築してインターセプト コードを挿入したりせずに、メソッド呼び出しの周りにインターセプターを単純に挿入することです。
2 に答える
.NET 用のほとんどの AOP フレームワークでは、特殊な種類のファクトリなどを使用してオブジェクトを作成する必要があることは間違いありません。その理由は、.NET の (カスタム) 属性は受動的であるため、それらの属性をタイムリーに検査できる何らかのフレームワークが必要になるためです。
コード生成または IL ウィービング (通常のコンパイル後の中間言語バイト コードの変更) のいずれかを使用してインターセプトを許可する .NET 用の AOP フレームワークがいくつかありますが、私は常にそのようなことには近づきません。そのようなアプローチ。
私はかつて Anders Hejlsberg に .NET で「アクティブな」属性を取得できないかどうか尋ねる機会がありましたが、彼の応答は、Microsoft がそのような機能を提供する場合、プラットフォームの今後の開発をすべて停止する可能性があるというものでした。誰かのコードとの互換性を損なうことなく.NETを前進させることは不可能です(私は彼の答えを誤解しているかもしれませんが、本質的な部分はそれが検討され、拒否されたということです-明らかに正当な理由で).
つまり、.NET には、あらゆるメソッド呼び出しをインターセプトできるインストルメンテーション API があります。ただし、その API はアンマネージド API (アンマネージド C++ コードを記述する必要があります) であり、(IIRC) では .NET アプリを自分でホストする必要があります。これは非常に手の込んだアプローチです。また、インストルメンテーションがアプリケーションのパフォーマンスを損なう可能性があることにも注意してください。
IoC フレームワークの比較という記事を見たことがありますか?