Recently I’ve been working on a system that consumes several WCF Endpoints that share types and are part of the same larger system. To this end I use an abstracted service factory to provide a wrapper that lets me call against my service interface and ensure that it is cleaned up correctly, by wrapping calls to client in what I call a proxy wrapper. I don’t call nakedly against a wcf client.
I used dependency injection so where I need to make my WCF calls I inject a service factory, and that provides what I call proxy wrappers. Code to run against the client is passed as lambda expressions and cleanup code is kept in the proxy wrapper. Looks like this:
public void DoSomething(int id)
{
IProxyWrapper<IService> proxyWrapper = ServiceFactory.GetService<IService>();
Data data = null;
proxyWrapper.ExecuteAndClose(x => data = x.DoSomething(id));
return ResponseProcessor.CreateResponse(data, context);
}
I thought the above was a good idea because the try/catch around the wcf client, and the wcf client’s lifetime were no longer a problem of the consumer of the service, the proxy wrapper and service factory would worry about it.
From a testing perspective it was a little weird because I had to program a service factory mock to return a mock proxy wrapper that would run code against a mock client. It is not hard and allows for unit testing, but it is always difficult to explain to someone else.
Recently I ran into a pattern where instead of using a WCF client at all, a client class is created that wraps the WCF client in a way that the consumer would not know or care if the functionality is presented as a WCF client or not. In this pattern the client class handles all details of WCF, or whatever mechanism is used to communicate, and the caller simply references and calls against the client class directly. The same code above becomes:
public void DoSomething(int id)
{
IServiceClient serviceClient = ServiceFactory.GetService<IServiceClient>();
Data data = null;
data = serviceClient .DeleteCheckCall(id);
return ResponseProcessor.CreateResponse(data, context);
}
The above looks a lot more normal to someone not indoctrinated into the intricacies of WCF. It is also easier to test since I just have to have my service factory return a mock of the client. Also if I have to pass data over the service that is hard to serialize I can hide that problem from my consumer by allowing them to pass data regardless of whether it’s hard to serialize and then handling serialization behind the scenes in the client wrapping class.
The only downside is then when I create a service I have to create a client interface and class to wrap calls to that service. Also, this client is only going to be consumable by code that the client is shared with. The same goes for the proxy wrapper I suppose.
All in all I think I like the client class that hides all WCF details from the consumer. Makes it easier if need to change communication mechanism since nothing that is done is specifically to accommodate WCF, as in the proxy wrapper where functionality is passed as lambda’s to all it to be encased in error handling code.
I figured there was a better way then what I was doing and I think I was right.