Question

I have a VERY complex service host which consists of multiple DUPLEX services here. They provide a bit of common functionality (Connect, Disconnect, KeepAlive, etc…) but besides that they provide very specific functionality each.

All my services inherit from a common base class (abstract).

So, I’m also responsible for a part of the client application and I want to have the administrative bureaucratic handling of connecting, disconnecting, keep alive pinging and reconnects (etc…) handled in a base class so I can observe the DRY principle AND force other developers to NOT implement their own connection handling.

Is there ANY way to have WCF expose the service base class so I can create a common wrapper class for the bureaucratic waste of time in the client application?

I really don’t want to see each and every developer of future client components create their own wrapper?

And, if you allow the rant:

Why, why, why is Microsoft so totally negligient towards best practices and basic principles of clean code development? It’s the same as with this INotifyPropertyChanged – stuff where one is forced to write masses of unnecessary, repetitive code instead of being provided with a simple attribute for notifying properties…

Answer 1

I don’t know of a good way to make multiple WCF proxies inherit from a common base class. You can manually edit the code that’s generated when you add a service reference, but that’s not good for maintainability.

But you can have multiple proxies use the same base interface, if you share a contract assembly between the client and the server. You could then write a client-side helper class (maybe using extension methods) to perform common operations on the base interface. You can put the helper class in a shared assembly too, and reuse it from multiple clients.

I haven’t worked with duplex bindings though, so I’m not sure if that introduces complications.

For example, suppose you have two services Calculator and Echo, and each needs to implement a Keepalive method. You could define three service contract interfaces:

[ServiceContract]
public interface IStatefulService
{ 
    [OperationContract]
    void KeepAlive(int sessionID);
}

[ServiceContract]
public interface ICalculator : IStatefulService
{
    [OperationContract]
    int Add(int a, int b);
}

[ServiceContract]
public interface IEcho : IStatefulService
{
    [OperationContract]
    string Echo(string message);
}

You can put the service contract interfaces in a common class library that’s shared by both client and server.

On the server, you’d have your ServiceBase class, which would implement IStatefulService and contain the keepalive-handling code. You’d have a concrete CalculatorService that derives from ServiceBase and implements ICalculator; and a concrete EchoService that derives from ServiceBase and implements IEcho.

On the client, you’ll need two proxies, one per service. In theory, you can generate the proxies using “add service reference”, using the “reuse types from referenced assemblies” checkbox – but I’ve run into problems with this. Instead, you can just use the ChannelFactory directly, like this:

var echoer = (new ChannelFactory<IEcho>("")).CreateChannel();
Console.WriteLine(echoer.Echo("hello"));

var calculator = (new ChannelFactory<ICalculator>("")).CreateChannel();
Console.WriteLine(calculator.Add(2, 3));

(In production code, you’d want to reuse the channel factories rather than creating them on the fly like this. And you’d dispose of the proxies, and you’d have error handling…)

You’ll also need to set up the endpoints in the client config file.

Once you have your two proxies sharing a base interface, you can write a utility class that helps you work with that interface.