AOP対MVC FilterAttributes対インターセプタ

Question

1. ASP.NET MVCは、組み込みのAuthorization、Action、Result、Exceptionフィルタを使用または拡張することを提案しています。
2. サードパーティのAOPツール（Postsharp）は、それらの属性を提案しています。インターセプタは、IoCコンテナ（Unity、Ninject、Autofac）によって提案されています。

今、私はうんざりです。私はそれらのすべてを混ぜるかもしれない。 堅牢なコードと安定した方法論を構築したいのですが、どうすればいいですか？

Answer 1

すべては、アプリケーションの設計が優れていることから始まります。アプリケーションのデザインが正しい場合、UIフレームワークが公開するAOPのような機能（WCFでも同様です）とやりとりする理由はあまりありません。

たとえば、汎用インターフェイスの背後にあるすべてのビジネスロジックを非表示にしてコマンドメッセージを（this articleに示すように）渡すと、コントローラはそのようなビジネスコマンドを実行するだけではないシンラッパーになります。その場合、これらのビジネスオペレーションをラップし、UIコードをクリーンで属性から解放して、認可と例外のフィルタリングを実装することができます。事業横断的な懸案事項を包括するのは、傍受またはplain old decoratorsの両方で行うことができます。これにより、はるかに柔軟性が増し、デザインを維持するSOLID（長期的にはあまり明らかではない）

ポストシャープのコードウィービングツールが使用されていますが、注意が必要です。ポストコンパイルプロセスを使用してコードをアセンブリに挿入します。これは、それらのクラスに当てはまることなく、それらのクラスを単体テストすることに非常に苦労します。これらのクラスを単独で簡単にテストすることはできません（これは単体テストの前提条件です）。アスペクトをいくつかの静的変数に依存させることは、アスペクトと単体テストの両方を複雑にします。静的変数は単体テストを並行して実行するのを困難にします。グローバル定数を使用するには、変更されたグローバル設定を正しく破棄して他のテストに影響を与えないようにテストする必要があります。

コードウィービングツールは、傍受よりもパフォーマンスが高くなることがありますが、デコレータの使用に比べてパフォーマンスは向上しません。

Answer 2

既存のコードベースに変更を加えずに機能を追加するという、3つのテクノロジがすべて同じことを意図しています。

ASP.NET MVCとDIの両方で、に制限があります。では、コードを編集できないため、テクノロジがいくつかの場所で動作を追加できるため、名前付きフィルタまたはインターセプタを使用できます。 PostSharpなどのコンパイラベースのテクノロジだけが、あらゆる側面を追加できます。しかし、3つはすべてAOPの概念の実装です。

多くの用途では、従来のオブジェクト指向プログラミングに比べ、さまざまな利点があります。すべての単一の問題は、同じコストでより優れた設計の従来のOOPによって解決できるということは当てはまりません。しかし、AOPは主流ではなく、非主流技術（AOPは90年代に生まれ、OOPは60年代に生まれた）を使用することに関連するコストとリスクがあることは間違いありません。どの革新と同様に、異なるアクターはリスクと利益の感受性が異なるため、早期または後期の採用者になる可能性があります。

AOPは単体テストの障害ではありませんが、トピックに関する共通の経験はほとんどありません。一般に、アスペクトは別々のコード単位としてテストする必要があります。本質的かつ不可欠な側面があります。通常、ビジネスコードは必須の側面とともにテストする必要がありますが、非本質的な側面は無効にする必要があります。アスペクトをビルド時に静的に無効にすることができます（ビルド構成から一部のアスペクトを除外するだけです）。または実行時に（アスペクトをテスト中にfalseに設定する静的変数に依存させます）。