Question

I’m trying to expose a fairly complicated class library as a service, I think WCF, but am pretty green and am struggling to understand what I can and cannot do architecturally. If my clients are to be .NET as well (let’s say WinForms, WPF, and/or ASP.NET MVC3), it seems like overkill to write a bunch of contracts to re-expose public classes, or to serialize complex objects. It’s hard to know from the many tutorials out there, because so many of them only work with value/primitive types.

Is WCF the way to go? If so, which flavor is the simplest to implement if the class library will manage all aspects of data and expose only objects?

A simple analogy: a HumanBody class that needed to be exposed as a service allowing for multiple users, always on, etc. If I have a .NET Applause client, and I want to do something like

ServiceName.HumanBody myBody = new HumanBody();
myBody.Parts.Hands.Clap();  

I’d have to turn those objects into interfaces and write a bunch of wrapper methods, but the objects are “complete” as they exist–this is why it feels like overkill to me. (I know I’m not thinking about this correctly–that’s the reason for the question. If these questions are too vague, I will refine on comment/answer.)

(Also, please note that I am not asking how to accomplish this practically–there are many versions of that question already on SO, with a couple notable good answers here and here. There’s also a very useful tutorial on how to build your own WCF architecture without the VS auto-added clutter here. I am working through the construction on my own.)

Answer 1

WCF is most likely the best route for you. However, before you start thinking about how to approach it, I think we need to clarify what a service is just a bit.

A service, regardless of the transport layer that it uses (HTTP, HTTPS, TCP, UDP, MSMQ, carrier pidgeons, etc.) is just a list of operations that take parameters. You cannot, per-se, expose your “HumanBody” class as a service as it is. Services are not object-oriented; they’re very much like procedural programming.

You can, of course, send over complex object graphs as parameters or return them as the return value of a service operation. You can also write your client library in such a way that your interface to the service is object oriented, but your actual service commands will not be that way.

To use your above example, you’d have this as a service interface:

public interface IHumanBodyService
{
    ClapHands(<parameters>);
}

<parameters> here would be whatever identifying information is necessary to send to the service so that it can know what to do. That might be the whole myBody object graph (serialized, of course, but WCF will take care of that for you as long as your class is properly annotated), or it might be something as simple as a BodyId or PersonId value.