tags:

views:

38

answers:

1

Ok, not really sure how to word, but will try my best.

I have a number of WCF services that are setup and run awaiting an object to come in for processing.

WCFServiceA
WCFServiceB
WCFServiceC

Service A will run some processing and decide to send the object onto Service B or C.

So my object has [DataContract] attribute on all classes in it and [DataMember] on all properties.

So so far so good.

But now I well lose all the functionality from my object, as this is now basically a serialised version of the object.

So is it best practice if I want to use a full complex object to include the same assembly in all 3 services as a reference and send things across as "KnownTypes"?? Providing the basic DataContract and DataMember for anything using the services that does not know these types so they can still create these object for the services to run with?

Hope I have worded this correctly and you understand my question here.

:EDIT: To try and clarify.

The object I am sending can have a "Policy" attached to it, this policy object is a class and can be one of several types, vehicle, house, life, pet policy etc.

But the actual type will not be known by the receiving service. Hence the need for KnownTypes.

I think I just answered my own question!! :)

+1  A: 

That was a good explanation of the problem. The draw back I see in this approach is if you are going to update the object , say adding new properties or removing some , all the 3 service needs to be updated with the new assembly.

Using of the known types can sometimes lead to backward compatibility issues when you want to upgrade the objects in live depending on the setup.

Or create a DTO (Data transfer object) with just the properties and pass it across the services as a data contract and strip the complex logic in to a helper class which can be referenced by the services.

Suhumar