8

私は、AssemblyInfo.csにいくつかの属性があり、特定のクラスのメソッドにマルチキャストされているプロジェクトに取り組んでいます。

[assembly: Repeatable(
AspectPriority = 2,
AttributeTargetAssemblies = "MyNamespace",
AttributeTargetTypes = "MyNamespace.MyClass", 
AttributeTargetMemberAttributes = MulticastAttributes.Public,
AttributeTargetMembers = "*Impl", Prefix = "Cls")]

これについて私が気に入らないのは、AssemblyInfo（Info、気をつけてください！）にロジックの一部を配置することです。これは、初心者にとってはロジックをまったく含まないようにする必要があります。その最悪の部分は、実際のMyClass.csがファイルのどこにも属性を持たないことであり、このクラスのメソッドがそれらを持っている可能性があるかどうかは完全に不明です。私の見解では、コードの可読性が大幅に低下します（PostSharpを使いすぎると、デバッグが悪夢になる可能性があることは言うまでもありません）。特に、複数のマルチキャスト属性がある場合はそうです。

ここでのベストプラクティスは何ですか？このようなPostSharp属性を使用している人はいますか？

4

2 に答える 2

13

最初にMaxに答えさせてください。確かに、アスペクトは優れたOOPパターンに代わるものではありません。それらは補完です。優れたAOP設計は、優れたOOP設計から始まります。ただし、OOPパターンでは、多くの配管コードを手動で作成しなければならない場合があります。このような場合、アスペクトを使用して、OOPパターンの実装を自動化することができますが、それらを置き換えることはできません。

AOPをインテリジェントに使用すると、ソリューションの理解（ビジネスコードとメンテナンスコードが混在していない）、テスト（ビジネスコードとは別にアスペクトをテストできる、つまりビジネスメソッドのトレースをテストする必要がない）が容易になります。適切に）、変更します（パターンのすべての実装を変更するのではなく、パターンを変更するときにアスペクトを変更する必要があります）。さて、AOPを悪用したり、ハッキングツールとして使用したり、以前にOOPパターンを考慮していなかったりすると、AOPのメリットよりも多くのコストが発生します。他の鋭いツールと同様に、AOPはインテリジェントに使用する必要があります。

元の質問に戻ります。

AssemblyInfo.csにアスペクトを配置する必要があると誰が言いますか？GlobalAspects.csという名前の新しいファイルを作成し、そこにすべてのアセンブリレベルのアスペクトを配置できます。確かに、AssemblyInfo.csはアセンブリレベルのメタデータ用である必要があります。

しかし、あなたのように、私はアセンブリレベルの側面が好きではありません。避けるべきだと思います。アセンブリレベルの側面の主な問題は、命名規則に依存していることであり、これは悪です。（この悪は、アカデミックAOSDコミュニティではポイントカットの脆弱性と呼ばれます。）実際、クラスまたは名前空間の名前を変更すると、アスペクトが適用されるメソッドのセットが変更され、これはすぐに悪夢になる可能性があります。そのため、命名規則に基づくアスペクトを自分で使用することはありません。

コードの可読性はどうですか？かなりの程度、読み取り可能なコードはショートコードだと思います。CreateProductというビジネスメソッドがある場合は、製品を作成するコードだけを確認したいと思うでしょう。ほとんどの場合、トランザクション、例外、またはトレースを処理するコードには興味がありません。いくつかの側面が私のためにそれを処理することを知っていれば十分です。

そして、どうすればわかりますか？PostSharpを使用すると、VisualStudioExtensionを使用できます。AspectJを使用すると、Eclipse用のAspectJプラグイン（AJDT）を使用できます。これらは、IDE内で、現在表示されているコードにどの側面が適用されているかを示します。また、本当に詳細を確認したい場合（ただし、実際に確認することはめったにありません）、デバッガーを使用してアスペクトにステップインするか、Reflectorを使用して生成されたコードを確認できます。

概要：

  1. 優れたAOP設計は、常に優れたOOP設計から始まります。
  2. アスペクトを適用するために命名規則に依存することは避けてください。
  3. Visual StudioまたはAJDTのPostSharp拡張機能を使用して、コードの側面を視覚化します。
于 2010-03-22T07:32:06.120 に答える
0

これは人気のない答えになると確信していますが、仲間からのプレッシャーバッジを取得できるかもしれません...

あなたの本能は正しいです。あらゆる種類のメタデータにロジックを配置することは、維持不可能な地獄の火の中で永遠に燃える恐ろしい、恐ろしい罪です。

私はそれが別の方法で解釈されると確信していますが、これによって軽視されていないことを意味します。

ベストプラクティスは、「アスペクト指向のプログラミング」ツールを使用しないことです。これは、不十分な設計とテストの実践の跛行を可能にする松葉杖です。代わりに、あなたのデザインを見て、「なぜ」と自問してください。

このツールを使用する必要性を感じたのはなぜですか？どのような設計上の問題を解決しようとしていましたか？

問題をしっかりと把握したら、説明されたデザインパターン（Shalloway＆Trott）またはHead First Design Patterns（Freeman、Robson、Bates、およびSierra）を取り上げます。

最終的に、パターン指向のソリューションは、理解しやすく、テストしやすく、変更しやすくなります。唯一の追加コストは、これらすべての側面がどこにあるか、それらがどのように組み合わされているか、変更を加えるたびにそれらが互いにどのように影響するかを把握しようとする繰り返しの料金の代わりに、デザインパターンを習得するための1回限りの料金です。

于 2010-03-22T06:22:16.440 に答える