問題タブ [castle-dynamicproxy]

MVC3 に移行した後、Autofac 2.4.4 に更新しましたがEnableInterfaceInterceptors、登録に含めると例外が発生します。DependencyResolver.Current.GetService<ISite>()が呼び出されるまで、例外は表示されません。

例外：

登録：

注: Castle の異なるバージョンでの競合に対処するために、 と で ILMerge を実行しましAutofacContrib.DynamicProxy2.dllたCastle.Core.dll。

今日、DynamicProxy2 を使い始めました。そして、それが大幅なパフォーマンスの低下を引き起こしていることがわかりました。

以下のコードを参照してください。Test1 は Test2 よりも 10 倍遅いです。

DynamicProxy を使用するときにパフォーマンスを向上させるためのヒントはありますか?

アップデート：

私のマシンでは、Test1 に約 45 秒、Test2 に約 4.5 秒かかります。Krzysztof Koźmicの回答を読んだ後、 NotifyPropertyChangedInterceptorをシングルトン スコープに入れようとしました。

約4秒節約できました。Test1 には約 41 秒かかります。

更新 2:

私のマシンでは、Test3 に約 8.3 秒かかります。そのため、Autofac または DynamicProxy を単独で使用してもパフォーマンスはそれほど大きな問題ではないようですが (私のプロジェクトでは)、それらを組み合わせるとパフォーマンスが大幅に低下します。

私はNinject 2を使用してプロジェクトをゼロから行っていますが、1つの質問が私を悩ませています:

タイプのメソッドをインターセプトする場合は、それをプロキシにラップする必要があります (具体的にはキャッスル ダイナミック プロキシ)。上記の型にパラメーターのないコンストラクターがない限り、プロキシの作成は失敗します。存在する場合、このコンストラクターは、型インスタンスがカーネルから解決されるときに使用されています。

残念ながら、これは、パラメーターを使用したインジェクション コンストラクターが無視されていることを意味し、プロパティ インジェクションに頼る必要があります。ドメイン タイプをプロパティの [Inject] 属性と結合することに少し抵抗があります。

Ninjectを使用してAoPのプロキシでインジェクションコンストラクタを使用する方法はありますか?

DynamicProxy オブジェクトはIChangeProxyTargetインターフェイスを実装できることに気付きました。これにより、 のようなことが可能になります((IChangeProxyTarget)myProxyObj).ChangeInvocationTarget(newTarget)。

DynamicProxy オブジェクトの mixin 実装を同様に変更する方法はありますか? 明らかに、これは私が完全には考えていない方法でターゲットを変更するよりも複雑でニュアンスがあります (さまざまなインターフェイスの実装、ミックスインの多様性などのため) が、その概念は完全に考えられないわけではありません。

または、それが欠けている場合、合理的にパフォーマンスの高い方法でこれを達成することに関するアイデアはありますか? 私はこれをハッキングすることに関していくつかの理論的な考えを持っていますが、それは非常に複雑に思えます:

1. プロパティを使用して MixinSwitcher クラス (および付随する IMixinSwitcher インターフェイス) を定義しAction<object, object> DoSwitchます。
2. DP オブジェクトを作成するときに this のインスタンスをミックスします。proxyGenerationOptions.AddMixinInstance(mixinSwitcher);
3. DP オブジェクトを作成しますvar dpObj = proxyGenerator.Create...- 実装するインターフェイスに IMixinSwitcher が追加されていることを確認します
4. リフレクションを使用して、関連する mixin MemberInfo を見つけますdpObj.Gettype()
5. System.Reflection.Emit を使用して、このプロパティの高速セッターを生成します。
6. 設定mixinSwitcher.DoSwitch = (SRE setter method here)
7. ((IMixinSwitcher)dpObj).DoSwitch(dpObj, newMixinValue)
8. 利益...または脳が溶けますか？

ステップ 1 クラスは、特定の/複数の実装をターゲットにできるように汎用化できます。ステップ 4 ～ 5 はパフォーマンスを向上させるためにキャッシュされ、一般的なステップ 1 の実装はクリーンアップされる可能性があります。

それでも、私はそれがかなり狂っていることを否定しません - より良い方法はありますか?

反復的なタスクにアスペクト指向プログラミングを利用しようとしています。懸念事項を分離する方法がわかりません。私は C# を使用しており、AOP には Castle.DynamicProxy (Autofac の InterceptedBy 機能を使用) を使用していますが、この質問への回答が、他の AOP ソリューションにも適用するのに十分な一般的なアドバイスになることを願っています (おそらくあなたは納得できるでしょう)。別の AOP ソリューションに切り替える必要があります)。

たとえば、クラスへのすべてのメソッド呼び出しをインターセプトする次のインターセプターのようなものがあります。メソッドが呼び出されたとき、(1) 呼び出しにかかった時間を測定し、(2) 呼び出される前後のメソッドの名前をログに記録します。

ここでのタイミングの問題 (メソッド呼び出しにかかった時間の測定) は、ロギングの問題 (ログ ファイルへの書き込み) とは別のものにすべきだと思います。私はこのようなことを考えていますが、順序付けにどのようにアプローチするか、またはcallTime変数をどこに置くべきかわかりません:

ここで基本的に私が考えているのは、何らかの方法でTimingInterceptorがメソッドを直接インターセプトする必要があり、次にLoggingInterceptorがそれをラップする必要があるということです。

これらの懸念が正しい順序で発生することを確認するために、人々はどのようなアプローチを使用しますか? LoggingInterceptor が TimingInterceptor の Intercept メソッドをインターセプトするようにして、インターセプターをチェーンしますか? [InterceptOrder(1|2|3|...)]それとも、インターセプター クラスに何らかの属性を設定する必要がありますか? または[InterceptAfter(typeof(TimingInterceptor))]、LoggingInterceptor のようなものを配置できますか?

また、スレッドローカル変数を使用して呼び出し時間を追跡するより良い方法はありますか? はい、これをスレッドセーフにしたいと思います。この変数をスタックに保持することが望ましいと考えていますが、LoggingInterceptor がカップリングをあまり導入せずに TimingInterceptor へのハンドルを取得する方法がわかりません (LoggingInterceptor を再コンパイルせずに TimingInterceptor の実装を切り替えられるとよいでしょう)。 .

いくつかのタイプを1つずつ登録しています：

登録されているこのアセンブリのすべてのタイプのインターセプターを登録する方法はありますか? 私は慣習によってすべてのタイプを登録したくありませんAllTypes。書かずにインターセプターを追加したいだけです

何億回も。

ありがとう！

動的プロキシを使用するコストはいくらですか?

プロジェクトをインターフェイス実装で乱雑にしたくないので、LinFu、Castle、Unity などのサードパーティ ライブラリによって作成された動的プロキシを使用することを検討しています。インターフェイスごとに 1 つのインスタンスを生成するか、呼び出しごとに 1 つ取得しますか。

これはWebアプリなので、長期的にはパフォーマンスの問題は何ですか.

私もEF 4.1（現時点ではCTP5）を使っているので、プロキシクラス自体を作成する場合は、EF独自の動的プロキシ作成ツールを使用できるかどうか疑問に思っています。

PSはい、私のインターフェースは他のインターフェースや基本クラスとともに具象クラスによって実装されていますが、具象クラスに付属する余分なものではなく、インターフェース部分のみが必要な場合があります。

すべてのインターフェイスは、EF4.1 POCO の一部のみを宣言します。つまり、ゲッターとセッターだけです。

Automapper で BaseTypeForInterfaceProxy を設定するにはどうすればよいですか。

LoggingWithDebugInterceptorとLoggingInterceptorの2種類のインターセプターがあります。
Castle Logging Facilityを使用していますが、Castle Logging Facilityによって作成されたILoggerのIsDebugEnabledプロパティに従って、ILoggableを実装する任意のタイプのコンテナーにインターセプターを登録するセレクターを作成する方法を考えています。
どのようにそれを行うことができますか？

Loggable基本クラス ( ILoggableを実装する)をインターセプトするインターセプターの単体テストを作成したいと考えています。
Loggable基本クラスには呼び出すメソッドがなく、ロギング機能によって初期化されるためにのみ使用されます。
私の理解では、次のことを行う必要があります。

1. ILoggableとILoggerのモック
2. ロギング機能の初期化
3. インターセプターを登録する
4. モックされたILoggableのメソッドを呼び出す

問題は、ILoggableインターフェイスに呼び出すメソッドがないため、何もインターセプトされないことです。
ここで行動する正しい方法は何ですか？ILoggable
を手動で モックして、呼び出すスタブ メソッドを追加する必要がありますか? また、コンテナーもモックする必要がありますか?

Moq と NUnit を使用しています。
編集:
参照用のインターセプターの実装は次のとおりです。