How can I avoid huge communication classes in WCF?

Question

My understanding is that all contract-implementing code has to be in a single class, that can become very large, obviously. How do I avoid this? I really prefer to have a few small classes doing one part of the communication with clients than a single behemoth class.

The only idea I could think of is using multiple interfaces implemented by a single class split up by partial, but I don't think this is really solving the issue.

Answer 1

You might want to use Inheritance, depending on the structure of yoru code. Usually you can break all code up into smaller pieces, helpers, sub-routines, etc.

It's like with any other API-development, you don't want / don't need everything in the same place in the same package.

Answer 2

First, if your contract is big, can they be refactor into more specific service contracts?

The contract implementation class can be implemented as entry point method. You can always model the implementation and define the appropriate abstraction and have your service contract implementation class calls those internal implementation.

Answer 3

If you could change your code fundamentally, you could expose just a single endpoint that works with request/response messages. This way there could be a single end-point and a single service definition that takes a (possibly derived) request message and returns a response message. Your interface into the service would then just be a single method and in the server side implementation you would route that request object to the actual service implementation (possibly determined by a factory) possibly using metadata on the request message (or even it' type-name) to define what service is being called.

So, your end service interface would just have a method like this:

public interface IServiceRequestor
{
  Response ProcessRequest(Request request);
}

This allows you to handle a possibly unlimited number of exposed services without having to know what they will be at compile/dev time, and also avoid a proliferation of Service methods defining the service calls available