職場の同僚と話し合いました:プロキシオブジェクトが @AOP に登場するため、AOP が DI に多少似ている場合、私たちは混乱しました。
http://www.postsharp.net/blog/post/Anders-Hejlsberg-Dead-Body.aspx
すべての依存性注入フレームワークには、AOP のような機能がいくつか付属しています。インターフェイスの実装が必要な場合、実装自体を受け取るのではなく、代わりにプロキシ (DynamicProxy と呼ばれる) を受け取ります。このプロキシは、最終的な実装。
It looks like AOP, it smells like AOP,しかし、本格的な AOP フレームワークとは比べ物になりません。
依存性注入を使用すると、動的プロキシに基づく AOP が使いやすくなり、自然な道筋になると言えます。
ただし、AOP をまったく使用せずに依存性注入を使用することも、依存性注入を使用せずに AOP を使用することもできます。ところで、プロキシは AOP を実装するためだけに使用されるのではなく、循環依存関係を解決したり、スコープの小さいオブジェクト (リクエスト スコープのオブジェクトなど) をスコープの大きいオブジェクト (シングルトン スコープのオブジェクトなど) に挿入したりするためにも使用されます。
いいえ：
1) 依存性注入ツール (Inversion of Control コンテナー)には AOP/傍受ツールが付属していることがよくあります (たとえば、Castle Windsor には Castle DynamicProxy が付属しています)。
2) AOP ツールは、依存性注入なしで使用できます。たとえば、PostSharp は、使用する IoC ツールに関係なく、単独で動作します。別の例: IoC コンテナーなしで Castle DynamicProxy を使用できますが、必要なシナリオはあまり想像できません。
(私はJavaツールに精通していないため、私の回答で.NETツールを使用して申し訳ありません)。
DI を使用すると、AOP がより自然になります。プロキシを使用してこれを行うことができますが、私の個人的な好みは、古き良きデコレータを適用することです。
AOP のように見え、AOP の匂いがしますが、本格的な AOP フレームワークとは比べ物になりません。
私はこの声明の著者に心から同意しません。私の経験では、PostSharp のようなツールを使用すると、アプリケーションの設計上の欠陥を回避できます。これにより、これらのツールは、レガシー アプリケーションや変更できない設計 (たとえば、INotityPropertyChangedインターフェイスの処理など) を処理するときに非常に強力になります。ただし、これらのツールを使用すると、設計を修正せずに AOP 機能を追加できますが、これらの設計上の欠陥は、プロジェクトの存続期間中ずっと悩まされます。
簡単な例の 1 つは、テスト容易性です。このようなツールは、依存性注入パターンが解決するアプリケーションのテスト容易性には対応していません。これらのツールはコンパイル時にアスペクトを織り込むため、アスペクトなしでコードをテストすることは非常に困難になります (これは、単体テストを行うときや、場合によっては統合テストを行うときにも行う必要があることです)。コンパイラ ディレクティブを使用して巧妙なトリックを実行する必要がありますが、これは問題の一部を解決するだけです。これらの側面をテストしたいのですが、コードのすべての部分を分離してテストしたいのと同じように、分離してテストしたいからです (それがユニットです)。テストは約です）。解決できたとしても、コードの保守は依然として困難です。その保守不可能なコードは、設計上の欠陥が原因です。
記事の著者は次のように述べています。
最初の問題は、動的プロキシでは、インターフェイスとして公開することを選択したサービスの明示的な境界にのみ側面を追加できることです。プライベート メソッドまたは静的メソッドにアスペクトを追加することはできません。たとえそうしたかったとしてもです。
彼はこれについて完全に正しいですが、private メソッドまたは static メソッドに側面を追加したい場合は、設計に何か問題があります: 設計を修正してください!
2 番目の問題は、より劇的です。AOP のいくつかの利点に夢中になると、依存性注入が必要ない場合でも動的プロキシを使用し始め、動的プロキシの要件のためだけにコードのアーキテクチャを変更します。そして、これは間違っています。AOP では、コードのアーキテクチャを変更する必要はありません。
PostSharp を使用する場合、AOP のアーキテクチャを変更する必要はありません。しかし、デザインが間違っていると、PostSharp などのツールを使用しても、アスペクトを適用することはさらに難しくなります。また、PostSharp を使用した属性のない AOP は、商用バージョンを使用している場合にのみ可能であることを忘れないでください。属性を使用して AOP を適用すると、高い結合とメンテナンスの問題が発生します。すべての DI ツール (少なくとも .NET 用) は無料で使用でき、属性のない使用がデフォルトです。
優れた設計のための代替手段はありません。PostSharp のような正しい設計ツールを使用すると、ほとんどの場合冗長になります。一部のエッジケースでは依然として有益です（これらのケースでは非常に有益です）が、私の経験では、デザインがSOLIDの場合、これらのケースはまれです。
ここで問題は明らかに次のようになります: 優れた SOLID 設計とは? すべてのアプリケーションに適用できる、既製の常に有効な設計などありません。私が設計するすべてのアプリケーションは異なりますが、ここ数年、あなたにも有益かもしれない特定の繰り返しパターンを見てきました。これについては、過去にここ、ここ、およびここに書いています。これらの記事で説明されているパターンは、私が設計と構築を支援する多くのアプリケーションの基本的な構成要素になっています。これらのパターンの重要な要素は SOLID です。