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

We have about 60 partial files called "BeamServer.cs", each in a sub-folder that corresponds to the purpose of the functions in that file. Any helper classes (or other helper files) that are for the same area of our program resides in that folder as well.

Your "one class" represents your "one business need". We found a nice side benefit in that if one of the members of our team is working on the "Accounting" portion of BEAM (our software), then they would check out the file "Accounting\BeamServer.cs" and none of the rest of the team would be effected.

EDIT: Also, the class should only contain the method signatures (and wrapper functions that simply call base.Channel.DoSomething()... Any data structures would of course be their own class files (such as "Person.cs" or "Employee.cs" or whatever).

Answer 4

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