2

.NET 3.5 では、System.Reflection を使用して AOP (おそらく Castle のウィンザー インターセプターのコンテキストで) を使用して、メソッド レベルで実行する必要があるセキュリティ アクションを定義するなどの作業を行う予定です。 Reflection の一部が遅いと聞き (MSDN の記事を読んだことがあります)、これらの部分をキャッシュしたいと考えています (製品コードに近づいたら、ともかく)。私のアプローチを検証したいと思います：

  • キャッシュ キーは {type} + {大文字と小文字を区別するメソッド名} + {パラメーター タイプのリスト} です。
  • キャッシュ キー オブジェクトは、Equals 操作を介して比較できます
  • キャッシュ ペイロードは {MethodInfo} + {メソッドで定義されたカスタム属性のリスト} です。
  • キャッシュは、コンストラクター注入を介してインターセプターに注入されます
  • キャッシュは長期間維持できます (自己変更コードを書くつもりはないという仮定に基づいています ;-) )

アップデート：

自分で書いたリフレクションを介してメソッドを呼び出すつもりはありません。（現時点では）機能を注入したい属性の属性を調べてください。ここで、属性は注入する動作を定義します。私のインターセプターは、現時点では、変更する理由がわかるまで、Castle の Windsor IInterceptor メカニズムを使用する予定です。

4

2 に答える 2

3

MethodInfo を明示的に呼び出すのは確かに遅いですが、それをデリゲートに変換すると、はるかに高速化できます。たとえば、このブログ投稿を参照してください。もちろん、メソッドを見つけるなどの点では役に立ちませんが、メソッドを繰り返し呼び出す場合は、覚えておく価値があります。

キャッシュ キーは簡単に作成できるように思えます。型と文字列を簡単に比較できます。値は常に比較的単純です:)

キャッシュが構築されると、読み取り専用になりますか? 完全に構築される前に読み取られないことを保証できるように、フェーズを分離できますか? もしそうなら、明示的なロックなしで逃げることができるはずです - 基本的にカスタムキータイプからカスタム値タイプへの辞書。

于 2008-10-11T09:07:31.513 に答える
1

ジョンの投稿のほとんどに同意します-辞書に関する小さなメモ:パフォーマンスの観点から、これと単なるフラットリストをベンチマークすることをお勧めします。前回ベンチマーク (辞書とフラット リスト、一致が見つかるまで各項目をチェック) を行ったとき、分割点 (読み取りアクセスの場合) は約 150 項目でした。その下では、リストはより高速でした (単に単純化しただけです)。ただし、独自のテストを行ってください...（何らかの方法で証明するための数値はありません）。

コードによっては、ジェネリックを使用してデータをさらに分割できる場合があります。つまり、タイプ T のすべての情報が 1 つの場所にあり、キャッシュの静的 ctor に入力されるようにキャッシュを使用できます。これは、アーキテクチャに応じて、可能な場合と不可能な場合があります。

最後に、適合する場合も適合しない場合もありますが、PostSharp のような既存の AOP フレームワークがあり、注入ポイントを簡素化するのに役立ちます。

一般的なポイントについて - (init コードで) Cache メソッドのメソッドに型指定されたデリゲートを作成して、スキャンする必要があるデータの量を減らすのはかなり簡単です - Type.MakeGenericType とそしてDelegate.CreateDelegate - この時点以降、コードは Func<...> デリゲートを認識するだけで、実装を気にする必要はありません。

于 2008-10-11T14:44:20.617 に答える