Копирование атрибутов в сгенерированный прокси InterfaceInterceptor - PullRequest
Новая
       35

Копирование атрибутов в сгенерированный прокси InterfaceInterceptor

2 голосов
/ 23 ноября 2011

Предположим, у меня есть интерфейс, доступный через WCF: 

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

И реализация: 

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

Я могу опубликовать Service поверх WCF, и все работает хорошо.

Теперь я хочу использовать Unity для перехвата Service.Я могу использовать поведения WCF для этого, но к IService (и Service, который его реализует) иногда обращаются из внутренних служб, а не через WCF, и мне нужен механизм перехвата, который будет применяться как при обращении к классу через WCF, так икогда к нему обращаются локально.

Я могу использовать для этого InterfaceInterceptor Unity, но тогда у прокси, который я получу, не будет атрибута ServiceBehavior, который, очевидно, влияет на поведение WCF и поэтому необходим.

Теперь я могу использовать TransparentProxyInterceptor или VirtualMethodInterceptor, которые будут наследовать от моего Service класса (и, следовательно, наследовать атрибуты?), Но InterfaceInterceptor выглядит как «правильный» перехватчик для использования вэтот случай.В конце концов, я работаю с интерфейсами.

Глядя на код Unity, кажется, что InterfaceInterceptor использует Reflection.Emit для генерации прокси.Если бы он использовал TypeBuilder.SetCustomAttributes, он мог бы просто скопировать атрибуты из моего исходного типа и применить их к своему прокси.Однако я не смог найти точку расширения Unity для этого.Самый близкий, который я получил, был InterfaceInterceptorClassGenerator, но он также не раскрывает его TypeBuilder.

Есть ли простой способ расширить InterfaceInterceptor для копирования атрибутов из базовой реализации?Есть ли другой способ заставить ServiceBehavior, указанный в Service, применить к прокси?

Ответы [ 2 ]

0 голосов
/ 23 ноября 2011

Если вы используете WCF, тогда я не понимаю, почему у вас не будет конечной точки, которую вы используете для внутреннего использования.

Например, вместо использования сетевого транспорта вы бы использовали транспорт с именованным каналом.

Риск при использовании другой инфраструктуры перехвата (будь то Unity или другой) заключается в том, что вам не гарантируется, что вы сохраняете паритет в реализациях перехвата.

Тем не менее, вам лучше использовать только внутренний WCF, а также канал, который соответствует вашим потребностям в этом сценарии.

Обратите внимание, что вы можете написать свой собственный транспорт (возможно, используя разделяемую память или что-то в этом роде), который более эффективен при выполнении вызовов в одном домене приложения (если вы определили, что транспорт на самом деле проблема ).

0 голосов
/ 23 ноября 2011

Я думаю, что вы можете добавить новый слой для своего сценария следующим образом:

add a new layer

Вы можете сделать любой перехват для «ServiceImp», который реализует IServiceImp.Служба не имеет какого-либо кода функции, но является только функцией преобразования и используется как Служба ТОЛЬКО , НЕ не перехватывает Службу, Служба зависит от ServiceImp (или IServiceImp, который может бытьвведено Unity).

Теперь ваш местный житель может использовать Service или ServiceImp.и WCF InstanceProvider может использовать обновленную службу, которая все еще имеет атрибут ServiceBehavior.

...