Как уже было предложено, статические счетчики или события и слушатели могут технически добиться цели, но если вы стремитесь к более универсальным решениям, это может быть реализовано с помощью Dependency Injection (DI).
Прежде всего, вам нужен Mediator , который используется совместно службой WCF и хост-приложением. Вы можете писать сообщения этому посреднику из службы WCF, а затем он может распространять эти сообщения соответствующим обработчикам на хосте.
Вам необходимо внедрить Медиатор в вашу службу WCF. Это можно сделать с помощью пользовательского ServiceHost, который назначает пользовательский IInstanceProvider контракту на обслуживание. До выхода главы 7 моей книги лучший план, который я знаю о том, как включить Конструкторское внедрение для WCF, - это это сообщение в блоге , если учесть, что делегат просто анонимный интерфейс .
Имея это в виду, рассмотрите возможность использования регистратора статистики как Декоратор для «реальной» службы, поскольку это даст вам лучшее разделение интересов . Примерно так:
[ServiceContract]
public interface IMyService
{
[OperationContract]
Foo DoStuff(Bar bar);
}
public class StatisticsDecorator : IMyService
{
private readonly IMyService service;
private readonly IMediator mediator;
public StatisticsDecorator(IMyService service, IMediator mediator)
{
if(service == null)
{
throw new ArgumentNullException("service");
}
if(mediator == null)
{
throw new ArgumentNullException("mediator");
}
this.service = service;
this.mediator = mediator;
}
public Foo DoStuff(Bar bar)
{
this.mediator.SignalBeforeDoStuff();
var result = this.service.DoStuff(bar);
this.mediator.SignalAferDoStuff();
return result;
}
}
Во время выполнения вы должны внедрить «реальную» реализацию IMyService в StatisticsDecorator вместе с общим посредником.
Если вы используете DI-контейнер, вы можете использовать его возможности перехват вместо ручного поворота декоратора, но концепция та же.