私は、セキュリティ、ロギング、検証などのクロスカッティングに関するいくつかの基本的なAOPスタイルのソリューションを使用してきました。私の解決策はCastle WindsorとDynamicProxyです。私はBooベースのDSLを使用してすべてを適用できるので、このルートを辿りました。私は週末にPostSharpを見て "より良い"解決策になっていると言われました。私はPostSharpをすばやく見てきましたが、私は属性の使用法を控えています。AOPを適用する
誰もが両方のソリューションを試してみて、自分の経験を共有しようと思いますか？
私はちょっと城ウィンザーを見ました（まだ）ので、私はそれについてコメントすることはできませんが、私はポストシャープを使いました。
ポストシャープはコンパイル時に製織して動作します。それはあなたのコードを変更するビルドにポストコンパイルのステップを広告します。コードは、クロスカットの問題をコードにプログラミングしたようにコンパイルされます。これは、ランタイムウィービングよりもやや優れています。また、属性を使用するため、Postsharpは使いやすいです。私はAOPのための属性の使用は、DIのためにそれを使用するのと同じように問題ではないと思います。しかし、それは私の個人的な好みです。
しかし...
すでに依存性注入のための城を使用している場合、私はあなたにもAOPのもののためにそれを使用してはならない正当な理由が表示されません。私は、実行時のAOPはコンパイル時よりも少し遅いものの、より強力であると思います。 AOPとDIは私の意見に関連した概念なので、私は両方のフレームワークを使うことをお勧めします。だから私はおそらくAOPが必要な次のプロジェクトを再び城のものを見てみましょう。 PostSharpとマイナーな問題の
カップル...私はPostSharpを持っていた
1つの問題は、asp.netを使用しながら、例外メッセージの行番号がに注入IL命令の数によって「アウト」しているということですPDBsも注射されていないので、PostSharpによるasssemblies :-)
また、PostSharpアセンブリを実行時に使用できないと、実行時エラーが発生します。ウィンザーを使用すると、後でコードの再コンパイルなしにクロスカットをオフにすることができます。
（これは理にかなって願っています）
これは私が出くわし、私はちょうどPostSharpは今、実際にPDBファイルを変換しないことに注意したいかなり古い答えなので、デバッグの問題はもうありません（参照： http://stackoverflow.com/questions/2006508/postsharp-pdb-debugging-and-referenced-assemblies） –