2

WCF 経由で公開されているインターフェイスがあるとします。

[ServiceContract]
interface IService
{
    [OperationContract]
    void Foo();
}

そして実装:

[ServiceBehavior(...)]
class Service : IService
{
    public void Foo() { /* impl */ }
}

私は WCF 経由で公開できService、すべてがうまく機能します。

ここで、Unity を使用して の傍受を実行したいと考えていますService。そのためにWCFの動作を使用できますが、IService(およびServiceそれを実装する)WCF経由ではなく内部サービスによってアクセスされる場合があり、WCF経由でクラスにアクセスするときとローカルにアクセスするときの両方に適用される傍受メカニズムが必要です。

これにはUnityを使用できますInterfaceInterceptorが、取得したプロキシにはServiceBehavior属性がありません。これは明らかにWCFの動作に影響するため、必要です。

これで、クラスから継承する(したがって、属性を継承する) TransparentProxyInterceptororを使用できますが、この場合に使用する「正しい」インターセプターのように思えます。結局のところ、私はここでインターフェースを扱っています。VirtualMethodInterceptorServiceInterfaceInterceptor

Unity のコードを見ると、プロキシの生成にInterfaceInterceptor使用されているようです。Reflection.Emitのみを使用TypeBuilder.SetCustomAttributesした場合、元のタイプから属性をコピーして、プロキシに適用するだけで済みます。ただし、これを行うための Unity 拡張ポイントが見つかりませんでした。私が得た最も近いものは でしたInterfaceInterceptorClassGeneratorが、それも公開されていませんTypeBuilder

を拡張しInterfaceInterceptorて、基になる実装から属性をコピーする簡単な方法はありますか? プロキシに適用するためにServiceBehavior指定されたものを取得する別の方法はありますか?Service

4

2 に答える 2

0

WCF を使用している場合、内部で使用するエンドポイントがない理由がわかりません。

たとえば、ネットワーク トランスポートを使用する代わりに、名前付きパイプ トランスポートを使用します。

別のインターセプト フレームワーク (Unity であるか別のものであるかに関係なく)を使用するリスクは、インターセプションの実装で同等性を維持していることが保証されないことです。

そうは言っても、そのシナリオでのニーズに合ったチャネルと共に、WCF を内部的にも使用する方がよいでしょう。

独自のトランスポートを (おそらく共有メモリなどを使用して) 記述できることに注意してください。これは、同じアプリ ドメインで呼び出しを行う場合により効率的です (トランスポートが実際に問題であると判断した場合)。

于 2011-11-23T03:04:47.563 に答える