CODEWITHSUNDEEP
.netwcfsoaclass-library
downwitch
downwitch

Reputation: 1372

Is WCF the right architecture service choice to host a complex class library for .NET clients?

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.)

Upvotes: 4

Views: 246

Answers (2)

Anders Abel
Anders Abel

Reputation: 69250

Any interface that is to be run over the network should strive to be as non-chatty as possible. That is, it should preferably perform most operations in one round-trip over the network.

Your example with chaining method calls is a good object-oriented API, but unfortunately it is very chatty with all those function calls. To expose that as a good network-enabled service, it has to be wrapped in a service layer which contains one method for each basic function that the client needs. The data to be transferred has to be grouped into data transfer objects - classes with only properties and no behaviour.

WCF is designed to support this design principle. There is an operation-only service contract interface and data-only data contract classes.

I think that WCF is a good choice, as it helps you to wrap your object-oriented design in a network-optimized service layer.

Upvotes: 2

Adam Robinson
Adam Robinson

Reputation: 185593

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.

Upvotes: 3

Related Questions