今、私はめちゃくちゃです。私はそれらすべてを混ぜるかもしれません。堅牢なコードと安定した方法論を構築したいのですが、何を使用すればよいですか?
すべては、優れたアプリケーション設計から始まります。アプリケーションの設計が正しければ、UI フレームワークが公開する AOP のような機能を操作する理由はほとんどなくなります (これは WCF にも当てはまります)。
たとえば、すべてのビジネス ロジックをジェネリック インターフェイスの背後に隠してコマンド メッセージを渡すと (この記事 を参照)、コントローラーはシン ラッパーになり、多くの場合、そのようなビジネス コマンドを実行する以上のことはしません。その場合、これらのビジネス オペレーションをラップすることで承認と例外フィルタリングを実装し、UI コードをクリーンで属性から解放することができます。これらの分野横断的な懸念事項をビジネス オペレーションにラップすることは、インターセプトまたは単純な古いデコレータの両方で行うことができます。これにより、柔軟性が大幅に向上し、設計が堅固に保たれます(長期的な利点はあまり明白ではありません)。
PostSharp などのコード ウィービング ツールも使用できますが、注意が必要です。コンパイル後のプロセスを使用して、コードをアセンブリに挿入します。これにより、これらの側面に影響を与えずにこれらのクラスを単体テストすることは非常に困難になります。これらのクラスを分離して簡単にテストすることはできません (これは単体テストの前提条件です)。アスペクトを静的変数に依存させると、アスペクトと単体テストの両方が複雑になります。静的変数を使用すると単体テストを並行して実行することが難しくなり、グローバル定数を使用すると、変更されたグローバル設定をテストで正しく分解して、他のテストが影響を受けないようにする必要があります。
コード ウィービング ツールを使用すると、多くの場合、インターセプトよりも優れたパフォーマンスが得られますが、デコレーターを使用した場合と比較してパフォーマンスが向上することはありません。
あなたは、既存のコードベースを変更せずに機能を追加するという、同じことを意図した 3 つのテクノロジーを挙げました。
ASP.NET MVC と DI はどちらも、アスペクト (名前付きフィルターまたはインターセプター) を持つことができる場所に制限を設けています。これは、テクノロジがコードを編集できないため、一部の場所でのみ動作を追加できるためです。PostSharp などのコンパイラ ベースのテクノロジだけが、あらゆる場所にアスペクトを追加することができます。ただし、3 つすべてが AOP の概念の実装です。
アスペクトは、多くのユースケースで、従来のオブジェクト指向プログラミングよりも優れていることが証明されています。同じコストでより良い設計の従来の OOP ですべての問題を解決できるというのは真実ではありません。ただし、AOP が主流ではなく、主流ではないテクノロジの使用に関連するコストとリスクがあることは正しいです (AOP は 90 年代に生まれ、OOP は 60 年代に生まれました)。あらゆるイノベーションと同様に、さまざまなアクターはリスクとメリットに対する感受性が異なるため、アーリー アダプターまたはレイト アダプターになる可能性があります。
AOP は単体テストの障害にはなりませんが、このトピックに関する共有経験はほとんどありません。一般に、アスペクトは個別のコード単位としてテストする必要があります。本質的な側面とそうでない側面があります。通常、ビジネス コードは重要な側面と一緒にテストする必要がありますが、重要でない側面は無効にする必要があります。ビルド時に静的にアスペクトを無効にする (ビルド構成から一部のアスペクトを除外するだけ)、または実行時にアスペクトを無効にする (テスト中に false に設定した静的変数にアスペクトを依存させる) ことができます。